Scrum Taught Us That We’re Doing Waterfall

Last week I spoke at the Pasco County .NET User’s Group here in Florida on Debugging .NET Applications with WinDBG and SOS. Afterwards we all met at a local restaurant and were talking about agile topics – the good, the bad, and the downright ugly. The leader of the group, Greg Leonardo then said a great statement that I immediately posted:

Scrum taught us one thing – we’re still doing waterfall!

The statement itself is actually not a knock at Scrum, or agile topics in general. It’s a realization said time and time again that you can’t just adopt some tools and practices and hope for the best. You have to be willing to change fundamental things about your organization – something that isn’t easy to do.

As an example, let’s say that you decide to adopt Scrum in your organization, and you utilize iterations, story points and burndown charts. You notice over time that your charts look something like this:

The red line is what the team “should” be accomplishing each iteration. The blue line is what they actually “are” accomplishing. The one thing you should notice (other than the two lines not meeting) is the shape of the blue line. It’s not smooth. In fact, it kind of looks stepped. Almost like the team is doing…waterfall!

That’s likely because they are. Each iteration things are not getting done, done, and so it builds up until a big batch is completed at once. Except that a batch is almost never completed at once. There are invariably bugs that crop up, and since code has already been built on that batch, the code has spread out further into the base, and takes more work to fix. Of course, the fixed code isn’t finished until the next batch, when more issues are found, etc, etc.

Worse, this kind of a stepped appearance to burndown charts is typically the graphical manifestation of a deeper systemic problem. And that problem is that change is hard, especially when the organization doesn’t really want to change.

If you are wondering if you are really doing waterfall inside of an agile methodology, you can ask yourself questions like:

• Have we ever talked about a “development sprint” and a “testing sprint” and an “acceptance sprint”?
• Has the phrase, “I had to stop work on Feature Z because the QA team found a bug in Feature Y I finished up earlier this week” ever come out on a stand-up?
• Can anyone articulate the vision, strategy or goal of what we’re doing?
• Are you using a burndown chart, but seeing it burn up?
• Are people surprised daily by the things that come up at the stand-up meeting?
• Is management surprised at the end of an iteration that things aren’t done?
• Does management even care that things are done during an iteration (as long as you darn developers get it done by the release!)?

I’m sure I could turn this into a funny checklist with scoring numbers where you could get a badge saying, “We’re Scrummerfallaristic!”, the fact is that it isn’t funny when you are in the middle of it. The good news is that once you recognize the challenge, there are lots of resources to help you. The book Fearless Change is a great start. Reading books like Lean Software Development, Implementing Lean Software Development and Lean-Agile Software Development are great ways to understand the challenges of batch processing and having a lot of work in progress, and how to go about fixing it. For Scrum specific information, Succeeding With Agile is one of the better books out there, but I highly recommend looking at a holistic view of your teams and your organization.

And when worse comes to worse, you always have the option to change your organization, or change your organization. But hopefully you can stop the stairs of waterfall and instead navigate the journey to the bliss of agility.