Nov 04 2009
Efficiency is the enemy of effectiveness
Dan North gave a very inspiring talk at the Oresund Developer conference today, titled Our obsession with efficiency. His presentation focused on perceptions of efficiency and pitfalls of applying wrong efficiency models to software development. efficiency. Most efficiency is measured as budget/revenue, effort, time or activity and improvement efforts focus on these things, but according to North this is wrong.
“We get what we measure”, said he, adding that the system is going to game the metrics. “Does finding a lot of bugs really mean that you have good testers, or does it mean that you have crap code?”, asked North. He also mentioned several examples of how people game the system in software development, including commenting out failing tests to increase test pass rates and generating tests without assertions to increase test coverage. Improving the efficiency in these parts leads to inefficiencies on the global level. “When you focus on efficiency of a part, you lose sight of the big picture. [...] Efficiency is the enemy of effectiveness.”, said North.
Likewise, things that seem very inefficient can produce great effect on the global scale. As some examples of that, North mentioned cross-functional teams, pair programming, parallel spikes and the theory of constraints. Using a less controversial topic, he said that experimentation and innovation are very inefficient if considered on their own because they lead to lots of work that will necessarily be thrown away, but the global results of that are very effective.
North suggested that teams shouldn’t care about effort, but about the effect. Functional points, velocity, man hours and similar are easy to game and can lead to local optimisations that hurt the big picture. It is crucial to measure the correct thing and North suggests measuring cycle time for end-to-end customer satisfaction or cost of the end-to-end process, including opportunity costs and factoring in time.
So how can we improve the effectiveness? North suggests these pointers:
- Understand that you’re working in a system, and that it is likely that there is a system above that system and a system above that one
- Identify the goal of that system – sometimes it’s just its own survival
- Step outside to observe the effects – how well does its goal align with yours?
- Think about what’s stopping the system from giving you what you want, and improve that.
I’ll be posting many more articles on Oredev in the next few days. Subscribe to my rss reed to get notified about updates
 |
 |
i’ve been reading Don Reinertsen’s book….
http://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009
he talks about this in great deal with regards to product development and how we need to think about things like cycle time etc, but also how we need an economic model for decision making and that we need to normalise our other decision making tools against this model..
Hi Gojko,
Thanks for the great summary, I wholeheartedly agree. Being “on time – on budget” doesn’t really mean that you’ve done the right thing. Customer satisfaction is a moving target anyway, not every customer knows exactly how to be satisfied, and many times this is a discovery process. It just needs to be a conscious one.
Unfortunately, the more you step up in system thinking, the more likely you are to bump into hidden truths like “our company doesn’t really care for employee’s growth” or “we don’t really have any long term plan”. In my experience, system thinking applies really well in transparent organizations, but that’s also a measure of how healthy they already are. If you can’t think in such a way, you’re anyway getting an early warning about the environment you’re in…
Hi Gojki,
You mentioned Parallel Spikes, what is this? Is it a form of set based development?
two or more teams working to solve the same problem with different solutions in parallel, then choosing the best one.