When I develop software, I build a logical set of instructions that send signals that control a machine in its interactions with other machines, humans, or nature. The level of precision required for successful software ranges from the incredible to the truly daunting. Anything can be complex. When complex things interact, the level of complexity goes through the roof. I’ve limited my enumeration of complexity in software development to the three most significant dimensions: requirements, technology, and people.
It is possible to have simple software requirements. A single customer who is the only person who will use the system can spend enough time with the developer that the two can agree exactly what to build. Assuming that this customer dies immediately after imparting his or her requirements, the requirements will remain constant, and there will be no changes, revisions, or last- minute modifications. More commonly, there are many stakeholders (those with an interest in the software and how it works) who have different needs and whose needs frequently change and are difficult to articulate. In most cases, these customers only really start to understand what they want when they are provided with someone else’s impression of what they want. Theirs are complex requirements because their requirements are not only ambiguous, but also constantly changing.
Simple technology exists, but it is rarely used in software development. One might define software development projects as the application of advanced, often unreliable technology to solve business problems and achieve competitive advantage. To compound the complexity of technology, more than one piece is usually employed, and the interfaces of the many are far more complex than the complexity within any single piece.
In Figure 1-1, the vertical axis traces requirements complexity, and the horizontal axis traces technology complexity. The intersection of these two kinds of complexity defines the total level of complexity of the project. 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.
The third dimension of complexity is the people developing the software. They all have different skills, intelligence levels, experience, viewpoints, attitudes, and prejudices. Every morning, each wakes up in a different mood than the day before, depending on his or her sleep, health, weather, neighbors, and families. These people then start to work together, and the complexity level goes through the roof. Taking into account this last dimension—people—in addition to technology and requirements, I believe that the last “simple” project occurred in 1969, when one person from order processing at Sears Roebuck asked me to sort some cards and generate a report on an IBM 360/20. Since then, things have only gotten messier. Scrum addresses the complexity of software development projects by implementing the inspection, adaptation, and visibility requirements of empirical process control with a set of simple practices and rules, which are described in the following sections.