Efficiency versus Effectiveness

January 30, 2011 at 3:44 pm | Posted in Agile | 10 Comments

I work as a consultant for companies that want to introduce Agile Software Development as a way to improve their software process. During an intake interview I always ask what they expect to gain from that and more often than not (about 90 % of the time) the customer’s first answer is that they want to improve the productivity of their IT department. Second in line is almost invariably the need for higher quality. But let’s stick with higher productivity first, because that is where the fun (please don’t interpret this as disrespect for my work or customers) starts.

My first reaction is pretty straightforward: “so what is your current productivity?”. I have never had an answer to that question apart from “we don’t know exactly, but it is not high enough” followed by remarks like “You are the expert, maybe you can do a baseline measurement.” My second question is mostly along the lines of “It’s ok that you don’t know your current productivity, but can you explain what you mean by productivity?”. And again I never get a clear answer. Sometimes a department has set goals like doing the same amount of work with less people: 20 % less people means 20 % productivity improvement to them.

The interesting thing is that when you talk to customers about productivity, they almost always talk about improving efficiency: more work done with less people, projects within time, budget and scope, etc. In other words, they mostly tend to talk about the costs, not about the benefits. From a historic perspective this makes sense: IT departments are often seen as cost centers. So the cheaper you can run your IT department, the better. This attitude ignores a couple of issues: firstly, IT is not just production work. It is about handling knowledge, interaction between people, etc. In his book ‘Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency’ Tom DeMarco argues that it doesn’t make sense to drive people up to 100 % efficiency.

But equally important, efficiency really isn’t that relevant. What really matters is effectiveness. How much money do you really get out of every dollar or euro you invest in IT. Cranking out more code per person month might not improve this at all. Productivity is all about the business value you can deliver. The interesting part is that there is a strong relationship between this definition of productivity (effectiveness) and efficiency. For three different types of companies I have shown this in the next graph:

If your IT department does standard production work then you can aim at high efficiency. Just like MacDonalds has an optimized process to produce hamburgers, you might do the same thing with your software. For example if you produce webshops in a limited amount of variations, you might want to go for 90 % efficiency. Higher than this hardly makes sense since you will always need some flexibility.

On the other side of the spectrum, if you are a start-up company or part of an R&D department, you need flexibility. By definition you need to trade a lot of your efficiency for the ability to handle risks (big opportunities and large risks come hand in hand). In this situation you should care about results, not that much about costs.

After the start-up phase, a company enters its maturing or consolidation phase. Efficiency can increase but you still want to maintain agility. Most IT-departments will have to handle this situation. Here you should go for 70 – 80 % efficiency and use the rest to handle risks, improve your effectiveness. In other words: concentrate on delivering business value at the cost of 20 – 30 % efficiency. An example of where I see this failing: many larger organizations have ‘optimized’ their software release process. Their IT department only releases twice a year because that minimizes the amount of work involved (never releasing would even be better, but that obviously doesn’t work😉 ).

These graphs have helped me many times while discussing productivity with customers. In putting this in my blog I hope they will be useful for others as well. Please let me know if you have improvements, criticism or other feedback!

10 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Another very worthwhile aspect is the business case of partial delivery. By delivering high-business value features earlier, the returns of the investment start flowing in while you complete other features on the long-list. Since your efficieny/effectiveness is perceived financially rather than in KLOC, this matters, a lot.

  2. Dan North has a great talk on this subject: http://www.vimeo.com/7849591

    • @Mike: thanks for the link. I talked to Dan North a couple of weeks ago when I visited the company I work for (Xebia), although we mostly discussed Clojure🙂

  3. Your explanation of effectiveness and efficiency confuse me. Productivity is ambiguous, but efficiency and effectiveness are too. I remember having long debates about this, mainly because of the ambiguity and connotations.

    Ok. So, why do you assume customers only care about cost? In my experience customers compare the delivered value to what it costs, which is logical in all companies at any stage of development. You should always get good (the right) value for money. Only in a start-up the risk and pay off are much different than a more settled company where there is lower risk (but also lower pay-off).

    When you say efficiency is not the main goal for all situations, what your probably mean is that you should not try to optimize the wrong process (I agree).

    However, efficiency is not a context-dependent goal. You should always be efficient, the nuance is in what you aim for. For instance a start-up must be very efficient at turning cash into learning and innovation. A more mature company might aim to be efficient in turning cash into user requested features.

    To summarize, both efficiency and effectiveness are always important. It’s doing the right things and doing them right. So in stead of aiming for one or the other, consider them complementary: productivity = effectiveness times efficiency.

    • It’s true that both are need to reach a perfect state. I think what Maurits was trying to get across is that you should firstly focus on effectiveness (it’s better to to the right things slowly than the wrong things fast), and then focus on efficiency once you have mastered effectiveness, and not too focus solely on efficiency.

      In a real world example it’s very easy to learn to code the wrong way, and quickly. Then before you know it you have a poorly written system to meet the costs/budgets set out, which in turn has additional future (and often unforeseen) cost implications around maintenance and modification.

      Both qualities are desirable, but I’d always favour effectiveness over efficiency. Pair programming is a classic example of where effectiveness triumphs.

  4. @Machiel, I’m not saying that customers only care about cost but in my experience it is the first thing they mention when I talk about Agile Software Development. This is partly due to the fact that most of the customers I talk to are responsible for their part of the organization. So what you get is a lot of sub-optimizations because of a strict focus on efficiency, which is after all the number most managers are judged upon: stay within your budget and you are doing fine.

    The point I try to drive home is that you should never aim for 100 % efficiency because that will have a negative impact on your effectiveness. You have to aim for the number that gives you the maximum result (effectiveness). So in some companies it might be wise to become less efficient to get better results!

  5. For the effciency vs. effectivity graph, where did this data come from?

    BTW, I really like the content of your claim. As a scrum master, I can see truth in some of the claims introduced.

    I guess this makes me think about our standard problems of measurement. As software engineerings, we want to measure stuff that makes sense.

    What do you feel are good measures of effectiveness?

    What are good measures for efficiency?

    • The data is based on a combination of my gut feeling and experience within many companies. No scientific backing yet. It very much depends on your company’s lifecycle and product what graph is applicable. To complicate the matter even further, both effectiveness and efficiency can be defined on multiple levels, ranging from individuals, teams and departments to complete organizations.

      In the end the only thing that matters is whether a company survives in the long run. On a project level I would define effectiveness as the business value delivered. Of course expressing single features in dollars or euros isn’t straightforward but it can be done.

      I want to elaborate on the multiple meanings of both effectiveness and efficiency (and how to measure them) in a next blog. Main goal of this blog was to present the graph that I use to convince customers that efficiency is just a small part of the puzzle and that it certainly shouldn’t have the main focus. Unless of course you are serving the same hamburger every time.

  6. Hey, I downloaded the GIMP#0.17, but I don’t know how to install it into gimp. Could you help me please?

  7. QuickLinks for August 2011…

    Here a quick list of articles I´ve read during the last month: An Agenda for Backlog Grooming Grooming the Product Backlog Angst kostet Geld und Führungskräfte sollten sich mit dem Thema befassen Who is Bob Marshall (flowchainsensei) ? The Clean Coder …


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: