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
Transformation Coach
dan@danube.com

Download the PDF version: Scrum Is Effective, Not Efficient blog

Posted in Agile
4 comments on “Scrum Is Effective, Not Efficient
  1. Renato Willi says:

    Dan,

    I don’t think any of us is in position of talking about efficiency or productivity now (although I believe we should keep trying). Beeing efficient or productive is “to produce more with less”. But how do we know how much are we producing? We can’t measure it, can we?

    All the metrics we try have lots of failures, like lines of code (that doesn’t consider that reuse would be a good thing), or Function Poits/Use Case Points, in wich one FP or one UCP is different from another, and varies in size deppending of as many factors as we can count…

    We don’t know that! And neither do others!

    So, I agree with you about Effectiveness, and so far I can’t agree at any efficiency improvement argument, unless some new metric widely used is accepted and convinces me.

    That was my penny! 🙂
    Willi

  2. Michael James says:

    I just saw a motivational poster from an old manufacturing plant that says “Quality Control Means Build It Right The First Time.” Factories can emphasize efficiency because they (should) know exactly what they’re building.

    If Thomas Edison knew beforehand that tungsten would work as a durable filament, he wouldn’t have needed so many attempts to get it right. This would seem inefficient to a man of less vision and courage.

    –mj

  3. Jase says:

    Hello Dan,

    What you say is very interesting, but I don’t follow fully and it gives me some questions.

    You say: “The more feedbacks you have the more effective you’ll be… and have as few feedback loops as possible. And we don’t know how to do that, now do we”

    I think the amount of feedback is not so important to determine the effectiveness, what is more important is the quality of the feedback which is alligned with business goals. Can’t a few good feedbacks be enough to know how effective you are? You can specifiy some quality scenario’s for measuring your effectiveness. Ofcourse lines of codes or function points are to vague and don’t tell much business/product relevant effectiveness. Finding the right feedback through quality scenarios can help to reach the effectiveness efficiently instead of going for a lot of feedback.
    Maybe it is not easy to specify precisely what needs to be done, this is where agility comes into the picture i think, but in general every project has some clear business (case) goals and for those quality scenarios can be provided to measure the overall effectiveness.

    You say: “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?

    If you can specify how to be effective, and you say that agility is effective it means you can specify effectiveness, than you can specify a way to reach it efficiently. I think too that agility is effective and i would measure it with quality scenarios. This also gives the possibility to have a reduced set of feedbacks related to the Q scenarios and allow us to get there efficiently because we now our goal.

    You say: “…if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.”

    Why can’t you add efficiencies in your inspect and adapt cycles? Rethinking and implementing the way to produce a powerfull effect can also ask for incorporating some efficient steps.

    You say: “waterfall is efficient — agility is effective”.

    I think if you say it is efficient, it means that it has to be also effective. Saying something is efficient means its result is effective. So in your conclusion waterfall is the ultimate way to go(?)

    Many Grtz, 🙂
    Jason

  4. Dan Rawsthorne says:

    A quick comment on Jason’s comment “if you say it is efficient, it means that it has to be also effective.” I completely disagree! Being efficient means that you did what you intended to do very quickly, with minimal resources. Being effective means that what you did is actually useful or “fit for use.” This is like the difference between verification and validation.

    Agility is a strategy, not a plan. You can certainly add efficiencies to your strategy, and this will probably make you more effective. It will not necessarily lead to an efficient implementation, however. It may actually make thing less efficient, by adding more feedback loops, for instance.

    Just sayin’
    Dan 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

*