The waterfall approach is named as such, because the project management process represents the flow of a waterfall through the various stages of activities. At the top of the waterfall is the requirements gathering stage, followed by design, development, integration, then testing, training and roll out. The approach is considered highly structured and managed, and it does work well for certain types of projects – in particular those that are unlikely to have evolving requirements and where there is certainty about the end goal.

In a waterfall development approach, all of the analysis and requirement building is done up front. This is followed by a stage where all the design is done. Then the development is all done in one go, and later on there is a stage when all of the testing is done.

Agile differs significantly from the waterfall approach to project management. It evolves in the face of continuous business change. It is helpful for when there are fewer certainties and when business requirements may adapt over time, or may not be well known, or both. When projects are run in an agile manner, they are iterative. Each stage is run incrementally and there is a lot of collaboration between people in varied teams.

When project work is operating in an agile manner, all the different work streams happen at the same time and they all conclude at the same time. Analysis, design, coding and testing all operate concurrently, and they all finish together at the end of the sprint. This is quite distinct from taking a waterfall type of solution to project management where each phase concludes before moving on to the next. Another important difference is that in agile, teams are self-organising. This does not occur in the waterfall project management approach.

It is all too common an error that agile teams start operating in the manner of mini waterfalls and continue calling it “agile”. Fortunately, there are warning signs that teams can look out for to avoid this scenario happening. One trap that teams often fall into is having the team work in silos. This is advantageous from the perspective of some developers as they have much more control over what they are doing. However, it does lead to mini waterfalls. This is because while it may seem efficient, it results in a longer wait for testing results because testing starts happening after development.

Another key warning sign is when small aspects of the project (user stories) start becoming more than just short placeholders. When user stories start having their own specification documents, this is not agile. Everything starts getting documented out for the user story, and the development is no longer iterative. Again, the testers then start working one stage behind the developers and not in the same iteration. What happens is, an iterative waterfall approach starts to build up – with each user story becoming a mini waterfall project in its own right. However, this is not what it means to be agile.

Other mini waterfall warning signs include the situation where only certain parts of agile seem to be going on in the project. An example scenario might be that the team is self-organising and collaborating across disciplines, but that design has evolved to start happening at the beginning of the sprint and testing at the end. The fact that the team is self-organising and collaborative may throw people off realising that this is a mini waterfall in disguise, but that is what it is.

While mini waterfalls may feel comfortable for those working within them, the main problem with them is that the user will not get what they want as testing and adjustments are not happening along the way. Not only that, but the timeline for project delivery starts to drag out. This will be dissatisfying for the customer.

True agile project management is a way of operating that is embraced throughout the organisation. Simply telling teams they are going to start working in an agile way, but not having leadership on board with this, will not lead to agile working. Traditional project management needs to be set aside, and an agile methodology must be used.

In true agile project management, planning does not occur upfront the way it does in a waterfall system. As soon as planning and design starts happening at the outset again, the team are working in a waterfall, albeit often a mini one. Tight and short feedback loops are required for agile to be effective. This helps the project team to actually build a product that will meet what the user/customer actually wanted, because users can give their thoughts much earlier during user stories. It is this process of continuous feedback that helps the project more quickly evolve into an end product that will meet the user/customer’s needs.

To move back from mini waterfalls to agile development, stop looking at the development in phases of requirements, production, design, development and test. Instead, go back to considering one aspect of what the user wants, developing a small part of this and checking in to see if it is right or how it could be better, and then continue building iteratively until the user is satisfied.

Where agile is not fully embraced through the organisation, it is possible for so-called “agile” teams to revert to the old ways and start developing mini waterfalls within sprints. This is detrimental to the project because it not only extends project timelines, but it means that user feedback is gathered later on, leading to more work to produce what they wanted. True agile occurs when all aspects of the project happen at the same time including analysis, design, coding and testing. Ultimately, the aim is to deliver value to the customer as often as possible.