Are Scrum and Waterfall The Same?

I’ve gone back to watch Uncle Bob Martin’s presentation “Agile overview” from NDC 2010 (while you’re at it check his “The land that scrum forgot”, the man is such a storyteller!). In the presentation, Bob tells about Winston Royce’s study “Managing the development of large software systems”, from 1970. This article is the origin of the waterfall methodology, although the word waterfall does not appear in it.

Here’s Royce original waterfall diagram:

Royce saw the waterfall method as an ideal, and you maybe surprise to learn that he recognized it won’t work in practice (see the first sentence under Figure 2). Not only does he say so in this very article, he also explains why:

Royce identified the feedback loops that make agile so powerful. He noted them however as obstacles to the flow of the waterfall.

That’s all history, of course. Apparently, too many people didn’t flip to the next page, to see who the killer of billions of dollars was. What possessed so many in our industry to follow a model that even its parent says is flawed?

I don’t know the real answer (if you do, let me know!), but I do have a theory.

The waterfall model is simple, and understandable to common people. And by common I mean regular business people. It’s easier to wrap our mind around the simple (yet flawed) waterfall model, than accept and deal with the actual interruptions caused by real life.

Come to think about it, this is similar to another model that is winning the hearts of many people: Scrum. Scrum is now the agile method of choice in mainstream. Scrum is easily understandable by business people, since its based on familiar processes, and doesn’t require understanding of geeky development practices.

What do you think? Why did waterfall succeed? Is scrum destined for the same fate?

Velocity: Agile Killer or Unsuspecting Mark?

Jim Highsmith recently wrote about “Velocity is Killing Agility”. Velocity was originally used as a planning tool. You measured velocity in the past, in order to see how much throughput you’ll get in the future. If we put it very simply:

Throughput = Capacity x Velocity

Now, as Jim describes in his post, velocity has turned from an observed (immutable) value to a goal, that can be tweaked.

And I ask: Why is that a surprise?

For years, we’ve been taught that “if it can’t be measured, it can’t be managed/controlled/[insert your favorite activity here]”. Business organizations still want an answer to the question: When will it be ready? And if your team has gone agile on you, you try to get what you can. Can’t get an answer? Measure a proxy,.  And once you have a proxy, i.e. velocity, you can build a plan how to improve it.

What do you mean “you can’t change” velocity? Sure you can! Better computers, better people and less coffee breaks and see how your productivity, I mean, velocity jumps up. Don’t believe me? I’ll show you next month, we’re measuring it!

Sure, velocity was not meant to be used like that. But that’s how it used today, as a translation proxy between the dev team and the business. It’s not killing agile, it’s adapting it, translating the agile lingo into business-speak.

History has taught us that sometimes what people invent ends up being used differently than how they imagined. I guess that’s where our dearly beloved velocity went.

My advice: don’t worry about it. What you should be concentrating on is producing high quality software features out the door. Management wants to improve your velocity? Don’t throw the idea out the window. There are always better ways to improve your output, individually and collectively. Improved productivity leads (eventually) to an improved velocity.

Frankly,  that’s a win-win situation, if I ever saw one.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More