How to combine waterfall and agile?

In answering this question, we want to start with a word of caution: combining waterfall and agile is an agile anti-pattern. The agile way of developing software has been designed to ‘replace’ traditional software lifecycles. Especially the timeboxed approach and the focus on ‘delivering value’ instead of ‘following a plan’ do not match with the way waterfall projects work.

Having said that, we believe that any starting point on the path to agile is good. If an organization doesn’t allow immediate abandonment of the waterfall process, running sprints inside the waterfall project can be the middle way to get started. In waterfall, we typically agree on a planning and deadline for implementing ‘all requirements’. Once we have a deadline and we know what needs to be developed, we can start running iterations within that planning. This means that we ‘cut’ all requirements into smaller parts. Each iteration of 2-3 weeks, we deliver parts of the requirements.

The big challenge in combining a waterfall process with Agile is change. In the above description, we can see that all requirements are fixed. If we deliver parts of the requirements each sprint, the big question is ‘how do we deal with new insights and changing requirements’? There are some possibile paths to address this questions:

1. Fix everything

If we fix everything upfront, we have mini-waterfall ‘phases’ instead of real sprints. In each iteration, we deliver a fixed set of requirements, which has all been planned upfront. We try not to change the requirements from iteration to iteration, but just follow the plan. Any additional requirement is parked till the end of the project.

2. Changing scope

An alternative is to be flexible with the scope. While we have a fixed scope, we allow for change in between the iterations. When a product owner has a new requirement, he can add this to the priorities in his backlog. Now instead of parking it till the end of the project, we can implement the new requirement. To do so, we replace that new requirement with an old requirement of the same size. This means the workload is equal and we can still make our deadline. The tension we get with this is that by the end of the deadline, people who are still in the waterfall mindset, will recognize that not all requirements have been implemented. We then need to plan for additional sprints and with that, move the deadline for release of the project.

One of the biggest benefits of the agile way of developing software products is the focus on ‘delivering the highest value within the timeboxes’. This means in each sprint and it also means we aim for maximum value within the timebox for the whole project. If people are in the agile mindset, they will recognize that by the end of the project timebox, what they will get is high value, provided that the project has been managed well. This may mean that some of the initial requirements are not done yet, but that’s ok, because they have been substituted by the product owner by ‘better requirements’.

People in the waterfall mindset expect everything to be completed by a certain date. If we run agile inside a waterfall project, with stakeholders ‘thinking waterfall’, this will inevitably lead to tension. We therefore always recommend educating everybody involved on the way agile works and explaining how the combination of waterfall and agile deviates from ‘pure agile’. This will over time lead to support and understanding of the Agile way, which may allow for future projects to be run fully agile.

Want to know more? Talk to us