We human animals naturally think about what’s right in front of us. We focus on the here and now. This served us well enough when life was simpler. But actions also have effects we don’t usually consider very well, either due to time – because they happen later on – , or distance – they affect people or things we don’t often interact with.
Craig Larman and Bas Vodde call this blind spot local optimization bias:
the tendency of actors within a complex system to do the ‘best’ thing in the confines of their own duties and roles, without understanding the larger impact of their choices and actions, or ignoring higher-level goals of the system.1
The following video illustrates local optimization in a typical organization. A supervisor instructs workers to prevent any unwrapped chocolate from getting past them into the next room. They mostly succeed. But in the long run and in the big picture, optimizing locally harms the business, its employees, and its customers. The video is supposed to be funny, but I want you to take it seriously because similar things happen every day in your own company.
During the 1980’s I had a brief stint in an IT department. Our IT department was actually called Information Services & Control (IS&C). One of my responsibilities was to prevent engineering teams from buying the tools they wanted to use because we could bulk purchase slightly cheaper alternatives that were “almost as good,” or force people to use our unwieldy Univac mainframe. This is a reasonable argument that could be right in some cases.
My boss produced reports for his boss showing how much money we’d saved the company. Those people probably all retired thinking this was the right thing to do. But today I realize what I did to save pennies was actually harmful in the big picture. Penny wise, pound foolish is an example of local optimization bias.
People who only look at the numbers are the worst of all.
– Taiichi Ohno
Beginning Scrum Masters, including some book authors, focus on trying to make “hyperproductive” teams instead of helping the product development organization become better able to learn and adapt.
A person without a deep understanding of software development might assume that large scale agility comes from summing the work of multiple “hyperproductive” teams. It seems logical at first glance. Shouldn’t faster horses pull the wagon faster? But you, gentle and wise reader, know that software development is not like horses pulling a wagon. In the big picture, everyone trying to be hyperproductive will produce a God-awful mess, not a faster company. We will not out-learn our competition this way. A locally-optimizing Scrum Master is the enemy of large scale agility.
Craig Larman Elaborates
Neal Peart (also from Canada) elaborates
Wheels within wheels in a spiral array
A pattern so grand and complex
Time after time we lose sight of the way
Our causes can’t see their effects.
Japanese version: 局所最適化バイアス：今ここで 対 後にどこかで
Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large Scale Scrum, Larman/Vodde (2010) ↩