The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!)
Here’s a VERY simple overview of the main differences between Waterfall Development, Iterative Waterfall Development, Scrum/Agile Development and Lean.
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.
Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!
I actually was able in my SDLC processes to marry the Waterfall with Scrum and Agile and it is working ...
I experienced that using story points based on complexity has brought the team disagreement in assigning points. We still ...
Hi, in addition to your article, you can view this list as well on my website in a more clear ...
Good article, and I STRONGLY ENCOURAGE everyone to read Andy Bruce's earlier response. Andy has nailed the often missed point ...
You have completely demonstrated the whole scheme of software development within the above diagram on such a fine way. Truly ...
Great post. I really like how you explained the methodologies in the pictures.
I was asked about this by a client today so great timing!
The usual sticky point remains of how we convince a sceptical client that Agile development can provide enormous benefits without a fixed price and up front requirements analysis – the battle continues!
I think your diagrams are inconsistent. One axis is time, the other is ‘features’.
Iterative Waterfall makes it look like time is horizontal, but that’s not consistent with SCRUM or LEAN.
And, your description doesn’t make SCRUM and LEAN sound that revolutionary, they come out as just mini- and micro- Waterfalls.
Hi Tara, I’ve translated in French your excellent post : La différence entre les modèles de développement en Cascade, en Cascade itératif, Scrum et Lean (en images !) Regards, Fabrice
Thank you for your post, as it is a good starting point to explain to clients the differences between these methodologies. I really like the textual explanations, the images don’t enhance your content any better, in my opinion.
Jackson: the conundrum is “without a fixed price and up front requirements analysis”. I strive towards agile methodologies, while still giving a fixed price. Granted, much more difficult to aim it right, and sometimes you win sometimes you lose, but you still give the client the confidence of the known bill. What are your thoughts on this?
[...] Shared The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean (In Pictures!) | Project Manag…. [...]
I like the pictures put together by Karl Scotland, which illustrate the points a little differently.
http://availagility.wordpress.com/2008/07/07/the-anatomy-of-an-mmf/
http://availagility.wordpress.com/2008/11/26/kanban-and-the-new-new-product-development-game/
[...] Take a closer look at it and read the explanation over on her blog, agile101.net… [...]
Hi
I like the picture. I would put in both Scrum and Lean the build and test boxes together meshed so that they are really intertwined right from the start. This picture makes it look like they would be sequential.
The Lean diagram shows many deployments. It seems to suggest that production deployments are increased whereas the features introduced are decreased. How do you deal with the inherent difficulties of taking down a system for so many production deployments?
Nice pictures !!
To be perfect, it would be nice to show the pipeline kickoff of the lean approach. As is, we could have the feeling that each column is related to the same item (which is not as far as I know)
Herve
How to convince clients to use Agile while meeting their needs for predictability?
0) Make sure it’s a project which can use Agile. Web apps? Almost always. Embedded guidance software for a deep space probe? Almost never.
1) Propose a fixed burn-rate. That is, propose a team that is right-sized to the skills and scale of the project.
2) Propose a fixed sprint size (2 or 3 weeks is typical) if you’re a fan of Scrum; if you’re prefer Extreme you can propose 6-8 week releases composed of 3-4 2-week iterations.
3) Propose a contract where the client can change anything they want for the “next” sprint or iteration – and where they can accept/reject each story as it completes. In exchange, the client has to be sure there is a single voice (not a committee) who is available to (or embedded with) the team.
4) Propose that the client can cancel at the end of any sprint/release with no penalty and will be left with shippable software that has been accepted.
One Agile firm I’ve brought into clients has the data indicating that many times clients stop development at around 85-90% of the original budget because the product is good enough to ship and make money (or deploy internally and save costs for the company).
I’ve used this approach in some of my strategy engagements as well. It’s a good compromise between time-and-materials and fixed-price models. The client can very quickly receive value (and see the cost vs. value model emerge quickly from the results of each sprint/release); the consulting firm has some predictability in its revenues.
Hope this helps!
[...] Here’s a quick and simple overview of the main differences between Waterfall Development, Iterative Waterfall Development, Scrum/Agile Development and Lean by Agile101.net [...]
Wow, great explanation, nice set of picture, this is exactly what I needed to show to people in my business the difference between the method. Thanks!
Good post… its very easy to understand and i liked your way of explanation.
Hey man I must mention that I was very confusing and did not even understand the differences between Waterfall, its iterative type and Scrum. I am clear now. Though I was stuck in your text explanation, your pictures helped me to understand. Thank you very much buddy.
These pictures are very useful in getting the differences. i’m practicing scrum practices in my project, but was not able to tell the fine difference between the iterative waterfall and scrum models.
Thanks for showing us that Lean = Epic Fail. I hadn’t realized till you pointed it out.
Hi Reow,
I’m not sure I follow your comment. Lean is anything but an ‘epic fail’…
/
Could you elaborate?
Thanks,
Tara
I like the lean method the most, but I would modify it to include a separate and longer “planning” section (requirements and such) at the beginning.
[...] I was perhaps more biased toward 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.” —agile101.net [...]
Very nice and good posting – easy to understand…..
Nice illustration! A minor nuisance is that you seem to confuse iterative development with incremental development. In your picture “iterative waterfall” should be “incremental waterfall”.
Have a look at my illustration from a bit different perspective: http://samipoimala.com/it/2010/04/16/iterations-and-increments-explained/
[...] The Difference Between Waterfall, Iterative Waterfall, Scrum & Lean (in pictures) – Visual representations of these various processes. [...]
can any one tell the major difference b/w agile scrum development methodolgy and rest of the traditional models.
thanx.
Good explanation..I never heard about this kind of methodologies until my client ask this requirement..Now i got an idea..
Thank you very much..
A few items that you did not get too in this post, but I am sure you can address in the future:
1. The entire team, chickens and pigs, must have some accepted level of skills/experience maturity to leverage for each scrum/product backlog.
2. The burndown chart should reflect the real budget costs thus far, with a real amount remaining to complete the project. Promises to catch up in the next scrum all too often look like re-work on DRs to me, which wastes the time/cost savings of Agile.
Thanks for your efforts!
Regards,
Rick
[...] สรุปจาก The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictu… [...]
[...] The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean (In Pictures!) | ! (tags: process waterfall scrum lean) [...]
very useful information by comparing all of software methodologies in the easy way and the diagram is cool!, this website can answer you everythings which are related. Thanks again.
[...] Agile 101 post here Categories: Methodologies Comments (0) Leave a [...]
[...] a imponer una metodología Lean en los últimos. Gráficamente podéis ver aquí las diferencias entre estas metodologías, un link muy [...]
[...] The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictu… (tags: waterfall scrum process) [...]
Great explanation, nice set of picture, this is exactly what I needed to show to people in my business the difference between the various metholodgies.
You have completely demonstrated the whole scheme of software development within the above diagram on such a fine way. Truly appreciating one. Liked it very much and bookmarked for my further references.
[...] https://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-i... [...]
I actually was able in my SDLC processes to marry the Waterfall with Scrum and Agile and it is working for me for many years, see diagram here:
http://apandre.files.wordpress.com/2011/08/scrumwaterfall.jpg