Shifting from a waterfall model to Agile takes a lot of effort. Many companies, especially larger ones, have difficulties embracing the principles of the Agile manifesto and shifting these values into a continuous mindset. As a result, they roll out only some of the tools and practices within their organization. But do those changes mean they’re truly working Agile?
After this read, you’ll be able to recognize an iterative waterfall and know how to break it.
Recognizing an iterative waterfall
Here’s the software development process that occurs within iterative waterfall companies. First, business analysts describe what they’d like to have built. Since they are working with known practices from Scrum, they pour these requirements into “user stories.” However, these user stories aren’t a conversation starter, but the absolute truth. The stories can been seen as artifacts.
With a little bit of overlap, the next phase will be the design. A designer will have a look at the requirements and visualize what’s listed in the stories. After a few rounds of feedback, the design is set in stone. Together with the requirements, the design is then ready to be handed over to the development team.
The development team is entitled to wait building a feature until these two artifacts are marked as ☑️. In the meantime, the analysts can start defining new user stories and wait with their feedback until the previous stories are delivered.
Hold on… Doesn’t this sound just like working in a waterfall framework?
It does! It’s just happening in an iterative way now.
The disadvantages of iterative waterfall
Here’s why the iterative waterfall model doesn’t have any advantages:
- More narrow collaboration
Creating artifacts like requirements and designs before starting development feels like setting up a contract, rather than working together in a joined effort. - Harder tracking of progress
Agile is about continuously delivering technical excellence. By creating separate blocks for specific disciplines, it gets harder to track the real progress. - Slower adoption of change
When the whole team is working on the same goal, you will have a possibility to adopt changes in two-week iterations. In iterative waterfall, this cycle takes six weeks because people are waiting for others to finish their work.
So, if iterative waterfall doesn’t work, how should it be done? Here’s what Mike Cohn, godfather of Scrum, suggests:
“A team should always work to overlap work as much as possible. Any upfront thinking (analysis, design and other types of work) should be done as late as possible and in as little detail as possible while still allowing the work to be completed within the iteration.”
— Mike Cohn
They don’t realize what's going wrong
Many organizations are shifting away from the waterfall model by using Scrum/Agile terms and embracing some of the Agile principles in their own way. As a result, they have no idea what is going wrong. They simply conceal their old habits with buzzwords and think they learned from their mistakes.
Can we blame them? No, we can’t. After all, it takes a lot of time, effort and patience to reveal the true value of working Agile.
When working in iterative waterfall, there’s no room for conversations about how to reach your end goal. To be truly Agile, business analysts should only agree on the effects they want to reach and the added value these will bring. These wishes can then be seen as the core design for a new feature. From here, you can start exploring the options with all the people involved.
Don't work like this…
…but like this.
Collaborating with all people involved in the sprint has a lot of advantages:
- Iteration is a cheap way of building software. Therefore, you can achieve much more in one sprint.
- You can identify risks and deal with them before finishing the sprint.
- You won’t have to document small changes.
- Changes won’t have to go trough a feedback loop that can take longer than a sprint due to hierarchical complexity in an organization.
Rules of thumb for being truly Agile
Now that you know the advantages, it’s time to move away from the anti-pattern called iterative waterfall, which has all the disadvantages of waterfall and none of the advantages of Agile. Here are a few rules of thumb:
- When example mapping, user stories should fit on a post-it note. The same goes for requirements. If your user story doesn’t fit the post-it, split it into smaller stories or re-write it.
- Design should only be sketched before development starts, and only create a general understanding of what should be built.
- Always keep documentation as minimal as possible. Only document what can’t change. Remember that having a good conversation is always better than writing documentation or requirements
- Be open to suggestions and always collaborate during sprints.
- None of the people involved should be in the lead. You’re working on a shared goal which can only be achieved through shared effort.
Change is never easy and the journey that you’re maybe about to start will trigger a lot of discussions. Keep in mind that correcting and educating people is not always the key to success. Ask a lot questions and keep track of the small successes you’ve booked. Find partners who share the same vision and build relationships with those who don’t.
