We’ve all heard about waterfall and agile projects. Waterfall projects are specified upfront, designed, developed, then tested and quality assured. The method is based on engineering projects and has served the IT industry well. Agile projects typically have delivery timeframes of two weeks, where a small increment of work is specified, developed, tested and delivered in that time. Both methods have their place, and research by the Project Management Institute (PMI) shows that 44% of projects use the waterfall method, while 30% use agile methods – the remainder using a hybrid of both approaches.
All well and good, but we should examine waterfall and agile in a little more detail to understand the pros and cons of each method, and to know which method to use when.
Let’s start by understanding the playing field better. The PMI uses the word “predictive” to describe waterfall projects, and I like that thinking. Waterfall projects are useful when we can predict the conditions that will prevail when the project is delivered. With business dynamics changing rapidly, and with technology changing perhaps more rapidly, and with customer requirements continuously and rapidly evolving, we could predict that waterfall method usage will decline in the future.
However, there are still some areas where waterfall projects will serve you well – you guessed it – where you can predict what will happen with some accuracy. Major software upgrades, or software associated with civil engineering projects, or office moves and expansions, can usually be treated in a waterfall way.
However…
We can’t deny that rapid change is the order of the day. In the 1980s, requirements had a half-life of about a decade. This meant a project could be 18 months long, and about 90% of the functionality specified at the start of the project would still be appropriate and useful.
But, the half-life of specs dropped to about two years by 2000 and is now estimated to be about six months or less. This means that the same 18-month project would only deliver 12.5% functionality that is still valid. That’s how rapidly things change. This is why more and more organisations are adopting agile development methods.
But agile is one of three methods that deliver in short periods. They're cut from the same cloth, but iterative, incremental and agile approaches are what I call the adaptive method: because they are designed to sense and respond as the initiative progresses. Typically adaptive cycles are between two and four weeks. This means a small element of a larger goal is designed, built, tested and delivered in a short period. If the deliverable works well, we continue to the next element. If there are problems, or if business conditions have changed, we can change direction, or even stop the initiative completely.
In waterfall projects, testing, and quality assurance are conducted near the end of the project, when all the functionality had been developed. Not only does this mean that risks are delayed until the end of the project, but if major problems are found, then fixing them involves going through mountains of coding that has been developed. In adaptive projects, testing and QA are done with each deliverable, and new functionality is not built until problems with existing functions are solved. So you are building on a solid base
Waterfall projects deliver outcomes at the end of the project, which means that benefits can only be realised after implementation. That’s fine if you’re building a bridge as no one can cross the bridge until it is completed, but with software that can deliver components of functionality, it may be the wrong approach. With an adaptive approach, functionality is usable as it is delivered, which suggests that we can focus on the most important functions, and get them in use as early as possible. This leads to the concept of minimum viable products (MVPs), where functions are made available when they are ready. If the MVP is a customer product, some early-adopter customers will pay for this functionality, in the knowledge that, over time, the product will get better and have more capabilities. Importantly, revenue flows early.
There’s much more to discuss about the differences between waterfall and agile approaches, but here’s the bottom line: it’s the thinking that matters. If we think that conditions will remain constant, we may be disappointed. However, if we adopt a mindset that says things will change rapidly, and use methods that allow us to identify changes quickly and respond to them, then we are more likely to succeed.
Takeaways
Waterfall projects are sequential, and agile projects are incremental.
Waterfall projects are useful if we can predict future conditions.
We predict that waterfall method usage will decline in the future.
The half-life of specifications for software is 6 months.
Agile projects allow us to sense and respond.
Agile thinking is essential in a changing business environment.
Share