Coming from an old school background and learning my trade
as a Business Analyst straight after Uni, I remained unconvinced about ‘agile
development’ for a long time. I only ever saw the best way of guaranteeing project
success was by capturing the requirements up front, creating traceability to
more detailed requirements and so on.
Over the last 9 months, I have been gradually converted to
the agile method of software development. I owe a large amount of this renewed
thinking to one of my colleagues from the US who shall remain nameless (despite
the constant hammering about it), but it was not all his doing. More and more
of my clients have been asking about Waterfall v Agile and what this actually
means?
Over the course of several engagements recently and learning
more about the practical application of Agile for software development, I worked
with a client that wanted to use both.
Folly! Was my first thought but when I
lifted the lid, I found that there can be a place for both on the same project.
Case in point, my client was undertaking the initial requirements analysis
using Waterfall but wanted to develop using Agile. So we worked it through…
Waterfall and Agile? Argh..or Maybe? |
They captured the Business Objectives (level 1), eliciting
the High Level Requirements (level 2) and then decomposing these into Detailed
Requirements (level 3) and creating traceability across the three levels. Now
came flip time. We decided to create work items (tasks) from the Detailed
Requirements and enter these onto the Agile Product Backlog (basically the list
of things to develop). From here they prioritised some them into a Sprint (a
collection of activities to develop in a set time frame)
and completed the activities (including some testing) to deliver working code at the end of the Sprint. Rinse and repeat for subsequent Sprints and there you have it, Waterfall and Agile playing nicely together.
and completed the activities (including some testing) to deliver working code at the end of the Sprint. Rinse and repeat for subsequent Sprints and there you have it, Waterfall and Agile playing nicely together.
So far, as long as you have clear demarcation lines between
the two methodologies (i.e. they cannot exist in the same project in the same
phase), they can coexist peacefully with traceability maintained.
I will post an update in a few months to see how it all
turned out.
I recommend Kurt Solarte's article on baby steps to Agile and Scott Amber's blog on Disciplined Agile Delivery. These further expand further on Agile concepts.
Nicely put Dave, there are a growing group of people calling this out as a new method of its own, scrumfall or water-scrum-fall as forrester puts it: http://www.forrester.com/rb/Research/water-scrum-fall_is_reality_of_agile_for_most/q/id/60109/t/2
ReplyDeleteYour blog provided us with valuable information to work with. Each & every tips of your post are awesome. Thanks a lot for sharing. Keep blogging.. Outsourcing development
ReplyDelete