Differences between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!)
This simple overview of the different Agile-Lean methods found was too great to not share. Sometimes it is best to keep it simple to build a foundational understanding….then build on that. Pictures speak a thousand words.
- Waterfall Development,
- Iterative Waterfall Development
- Scrum/Agile Development
- Lean
Thanks goes out to author Tara Lee Whitaker, a digital program director of a leading consumer magazine publisher in the UK. She has over 10 years of experience in the areas of product, project and program management. – The Agilista PM
.
Waterfall Development
‘Waterfall Development’ is another name for the more traditional approach to software development.
It’s called ‘waterfall’ as this type of development is often planned using a Gantt chart – you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).
In Waterfall approaches, you will rarely aim to re-visit a ‘phase’ once it’s completed. As such, you better get whatever you’re doing right the first time!
This approach is highly risky, often more costly and generally less efficient than more Agile approaches.
The main issues with this approach include:
- You don’t realise any value until the end of the project (when you deploy) (See: Self-Funding Projects, a Benefit of Agile Software Development)
- You leave the testing until the end, which means you’re leaving issue discovery until late in the day
- You don’t seek approval from the stakeholders until late in the day – their requirements might have changed
- You’re heavily reliant upon a plan, which you can/will often follow to the detriment of the end result
- You’re heavily reliant upon a project manager driving the way – the power of one
Iterative Waterfall Development
This approach carries less risk than a traditional Waterfall approach but is still far more risky and less efficient than a more Agile approaches. The focus is on delivering a sprint of work as opposed to a series of valuable/shippable features. The most commonly occurring issue in this type of scenario (in my experience) is bottle necking. For example, you deliver loads of code a little bit behind schedule (?) and you leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-commitment. It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.
Scrum Development
This approach carries far less risk than Waterfall approaches. We focus on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature. With that said, we still plan our work in iterations and we will still release at the end of each iteration.
Lean Development
Lean is very similar to Scrum in the sense that we focus on features as opposed to groups of features – however Lean takes this one step further again. In Lean Development, you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature. By doing this, you further isolate risk to a feature-level. In these environments, you aim to eliminate ‘waste’ wherever possible – you therefore do nothing until you know it’s necessary or relevant.
* * * * * * * * * * * *
Like what you read? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools you can use to help you be as Agile-Lean as possible….delivered right to your inbox weekly. No spam or junk mail. You can unsubscribe at any time.
..
There are a number of problems with this analysis, and as usual, they spring from a lack of understanding of approaches beyond the author’s preferred one.
1) You’re simply restating your conclusions about each approach, with some major unstated assumptions about the project environment, particularly the degree of ongoing business requirement change and whether you’re doing the classic one-off, unique project, or ongoing product development.
2) There’s no a-priori reason why Waterfall or Iterative Waterfall cannot adopt good software development practises introduced by Agile teams, such as feature isolation. Particularly for Iterative Waterfall – if a feature misses this sprint, then other than inconveniencing your test team, there’s no reason why it can’t drop into the next one. Actually, the greatest risk of this is in having mis-estimated this in the first place; more of a Risk when you’re planning as part of the iteration.
3) Feature isolation isn’t always possible – you may have true technical dependencies of varying degrees of strength that make it impractical to carry on while one area is blocked.
4) Iterative Waterfall more commonly overlaps the iterations, keeping each team reasonably levelled in effort for the duration (I’m assuming that Design is within one or both of Plan and Build here).
5) To clarify Lean development, each feature flows through the lifecycle on its own timeframe, independently of any others. Unless you have super time-efficient Test, testing the full solution (ie new tests plus a complete regression test) for each new feature is challenging for many test teams. It also has a very strong emphasis on standardisation and optimisation (and therefore a strong process focus) to enable effective continuous improvement – ensuring the improvements achieved once to be consistently gained. Stable Scrum teams in a continual enhancement environment, working on a clean architecture often tend towards Lean methods as they mature.
For pragmatic Project Managers, though, there is no single best method. Each project/environment requires method adoption and tailoring (and regular review) to define the most appropriate approach.
For Scrum and Lean PM paradigms you need to make sure your team is fully focused in order to guarantee efficiency. TimeOP is a great solution tracking your team’s progress, not only from a PM point of view, but also from an involvement point of view.
These are somewhat effective in distinguishing the different methods, and I like them in that regard, however their over-simplification (i.e., Iterative Waterfall need not be mandated as exclusively sequential) can be misleading.
For example, the generalization that Scrum “carries far less risk than Waterfall approaches” can be mis-representative and potentially unrealistic. With each project, with each methodology, with each implementation, so much depends on the team, the planning, the execution, not to mention other attending factors (e.g., communication plans, quality objectives, integration, vendor relations, budget/cost management, … the list is long but hopefully you get the point).
I’m not trying to over-complicate the issue. These are real-world considerations. To toss them to the side just to present, for example, Lean in its best favorable light while highlighting Iterative Waterfall blemishes would be a disservice. I really like Lean. Scrum has its place. So does Iterative Waterfall, etc.
Let’s keep it honest. Thanks!