4 reasons you should stay away from Almost-Scrum
[Originally posted on rtos.be]
“Almost-Scrum” or what is also known more generally speaking as the Avalanche Model is not a good project approach to find yourself in with your development team.
On Wiki you’ll find the following description: “The Avalanche model is a Software Engineering project management anti-pattern, it is a combination of a sequential process such as the Waterfall model and Agile software development methodologies. It is the result of a Project Manager’s attempt to apply Agile techniques to a project, when all they really understand or were taught was a sequential development cycle. Instead of breaking the project into parts that each sequentially go through the phases of development, the entire project inhabits all phases of development simultaneously. Usually the result of attempting to use the Avalanche model is mass confusion, wasted effort, and a product that cannot meet the specifications of any requirements document.”
From my personal experience here are the four main disadvantages of this development approach:
- confusion: terms that have a precise meaning in Scrum are redefined to match terms known to the organization, leading to confusion. Take the word “Sprint”. “Sprint” raises certain expectations to people knowledgeable to Scrum, for instance:
- It requires a sprint back log filled with detailed User Stories
- The PO has explained the User Stories before-hand
- An estimation meeting was organized (before the Sprint)
- A retrospecitve meeting is organized afterwards
Typically, when in the Avalanche Model, a Sprint is just a period of some weeks that one fills with loosely defined requirements.
- superfluous work: because you keep two ways of managing your project you need to do things the classical way and on top of that you also need to do extra work for the Agile part. Some examples:
- the organization requires you to deliver a detailed plan in MS Project, while you also need to organize and document your sprints.
- the organization requires you to deliver a detailed analysis before starting development, while you apply Scrum to discover the details along the sprints which you document in User Stories.
- the organization requires you to deliver an excel file and word documents as status reports, while in Scrum you have burn-down charts and scrum boards
This might not seem like a lot of work, but I can assure you you’ll be investing a lot of energy doing both.
- neither fish, flesh, nor fowl: since you try to balance between two ways of working, people often will unconsciously choose the path of least resistance, and either say “when working the old way, I never had to do X” or “when in Agile mode we’d never do X” and finally X never gets done.
- no fun: when you are on a roll in a real Agile project, the team plays a waltz: steady and continuous at a pleasant maintainable speed. In an Avalanche Mode, it is often more like a jerky merry-go-round: speeding up brusquely only to halt to a sudden standstill a little later.
Now, don’t get me wrong: if it is a transition phase (meaning: you’re on your way from waterfall to full Agile and you’re only temporarily stuck in an Avalanche Model), then it is ok. As long as the end goal is full Agile!
If, however, your end-goal is the Avalanche Model, then don’t bother. It will cost you and your team members a lot of energy, and the gains -if any- will be marginal. It’s more likely that team members will become frustrated quickly and lose interest in the project.