≡ Menu

Scrum Taught Us That We’re Doing Waterfall

We're Scrummerfallaristic! 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:

Burndown Chart 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.

Comments on this entry are closed.

  • abby, the hacker chick blog February 15, 2010, 8:45 am

    Great post! I agree that one of Scrum’s greatest strengths is that it can really make our problems visible – but I also think sometimes people don’t even realize that things are problems (“isn’t this just how it always works?”) so the list of questions is really great.

  • Katie McCroskey February 16, 2010, 9:43 am

    I found your blog post “Scrum Taught Us That We’re Doing Waterfall” unique because to me it sounded like you are reinforcing the idea that just any team calling themselves Agile, is Agile. In my experience, to really be Agile takes discipline and constant improvement to processes. Not finishing things during an iteration is not acceptable to our team or product owner. Where are the retrospectives that ask – Can we not get everything done because of impediments or are we taking on too much? Your recommendation to take a holistic view is on point, but I think the missing ingredient is the discipline to adapt. Changes to truly become Agile must be made by team effort and the ability and support to adapt and the discipline to follow through is key.
    This post is now featured on AgileShout.com because it made me think. Thanks!

  • Mark Simpson March 8, 2010, 11:48 pm

    I really appreciate that quote.

    As I’ve said, I’ve learned “Agile” all wrong. But the ONE thing that it did right near the beginning of my first project with “XP” (big quotes around that) was the small additional _transparency_ it gave. No longer could we developers hide behind our long schedules (which was quite scary really). We, as a team, could see when things were working and when they were not.

    Two failings we had, was that even though there was this transparency, there was still ignoring of the problems, and new ways to hide the problems.

    The new project has started, and we are again doing “Agile”, I’ll bring your questions with me and hope I can made some positive change (me and/or the corporation).

    Thanks for this post.

  • Alexandre Reis March 14, 2010, 6:56 pm

    Hey Cory,

    Just wanted to step in to say that burndown charts shaped like the one might not only mean that the team is getting batches of work done at a time.

    I have seen this chart during the initial stages of a project’s development due to technology adoption occurring gradually.

    On my current project, we have had a similar chart on our first iteration, because we tackled first all tasks that involved familiar technology – JMS and Java programing – then moved on to somewhat familiar – EJBs and JPA – to completely unfamiliar – BlazeDS and Flex.

    At every step of those changes in technology focus, we had a irregular slope on the curve, and I find that it is a natural thing, since each technology has a learning curve, and that is well represented on the burndown.