08Architecture without an owner

Two slogans did a great deal of damage: "business value first" and "no big upfront design". Combined with a horizon limited to the current sprint, they explain why so many Scrum codebases become brittle, accumulate debt quickly, and eventually slow delivery to a crawl.

A reaction against big design, misread as a rejection of design

"No big upfront design" was a reaction against months of design documents produced before any working software. It was never a rejection of design. The Agile Manifesto's ninth principle states that continuous attention to technical excellence and good design enhances agility. Its eleventh, that the best architectures emerge from self-organising teams, is the one most often misread. Emergence was meant to be deliberate work, carried out continuously.

In Extreme Programming, giving up upfront design was paid for with engineering disciplines: test-driven development, continuous refactoring, simple design and continuous integration. Emergent design works only when the code is constantly reshaped. Scrum, by contrast, is a management framework and says nothing about engineering practice. It was widely adopted without those disciplines. Martin Fowler described the result in 2009 as "Flaccid Scrum": teams adopt the process, neglect the technical practices, and slow down as the codebase deteriorates. The criticism comes from inside the agile movement, from one of the Manifesto's signatories.

Enablers and spikes

Early agile practitioners recognised that technical work needed its own place in the backlog, and two kinds of item emerged. They are often confused.

• A spike, a term from Extreme Programming, is a short, timeboxed experiment to reduce uncertainty: can this library handle the load, how does this protocol behave, which of two approaches works. Its output is knowledge, and the code is usually thrown away.
• An enabler, or technical story, builds a lasting capability: the deployment pipeline, the data layer, the authentication framework. Its output stays in the product. Scaling frameworks such as SAFe later formalised enablers and the "architectural runway" they create.

Many teams labelled both as spikes. Real architectural work was then treated as temporary exploration, and some spikes turned into open-ended research with no deadline.

It was also common practice to reserve a share of capacity for technical work. In France, Claude Aubry, one of the early advocates of Scrum, recommended in the first edition of his book Scrum (Dunod, 2010) devoting around a quarter of the effort of the early sprints to it. Over time that reservation tended to follow one of three paths. It eroded, because a fixed percentage has to be defended every sprint against visible features. It went underground, with technical work quietly absorbed into feature estimates, keeping some of it alive but invisible. Or it became a tax, a flat percentage applied regardless of risk, when the right amount varies widely between the start of a product and a stable one.

The structural bias of "business value"

Enablers are often described as carrying no business value. More precisely, their value is indirect and deferred: they reduce risk, lower the cost of future features and keep delivery speed sustainable. When a backlog is ordered only by visible business value, enablers lose every prioritisation contest. A Product Owner rewarded for features will rationally starve the architecture. The problem is not that teams forget design; it is that the prioritisation mechanism systematically ranks design below features unless something counterbalances it.

Debt and the slowdown curve

Ward Cunningham, another Manifesto signatory, introduced the technical debt metaphor in 1992. He described a deliberate loan: shipping a simpler design to learn faster, with the intention of repaying it through refactoring. Most teams keep the borrowing and drop the repaying. Fowler's Design Stamina Hypothesis (2007) describes the consequence.

Teams that work below the payoff line can legitimately trade design for speed, for a prototype or a short-lived product. Most products live far longer than that. In the absence of an owner for technical coherence, which Part I identified as the weakest point of the redistribution, the team crosses the line without noticing, and the slowdown is then blamed on everything except the architecture.