Software Complexity Dimensions

Definition

Schwaber identifies three independent dimensions of complexity in software development. Requirements complexity arises because customers don't fully understand their needs until they see something built, and because stakeholders have conflicting priorities that change over time. Technology complexity comes from using advanced, often unreliable tools and from the fact that interfaces between multiple pieces of technology are more complex than the components themselves. People complexity emerges because team members have different skills, intelligence levels, experience, and viewpoints—and because their motivation and effectiveness vary day to day based on health, mood, and external factors. These three dimensions interact multiplicatively: when all three are high simultaneously, the project enters the chaotic zone where traditional planning breaks down.

In the Book

Schwaber illustrates this with a two-dimensional graph (Figure 1-1) plotting requirements complexity against technology complexity, noting that the people dimension exists independently and multiplies the difficulty. He argues that "almost all of today's software development projects are complex. Those that are chaotic are unworkable, and some of their complexities must be resolved before work can progress."

He notes that no project is truly simple anymore. His last "simple" project was in 1969 when one person from Sears asked him to sort cards on an IBM 360/20. Since then, "things have only gotten messier." Every software project now involves multiple stakeholders with different goals, multiple technologies that must interoperate, and multiple people with different expertise and motivations.

Because of these three interacting complexities, it is impossible to predict the course of a project in detail. Schwaber explicitly rejects the premise that better upfront planning can solve this: "Complex problems are those that behave unpredictably. Not only are these problems unpredictable, but even the ways in which they will prove unpredictable are impossible to predict."

Why It Matters

This framework explains why traditional, plan-driven project management fails in software development but succeeds in manufacturing or construction. In manufacturing, requirements are stable (the product is specified), technology is reliable (tools have been tested), and labor is fungible (workers follow procedures). In software, none of these hold. The framework justifies Scrum's investment in frequent inspection and adaptation: if complexity is irreducible, the only way to succeed is to learn by doing and adjust continuously.