This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Scrum Is Effective, Not Efficient
I’d like to rant a little bit on something that I find prevalent in the teams that I coach and in the classes that I teach. When I talk to people about Scrum (and agility in general), I invariably hear things like, “I’d like my teams to be more efficient”; “We’re using Scrum so that we will be more efficient”; and, of course, “We’ll be more efficient with this process and save some money, right?”
The answer is “no” or “not right away,” and this usually leads to a conversation about effective versus efficient. By definition, effectiveness is “producing a powerful effect,” which in software means that we deliver something useful to the business. Efficiency, on the other hand, is “producing results with little wasted effort,” which is a completely different thing and is a totally non-agile concept.
Now, let’s look at what businesses usually do. (Remember that you are what you actually do, not what you say you do) In my experience, most businesses are in the business of “keeping their people busy” rather than in the business of “producing product.” That is, managers get in more trouble for their people “wasting time” than they do for their organizations not producing the right product. This is a shame.
Agility is all about “inspect and adapt” cycles, or feedback. The more feedback that you have, the more effective you’ll be, but the more effort you’ll be spending. This is inherently inefficient — we are sacrificing efficiency for effectiveness on purpose. In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?
This is where we get phrases like “fail fast, fail early,” which is a way of saying we like to be efficiently agile by learning our lessons as fast as possible. Okay, I wouldn’t mind being efficiently agile, but I’d much rather be effective than efficient. And, in my view, it doesn’t do any good to even try to be efficient until you already know how to be effective. That is, if you can’t produce the right product every time (or virtually every time), then don’t start adding efficiencies to your process.
To put it quite simply, “waterfall is efficient — agility is effective.” When we try to be efficiently agile, we often wind up introducing false predictability into our process that winds up hurting us in the end.
Enough for now, just my two cents, Dan
Dan Rawsthorne, PhD, CST
Download the PDF version: Scrum Is Effective, Not Efficient blog