Scrum’s Sprints Are Not Mini-Waterfalls

Teams that have extensive waterfall development experience often encounter a common problem when they adopt an agile approach like Scrum. The problem results from applying waterfall development to every sprint. The result is a project consisting of a series of mini-waterfalls.

For example, let’s say the team selects 4-week sprints. It feels quite natural for them to break up each sprint into three phases. They do analysis and design during the first week (phase 1); spend the next 2 weeks coding and unit testing (phase 2); followed by 1 week of system testing (phase 3).

This approach can work if the software features are prioritized and each phase is strictly time-boxed. There also needs to be a strong definition of done and a willingness to not deliver features that are incomplete or defective.

Those rules are usually violated with the obvious consequence that the testing effort gets time squeezed. There isn’t enough time to test the new code nor to fix any defects discovered. Project timing becomes erratic as the sprints get elongated. Incomplete and defective features are delivered to the business. Everyone gets frustrated.

“We tried Scrum and it didn’t work!”

Well, not exactly. They tried an iterative waterfall approach, blended it with some elements of Scrum, didn’t follow either approach rigorously, and ending up failing. Surprise!

One of the reasons teams fall into this trap is simply because their stories are too complex. Any story that requires significant analysis and design is too big. It needs to be split up into smaller chunks so that analysis, design, coding and testing can all be completed within a few days, or at most, about two weeks (assuming 4-week sprints).

In addition, the stories selected for a sprint should vary in size and difficulty. If the team selects a small number of big stories for a sprint, testing is more likely to get squeezed at the end.

It’s also helps to get completed code into test as soon as possible so that there is time to fix defects before the end of the sprint. A strong definition of done helps enforce that discipline.

There’s nothing inherently wrong with iterative waterfall — just don’t call it Scrum.

Updated: July 11, 2011 — 9:43 pm