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
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.
Picture
1:
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
farmore 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) isbottle 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 lessforced 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.
Picture
2:
Scrum Development
This
approach carries far less risk than Waterfall approaches. We focus on
delivering fully-tested, independent, valuable, small features. As such,
wediversify 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.
Original Link: http://www.agilistapm.com/differences-between-waterfall-iterative-waterfall-scrum-and-lean-software-development-in-pictures/
