A Sprint is Not a Mini Waterfall

19 January 2012

When someone tells me, "A Sprint is mini Waterfall," I quickly respond, "No!" And I do this often, because time and again I hear this opinion from people who are new to Agile. I even hear it from teams who have been executing projects using Agile software development methodology. In this article, let's examine five reasons why a Sprint is not a mini Waterfall

1. Continuous design, development, integration, and testing 2. Cross-functional team members 3. No change in scope during Sprint 4. Time boxing 5. A strictly defined cadence

1. Continuous design, development, integration, and testing

The design, development, integration, and testing (DDIT) stage within a Sprint is a continuous activity, not the sequential process it is in a Waterfall project. The graphics below illustrate this difference:

Waterfall Project

Agile Project

 

2. Cross-functional team members

A Sprint group is one cross-functional team working in a dynamic, often fluid manner. It is not a set of different teams working separately and handing off work from one to another, as is the case with Waterfall projects:

 

Waterfall Project Team

Agile Project Team

 

3. No change in scope during Sprint

Waterfall projects define a rigid scope-change control process to manage any changes to work already underway. In contrast, Agile scope-change control, by design, is virtually nonexistent. This gives the product owner the flexibility to change his or her mind between Sprints. However, once the Sprint begins, the scope is frozen and no change request is allowed until that Sprint is complete.

 

Waterfall Project

Agile Project

 

4. Time Boxing

A Sprint is always time-boxed, no matter how the Sprint progresses. In the Waterfall world, if the project is behind schedule, the project timelines are usually extended. In the Agile world, the Sprint duration does not change–it is time-boxed–even if all the committed scope could not be completed during the duration of the Sprint. If, at the end of planned Sprint duration, there are scope items that are not complete, they are put back into the product backlog, prioritized, and made ready for future Sprints.

5. A strictly defined cadence

In a Waterfall project, the cadence cannot be defined up front. A Sprint, in contrast, always works on a well-defined cadence. The graphic below depicts a typical two-week Sprint cadence:

Sprint Cadence

These five characteristics of Sprint versus Waterfall project methodologies clarify major differences between the two. Don't let yourself—or your team—make the mistake of thinking that Sprint methodology is "just" a mini Waterfall.

Article Rating

Current rating: 5 (3 ratings)

Comments

Michael Buratti, CSM, 1/20/2012 1:56:15 PM
I agree with the article, but the problem is when you are on a big company with an waterfall mind, you simply cannot override the paper that you need to produce. I think that mini waterfalls is the middle of the way till a true scrum project. (the famous SCRUM BUT)
Robert Jackson, CSM, 1/22/2012 10:17:45 AM
So many projects are in a state of "water 'scrum' fall"........
Dick Carlson, CSM,CSPO, 1/23/2012 9:36:19 AM
I have heard people say that sprints are mini-waterfalls for years - even now I often hear people repeat this. The article points out the "Why" Scrum sprints are not. In a large company like Boeing, where I work, it is difficult to convince some levels of management and the large Systems Engineering organizations without contrasting sprints as mini-waterfalls, because of their complex gated processes that are tied to the DoD 5000 series acquisition regulation. This article provides specific arguments upon which to base my rebuttal against this ridiculous claim.
Will Stern, CSM, 1/24/2012 9:39:23 AM
Being in a big company myself, it is a definite truth that management and company leaders have to buy into the agile methodology for it to truly work as intended. That said, Scrum does not change in any way the amount of paper and documentation, it just creates them on-the-go, instead of all up front. Our BI documents end up just as thorough as ever, we just aren't bound by them...we create them, modify them, and adjust them as the product improves.
Paul Ciarfella, CSM, 1/29/2012 8:05:02 AM
The visuals in this article are great, clearly conveying the differences between scrum and the waterfall model to those just implementing scrum ... and especially to those who are implementing scrummerfall, waterfragile and scrumbut under the guise that they're agile.
MADHAVAN ELANGO, CSM, 4/3/2012 8:12:39 AM
Gr8 visuals! Pellucid explanation! Good attempt to clear out one of the famous scrum misconceptions - 'Scrum is a mini waterfall!'. Appreciate it, Chand.
Ambadi SL, CSM, 5/10/2012 10:06:15 AM
Excellent Article. It will take the understanding between scrum and waterfall in a better way. Thanks.
Rahul Jain, CSM, 7/13/2012 7:39:39 AM
I agree but on cross functional teams I find it very difficult to convince people to work beyond their functional expertise. The requets are mostly met with Tacit resistance and skepticism aroud "what about after the project".
Ulitimately its leaves the members working only on their functional expertise during the sprint.
Venkata Kotam Raju Poranki, CSM, 8/25/2012 11:46:38 AM
I agree with Chand.
Deema Dajani, CSP,CSM,CSPO, 9/8/2012 4:59:05 PM
nice job Chand, in debunking a common misconception!
Maria Elena Rodriguez, CSP,CSM, 9/10/2012 2:27:10 PM
I really like this article. In an Agile transformation environment it is important to deliver this message as often as possible. Good job!
Naveen Kumar, CSM, 10/13/2012 12:08:01 PM
This article is very well to help beginers who come from SDLC and new to Agile to understand the Agile approach in better way.
Makes the Agile Coaches job Easy.
Dele Oluwole, CSM, 11/28/2012 5:02:58 PM
Great article!

@ Michael,
Most big company with a waterfall methodology find it difficult to override the volumnous paper work they produce because they have not fully come to terms with the Agile practise/procedure. They still have the yoke of Waterfall around their necks in Agile environment. There is nothing like a ΓÇÿmini waterfall in the middleΓÇÖ. It is either you are into Agile or not ....
@ Robert,
No, scrum/agile project can ever be in a state of ΓÇ£water scrum fallΓÇ¥ .... the people working on a product mindset may be water scrum fall but not the product.
@Will,
You are very correct
@ Madhavan,
What exactly is your point?
Sure you are in the right forum?
@ Rahul,
If they are ready to work in an Agile environment they must be flexible
Eric Yang, CSP,CSM,CSPO, 2/19/2013 11:26:18 AM
I agree that a sprint is not a mini waterfall. It is mindset difference. I work with a big company and fortunately our senior management is very supportive. To me this is culture changes. My question is how can/should be improved to change this in many other companies?
Amit Kumar Singh, CSP,CSM, 2/26/2013 7:27:11 AM
Good Article !! This will help new CSM like me to convince many people who still has a mindset of understanding Scrum as mini waterfall.
Robert Carstons, CSP,CSM, 4/4/2013 5:54:26 PM
I think the illustrations are a great way to communicate the differences between waterfall and agile. Nicely done!
Rammohan Jayaraman, CSP,CSM, 5/3/2013 2:41:33 AM
Excellent Article. Also, would like to add that by limiting the number of WIP items, it helps to avoid mini waterfall within a sprint.
Balaji C R, CSM, 11/20/2013 5:47:21 AM
Excellent article which makes distinct clarity on waterfall and Agile methods.

You must Login or Signup to comment.