I’m the middle of a Scrummerfall (http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.aspx)
Euphamisticlly defined by Brad Wilson:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.
Perhaps this:
Scrummerfall. n. The practice of combining the meetings of Scrum with a Waterfall process. This ensures that the team doesn’t have to change the way they work while adopting Scrum.
Right now I’m at the tail-end of a project with a first-time Scrum team. Here is where we’re at.
100% Code Complete!
I still have no idea what the phrase “code complete” means (other than the title of a great book by Steve McConnell). Making this declaration with 35 bugs open is meaningless. The team front-loaded all feature development, postponed testing and deferred bug fixing. We’re still finding bugs.
Here are some symptoms to this approach
I believe a core Agile principle is to deliver a high-quality system at frequent intervals. When a team is doing the Scrummerfall there is no pressure on keeping a system healthy. Why invest in automated tests and automated deployments when there are two (or three) Sprints at the end dedicated to testing and bug fixing?
If a team is delivering a high-quality product at frequent intervals, it’s because some investment has been made to ensure that the quality always remains high. Usually, that means testing the system all the time. Testing is painful. When all the features in the system are verified by hand each iteration (”yup it still works”) someone eventually says “enough is enough” and begins automating tests. In the Scrummerfall there is no pressure to have a high-quality system at frequent intervals. Deployment, testing and bug fixing are deferred to the end. The pain doesn’t happen frequently enough for someone to try to fix it.
Mike Cohn likes to say, “The deadline [of the Sprint] is sacred.” I like to say, potentially shippable is sacred.
Even if they won’t admit it, it seems like some teams like the test & fix cycle of a project
Programmers:
Project Managers:
QA:
After a sprint review meeting today I asked a few engineers, “From 0-10 how stable is the product?”
“two”
“three”
<nods>
The team has been working on the product for 11 sprints over six months. And I’ve been blown away by the amount of functionality the team has been able to add in such a short time. But the product hasn’t settled into a groove. There are a lot of features that almost work.
A couple of things are effecting the team:
Recent Comments