INTRODUCING OUR CERTIFIED AGILE BOOTCAMP FOR UNDERGRADUATE STUDENTS & YOUNG PROFESSIONALS

Toggle Menu

Insights > Agile Transformation > Waterfalling the Sprint: Why It’s a Problem, How It Happens, and How to Stop

Waterfalling the Sprint: Why It’s a Problem, How It Happens, and How to Stop

What is waterfalling the sprint? I recently received a question from a former student that expresses a struggle that a lot of Agile teams deal with shortly after transitioning from waterfall patterns: I have been a part of scrum teams in various forms. There seems to be a struggle with allowing time for testing to […]

By

June 29, 2020

What is waterfalling the sprint?

I recently received a question from a former student that expresses a struggle that a lot of Agile teams deal with shortly after transitioning from waterfall patterns:

I have been a part of scrum teams in various forms. There seems to be a struggle with allowing time for testing to be done during the sprint.  For example, in a three-week sprint is there a recommended cutoff time for all development to be done such as after two weeks or is it more fluid? What we seem to happening at my current workplace is testers are receiving things late in the Sprint which crunches them at the very end.  Do you have any mitigation strategies so that we’re not throttling the testers at the end?

The phrase that describes this pattern is “waterfalling the sprint.” The team appears to be planning and executing sprints, but inside of the sprint timebox they still handle all of the phases of work as discrete, siloed steps. A team that’s waterfalling their sprints might think they’re going to do something that looks like this while trying to build backlog Items ‘A,’ ‘B,’ and ‘C’ in a 10-day sprint:

         Well…that’s the plan, anyway.  Instead what typically happens is this:

Why is waterfalling the sprint a problem?

Throughout the sprint, people thought of as ‘testers’ are sitting around, while people thought of as ‘developers’ build all three items. Development takes longer than expected, leaving only minutes at the end of the sprint for validation and delivery tasks, most which won’t happen. The net result is that none of the items are fully tested, let alone delivered to a production environment. Now, any remaining testing and delivery tasks will roll over to the next iteration, while the ‘developers’ tackle new backlog items. From this point on, the team is in a continual pattern of bouncing between starting new work and fixing newly discovered bugs in old work that they thought was done already.

There are a bunch of background conditions that lead to waterfalling the sprint, which are also issues with team health in their own right.  Some of the most common are:

How can you help teams stop?

So how can we help teams stop waterfalling their sprints?  Most of the time, I recommend teams start with trying two new patterns:

This pattern reinforces that the team collectively owns all of the work in the sprint (especially if they’re also willing to trying pairing/mobbing/swarming behaviors), and helps show that what matters within the sprint is ‘done items’, not busy-ness.  And, if nothing else, even if they run out of time before they finish ‘C,’ at least ‘A’ and ‘B’ are complete to a point of actual value!

 

You Might Also Like