We need to talk about efficiency
Ok, for a start I purposely didn’t put the word ‘Agile’ in the title because… errrr… because Agile efficiency just isn’t a thing yet. But now that I think about it, give me a second to trademark it. Ok, and now back to the topic at hand.
Why do we need to talk about efficiency?
Because the discussion on efficiency, behaviour targeted towards efficiency and metrics on efficiency are the bane of most Scrum Teams I meet. Hands up if you’ve ever seen or fallen victim to one of the following:
- Reporting Velocity outside of the team.
- Reporting planned vs actual Velocity inside (or even outside) of the team.
- Making sure you have enough work to completely fill up a Sprint.
- Reporting the amount of Product Backlog Items delivered each Sprint (bonus points if they’re all User Stories).
- Making sure everyone is ‘utilised’ enough. Or ‘billable’ or some other form of ‘are you busy enough?’ metric.
Ok, put you hand back down. I was going to ask you if this has ever helped anyone, but I already know the answer to that question (It hasn’t).
In the next three parts of this article, I’m going to tell you why people are interested in efficiency, why it isn’t telling you what you think it’s telling you, and what you should be interested in instead. Let’s go!
Why do people care about efficiency?
Short answer: They don’t. It’s a proxy for what they really care about.
Long answer: So a lot of thinking on work comes from the production industry. You know, stocking the shelves, building the cars, etc. Simple work. Predictable work.
Thing is, if you’re gonna be producing 10.000 cars (value) you want to do this at the lowest cost while maintaining quality. So let’s fix quality and minimise costs. Lean teaches us that gains are most easily achieved by reducing the amount of non-value adding activities. Also known as the 8 types of waste: Defects, Overproduction, Waiting, Non-Utilized Talent, Transportation, Inventory, Motion, and Extra-Processing. Notice by the way that “people” isn’t one of those. Anyway, by minimising these the process becomes more efficient and so delivers more value for money. Add to this that people being more active literally translates into more of the valuable thing being delivered, so it makes total sense to fully utilise people. Because Waiting and Non-Utilized Talent are wasteful. (Though non-utilised talent means something else then the narrow definition of utilization as 'being busy').
To summarise: More efficient == more effective. Any sane company cares only about effectiveness. Efficiency is just a great proxy.
Why efficiency isn’t telling you what you think it’s telling you
Short answer: It fails to function as a proxy in a complex context.
Long answer: So complex work, or creative knowledge work, is different from simple work in two big, big ways:
- You never, ever, ever, produce the same thing you did last time.
- The amount of work done is not related to the value of that work.
Well shucks. If you’re not going to produce the same thing, the process you’re using is also going to be different, even if only slightly. So forget about process improvement, the name of the game is process adaptation. Standardisation has an almost opposite effect now. Whereas before standardisation increased effectiveness in delivering the same thing, now standardisation means committing to a way of work suited for a product you built once and never will again.
And then there’s the uncertainty. Basically, that something seemed a good idea a month ago doesn’t mean it’s still a good idea now. Maybe your customer just didn’t really know what they wanted? Maybe you competitor already has a better solution for a customer requirement? Maybe new legislation makes the feature more expensive to maintain, or even illegal? Maybe Trump did a, I don’t know, something Trumpy? As I said before in my ‘We need to talk about requirements’ article, all we really have is assumptions. Sometimes something we built isn’t being used. Sometimes the smallest, simplest feature turns out to be a game-changer. In a fast moving market, where we do creative knowledge work, effort and value are very loosely coupled, if at all.
What you should be looking at instead
Actually you’re going to look at the same thing you were looking at initially, but without the proxy. Effectiveness. How happy is the customer? Are we getting more of them? Are they paying enough to cover our costs and growth? Is the product working properly? Are we spending less in maintenance? Are we quick enough in meeting the customer’s needs and wishes?
Now this is going to be challenging. Often organisations have been so focused on measuring efficiency under the assumption that that covers effectiveness, that once you start looking for the latter it proves to be incredibly hard to get any data. The proxy has become so ingrained, so easy to use, that most organisations have forgotten it is a proxy.
And yet you must, if you want to get back some control on value delivery. Find the things your customer is willing to use (and pay for, if you’re a for-profit). Trace the evolution of customer needs and wishes to realised features, products, things. Build your organisation (or organisation of organisations preferably) around these things. Empower people to continuously meet and exceed the customer’s expectations. Measure your success by measuring the outcome.
Moving forward
Ehm, right, inspiring ending… Oh yeah! Here’s one related to a topic I tend to discuss in my Professional Scrum Product Owner class and leadership classes.
I’m going to give you some homework. Your mission, should you chose to accept it, will consist of 2 parts:
- Find a Product (aka a solution offered to an external (I can’t believe I have to use that word, but that’s another article) customer) and find out how much you’re spending a month on that Product and only that Product. Sales, support, development, operations, the works. Really tear it loose from the rest of the club. Now find the ROI per month. Look back 12 months. We’ll do just Profit/Loss for now to keep it simple.
- Compare the numbers to whatever efficiency metrics you have on that Product during the same time period. Does it hold as a proxy?
Good luck! And let me know what you find.