SCRUM-fall, waterfall in little pieces - whatever you call it, it infects Agile teams with alarming frequency. Agile-turned-waterfall seems to follow one of two patterns:
Waterfall within the sprint: This happens when research and additional requirements gathering occurs first in the sprint. Next, the stories are handed to development, who then move the stories to testers in the final days of the sprint. You may be experiencing this if your testers are idle, then slammed, and you never seem to have enough time to fix what they’ve found within the sprint’s boundaries. You’re often pretending things are error-free during your sprint review demos, or you have trouble closing stories because of unresolved test defects.
Waterfall across sprints: You are experiencing this when you do your requirements and wireframes in one sprint, develop them in the next sprint, and test them in a third sprint. You have sprint reviews with no demos because it was a “requirements sprint.” It often makes sense to do research spikes and design ahead of the sprint, but going too far in that direction can cause the team to deliver a large chunk of working, tested features every two to three sprints instead of delivering smaller chunks of working product at the end of every sprint. This also means that you’re getting less customer feedback, you may lose speed to market, and most critically, you may find yourself unable to quickly pivot.
I’ve been on SCRUM teams that experienced both of these dysfunctional manifestations of waterfall within Agile. Recently, I learned a why this happens, and how to stop it.
Story Size & WIP Limits to the Rescue
First, the team’s stories are probably too large. It might not seem like it, but they are. No single story in the sprint should take longer than a day or two to develop, test, and close - all inclusive. Where I work, this means that nothing should be greater than 3 points at most, with most stories at 1 or 2 points. Smaller stories move through the workflow faster, enabling testers to begin their work earlier in the sprint, and giving developers more time to resolve any issues that were found.
To make this even more effective, the team should institute work-in-progress limits (WIP limits) for each team role. This means that you set a limit on the number of open stories for development and test. If you’re at the WIP limit, one story has to move before a new story can open. For example, if development and testing both have WIP limits of 4, and both roles are at their WIP limit, then development must move one story into test before opening story 5, and testing must resolve a story before they can accept the new story from development. This encourages the team to move work through the pipeline, and also reduces time lost due to task-switching between many open stories.
Though writing smaller stories and adhering to WIP limits will be difficult at first, it’s one of the best ways to break teams out of accidental Agile/Waterfall.