Iterative Waterfall Is Not Scrum

One of the more common anti-patterns in Scrum is treating each sprint as a short waterfall project. While there isn’t anything inherently wrong with doing that, it’s not Scrum. It’s Iterative Waterfall. If it doesn’t work, don’t blame Scrum.

There are similarities between Scrum sprints and waterfall iterations but they are not the same thing — not at all.

Software development teams using either Scrum or Iterative Waterfall can:

• Conduct daily standup meetings
• Timebox their sprints or iterations
• Allow change requests to affect future sprints or iterations but not the current one

These elements won’t operate identically for Scrum and Iterative Waterfall but the basic ideas will be the same.

What are the differences between Scrum and Iterative Waterfall?

1. Scrum teams start out with minimal planning and controls. They do just enough planning to get the development effort started. Once the software begins to take shape, they adjust as needed. Iterative Waterfall teams spend significant up front time analyzing and planning. Iterations don’t begin until the complete plan is in place.
2. The biggest difference is in the workflows. In Scrum, stories are worked from beginning to done. Thus any story may be in the Sprint Backlog, in progress, or done. In Iterative Waterfall, stories (or feature sets) all have the same status during an iteration. That is, they go through analysis, design, development, integration and testing as a group.
3. Team members have cross-functional roles in Scrum. They do whatever it takes to get stories to done. Waterfall imposes predefined roles such as analyst, architect, developer and tester. Documentation and code are passed from one role to another.
4. Scrum teams focus on delivering value to the business users at the end of each sprint. That goal may not be achieved on each and every sprint, but it is always a focal point. Iterative Waterfall teams tend to break up business requirements into chunks of work that are optimal for the development team. The business may not see working software until late in the project.
5. Scrum teams are self-contained and dedicated. They have all the skills needed to deliver the software. Iterative Waterfall teams are usually assembled from multiple corporate departments such as project management, software development, quality assurance, etc. As such, the team members have allegiances beyond the project team.

While I admittedly have a strong bias in favor of Scrum (and other agile approaches), Iterative Waterfall can and does work. It’s more agile than standard waterfall but it doesn’t fit any standard definition of agile software development. So, if you decide to use it, please don’t call it Scrum.