I am a huge fan of Donald Reinertsen’s book The Principles of Product Development Flow. Reinertsen draws on a diverse set of disciplines including Lean manufacturing, economics, statistics, queuing theory, control engineering, and maneuver warfare to create a set of principles to guide the product-development process and improve product-development flow.
One principle in Reinertsen’s book is Principle E8, “The Principle of Small Decisions: Influence the Many Small Decisions.” Reinertsen describes this principle as follows:
Many companies assume that the path to economic success lies in making a handful of big economic choices correctly. This leads them to concentrate decision-making authority at high levels and to design information systems that support this high-level decision-making.
While big decisions are important, this bias means that most companies have weak systems to ensure that the many small economic decisions are made correctly. Collectively, these small decisions have enormous economic impact.
Sadly, this is a blind spot for many modern managers who are heavily influenced by the concept of the Pareto Principle, which observes that 80 percent of the leverage lies in 20 percent of problems. The dark side of the Pareto Principle is that we tend to focus excessively on the high payoff 20 percent. We overmanage this 20 percent and undermanage the other 80 percent. This leads to what we might call the Pareto Paradox: There is usually more opportunity in the undermanaged 80 percent than in the overmanaged 20 percent.
I have been considering this principle and how it might apply to software architecture. In some ways, it seems to contradict software architecture being the domain of “big decisions.” To quote Grady Booch, “Architecture represents the significant decisions, where significance is measured by cost of change.”
However, the fact-finding interviews that we have been conducting on Agile architecture seem to bear out Reinertsen’s emphasis on managing the small decisions, especially in large-scale multi-team Scrum environments. Even when sufficient upfront analysis has been conducted to allow teams to operate in a relatively independent fashion, inattention to the small decisions can cause problems. Successful Agile projects foster ongoing inter-team communication to ensure architectural integrity. Some choose to have a central architecture team that works across concurrently executing Scrum teams. Others have embedded architects on each team that meet regularly in what might be called an architectural Scrum of Scrums.
The importance of managing the small decisions was also voiced during a debrief discussion that we conducted as part of our Hard Choices game session at the Agile Alliance 2011 Conference last week. One of the participants said that in “real life” (as opposed to the Hard Choices game), many decisions made at the individual level can end up having broad system impact. He referred to such decisions as “landmines” planted in the code.
So is it the big decisions or the small decisions that matter most? The answer I think is both. Paying attention to the big decisions is critical to ensuring that quality attributes are fulfilled and that multiple (and possibly distributed) teams can operate with a relative level of independence. However, failure to be aware of, understand, and harmonize the many daily small decisions can be dangerous, especially in large-scale projects or projects that involve a high degree of complexity or uncertainty. Such projects require engaged, embedded architects to ensure that agility and high-integrity, coherent architectures can coexist.
— Nanette Brown, SEI