Scrum is a very inefficient framework

Yesterday I talked to several people about a workshop they had and efficiency came to realize that some tend to hammer on efficiency as something very relevant, although not using the word itself. It might even be the number one reason why people don’t understand Agile completely.

Except from an excellent presentation given by Dan North I could not find any article where Agile / Scrum and efficiency is thoroughly discussed. On other hand, there is a lot of stuff about this from Lean perspective.

Efficiency vs. Effectiveness

Just to make sure we understand each other:

  • efficiency = the ratio of the useful work performed by a machine or in a process to the total energy expended.
  • effectiveness = the degree to which something is successful in producing a desired result

The first one is about time well spent and the second about getting right results or doing the right thing. These seem not mutually exclusive in Scrum, but they are.

Why is Scrum inefficient?

Actually, most of the stuff in Scrum is inefficient. Think about pair-programming, decision making by whole team, retrospectives, product backlog grooming, open spaces, and so on. It is much more efficient to spend everyone’s time writing code instead of having all these meetings and other stuff. You might even hear some developers complain about these meetings. Mainly in the beginning, while experience with Scrum is still lacking.

Efficiency is irrelevant

As long as a team keeps delivering high quality desired product and keep improving their effectiveness, I don’t care if they spend most of their time chatting instead of coding, most of their time experimenting, spiking multiple solutions for the same problem, playing games, reading Reddit or laying on the beach every sprint. If team feels that enjoying the beach every sprint will improve their effectiveness by getting extra D-vitamins from sun and a nice cocktail, they should certainly do that.
One more time, effectiveness means achieving your goal as good and soon as possible. So, what exactly will go wrong if you’re still inefficient as hell? Nothing!It is sad to see that most managers today know so much about measuring efficiency and so little about measuring effectiveness. Measuring effectiveness is about measuring how well the products or services meet customer needs / requirements. Also, how well did we hit the stop of to be achieved goal.

Going for efficiency is bad

It is not that being efficient is bad. In contrary, it is very good that people spend their time well. That is something personal. The problem is that we, on bigger scale than personal, tend to forget effectiveness when talking about efficiency. We don’t see contradiction with effectiveness – which is far more important-, because it is often so difficult to see. An example:
A: “We spend too much money making architectural decisions in those long and frequent sessions. Maybe only architect and product owner should take all those decisions.”
B: “Do we keep getting the best / simplest decisions when only architect and product owner takes them?”
A: “No, but it’s more efficient…”
B: “How much time does everybody spends understanding and accepting those decisions afterwards? How much time do we spend controlling and discussing that decisions are enforced and correcting them afterwards?”

In other words, when seeing a big picture, at the end, it is sometimes not even efficient to go for efficiency and it is certainly not effective. Going for effectiveness, on other hand, can sometimes also be very efficient.

5 thoughts on “Scrum is a very inefficient framework

  1. Great post Victor, to me efficient is more related to factory like repetitive work which in essence does not match with any form of creativity like creating new functionality. I think you have nailed it to effectiveness, in the sense of delivering the right business support when it's needed. It's not about quantity, it's about quality.

  2. Viktor, your post reminds me of something Mary Poppendieck said in a tutorial at SATURN 2013 I attended last Friday: "utilization is the most ridiculous metric possible for a development team". (your definition of efficiency is what's usually called utilization). This comes from basic queueing theory: depending on the size of the batches of work, pushing utilization upwards will decrease throughput to zero. If the batches of work are large, this effect will start at utilization over 50%. "Fully utilized highways are called parking lots".

Leave a Reply

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

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

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.