Agile vs. waterfall – what’s the big deal?

If you don’t work in IT or on software projects, this is probably not something you will be worried about! But just in case you come across the phrases agile (or more correctly Agile with a capital ‘A’) or waterfall, here’s what you need to know about these methodologies.

Let’s go back a bit first. One of the features of software that makes this debate relevant is that it is malleable, as opposed to ‘hard’ engineering activities like building a house or bringing a new piece of consumer electronics – or any physical product – to market. Software can be produced quickly, refined ‘on the fly’, built in separate chunks and then linked together, thrown-away, tested and implemented, all in relatively short cycles. This is one of the reasons that Agile exists.

Software engineering used to be, and still is in some respects, about following a structured linear process, such as:

• Kicking-off a project or initiative with some vision or stated needs.
• Understanding and documenting the system requirements.
• Designing the solution.
• Building it!
• Testing that ‘it’ does what you want ‘it’ to do.
• Rollout the solution, launch the product, instal the app…

This is called a ‘waterfall’, metaphorically flowing down from start to finish through a series of stages, with little or no opportunity to go back up. Although nobody told salmon that that was the rule!

But there are problems with this approach, not least the lack of flexibility, the need to understand a lot of the detail up-front, and the long delay before the Customers see the finished product. There are many ways of adapting this ‘traditional’ approach to be more agile (small ‘a’ meaning quick and flexible) or lean, such as working on small chunks (increments), progressively refining the solution (iterations) and including Customers throughout the process. As software became easier to produce and critical to business survival and success, so software developers and managers started looking for more efficient ways of working such as Extreme Programming (XP) and Scrum.

In February 2001 there came a watershed moment (no pun intended) for the Agile movement, in snowy Utah a group calling themselves the Agile Alliance created a Manifesto for Agile Software Development, Although there is no one right way of doing things and no ‘owner’ or licensing of Agile, practitioners are expected to follow some value statements and guiding principles, including:

• [We] value working software over comprehensive documentation.
• [We] respond to change rather than follow a plan.
• The priority is early and continuous delivery of valuable software (i.e. that which satisfies the Customer).
• Build projects around motivated self-organising teams.

So far so good. However, as is normal in IT there are lots of different flavours out there, much jargon (such as sprints, backlogs, burn-down charts etc.), and zealots on both sides of the debate.

Unlike the videotape format war ‘betamax vs. VHS’ in the 1970’s and 80’s, Agile will not kill-off waterfall because both provide a different and even complementary way of working, appropriate to different situations. In fact it is more likely that future fashions in the industry will blend the best of each into a new thing, leaving the debate moot and the debaters ranting in their retirement homes about the good old days when Agile was the next big thing, and anyway betamax was the better format!

Tony

@ITelementary

(c) 2015 Antony Lawrence CBA Ltd.