This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Software Projects Are Nonlinear
Common sense flows from a shared view of how the world works. As shared world views change, so does common sense. Examples of how common sense has changed over recent decades include attitudes toward gender and race, as well as how teams work together.
The old common sense about software development was that the process was linear. The common belief was that teams should be managed like machines, each member doing a highly structured task while working as much as possible in isolation. This approach, sometimes called scientific management [Accel-Team.Com, 2000], sprang from the implementation of the assembly line in the early twentieth century and peaked with time-and-motion research in the 1950s. In this mechanistic approach, each person in the business process did one job repeatedly and, presumably, expertly. When their task was complete, they passed the item to the next person in the process. No one worker needed the big picture; they just focused on their own task. Interactions were minimal and the result was exactly the sum of the tasks.
Although an assembly line is efficient at producing many identical items that meet rigorous specification, it was found to have important limitations. First, the mechanistic approach did not provide a means for discovering and addressing certain quality issues. Some defects arose from the coupling of the tasks, from how people work together. For example, suppose one person follows instructions in placing a part on an assembly line. The next person sees that to place his or her part, he or she must hammer it in, degrading the product. If the two workers could collaborate, they might find a way to place the first part so that the second part fits easily. Another problem with scientific management was that people did not like being treated like machines. This management approach resulted in an adversarial relationship with management. The history of labor relations in the auto industry illustrates the point.
Some people see a mechanistic approach to business processes as common sense. Each task must be done. Why not analyze each task in detail so it can be carried out in the most precise and repeatable way possible? The waterfall software development process is an example of this approach, and early literature on the waterfall process makes such claims. The problem is that this mechanistic approach makes a leap of faith: that the interaction between team members is as simple as handing off a part in an assembly line.
A consequence of this linear thinking is the belief that the process, not the skills of the individuals, is the dominant contributor to success. The leaders of organizations that adopted this approached invested heavily in corporate processes and their enforcement. Their belief was that if they hired staff to fill the process roles with limited skills, the process itself would magically lead the team to a solution to the development problem. They held to this belief even though the research of Boehm [Boehm, 1981, 2000] and others shows that staff skill is the dominant success factor.
In what follows, we will show that process is important but it is not a substitute for skill. The process must provide a means to enable the skilled staff to work better together. To understand the role of process, you first must understand how members of the team need to interact. Today, we understand that development teams act more like societies or ecosystems than assembly lines. Each member plays a role in the community. These roles, not the artifacts, determine the interactions. With the right kind of leadership, the team members can come together in unexpected, but functional, ways to solve the problem. The dynamics of societies is nonlinear.
TIP
The old common sense was about control; the new common sense is about leadership.
3.3.1 Nonlinear Dynamic Systems
A system is dynamic if, for all practical purposes, it changes over time. A bridge may rust or experience metal fatigue, but it is more or less static. The stock market is dynamic; so is the marketplace. So is your software team: Every day, the people and the work are different.
A dynamic system is nonlinear if the response is not proportional to the input; that is, if small changes can lead to large reactions. Machines tend to be approximately linear; most real-life processes, including software development, are nonlinear.
To understand how a nonlinear system operates, consider the following thought experiment:
An automobile is placed in an empty, uneven field. You are asked to set the steering and speed, and to add the right amount of fuel so that the car, unoccupied, will arrive and stop at a specified target.
On the first try, you point the car in the right direction, compute the necessary fuel, set the speed control, and release the car. The car is buffeted by the wind, affected by the slope and bumps in the field, thrown off track by a pothole, and misses the mark. You try again and again, making all sorts of adjustments, and the car repeatedly misses the target.
You decide to take a systematic approach to the problem by running a series of experiments. You build a data table of initial conditions for the car, including the starting position, the angle of the steering wheel, the amount of gas, and the initial velocity. You set up the car with each of the initial conditions, let it run, and track where it ends. With enough data, you hope to be able to find the right settings to have the car arrive at the target. You plan several runs with each of the settings and average the results. When you run the experiment, you are amazed to find there is no predictability. The car ends up somewhere wildly different each time, with differences so varied that the averages are not reliable.
Eventually, you realize that unless the field is bowl-shaped and the target is at the bottom, the goal is unachievable. There is no repeatability. You observe that just a little steering would make all the difference. You realize that the outcome is affected by nonlinear interactions: interactions internal to the automobile (suspension, tires, steering), as well as by the outside temperature, the shape of the field, the wind, and many other factors. Each time you run the experiment, these nonlinear interactions affect the outcome. Because the car running in the field involves the nonlinear interaction of all these variables, it is a nonlinear dynamic system.
Scientists and mathematicians have come to understand the nature of such complex systems as the car in the field. An area of study, often called chaos theory [Lewin, 1999; Kauffman, 1996], is used to explain systems that involve many interacting entities. Chaos theory has been applied to weather systems, the dynamics of the marketplace, the origin of life, and, for about a decade, business organizations.
Some fundamental principles describe how nonlinear systems work. They provide guidelines for effective management of complex organizations such as development organizations. Most nonlinear systems are in one of three states, each found in business organizations.
State 1. Chaotic: Unpredictable and unadaptable
The behavior of chaotic organizations is always changing. The workers' tasks change frequently, so no one is sure who is doing what or who is responsible for what. People come to work each day trying to find a way to move the project forward. Attempts to get things moving fail. Interactions generate friction, and there is no discernable progress.
In disorderly projects, under chaotic conditions, team members do not communicate. They are continually in each other's way, unsure of what their job is. They spend more time trying to coordinate their efforts than moving the project forward. This kind of internal friction generates heat and not light.
Staff members of chaotic projects are emotional in interviews. They usually complain that what they do does not meet their job description, that they do not get credit for their efforts, that their time is wasted in unproductive meetings, and that their management does not seem to have a clue about what is really going on.
State 2. Stable equilibrium: Predictable, but unadaptable
Systems in a stable equilibrium behave as the car would if the field were a bowl. No matter where you set the car in the field, the car winds up at the bottom, in a state of equilibrium. The outcome is always the same. These systems require a large amount of external energy to move them from equilibrium. To carry the metaphor further, moving them from their stable state for the long term is like carrying the car out of the bowl. Small changes will not achieve this result.
Some managers believe that a stable equilibrium is good for their organizations. They perform year after year, seemingly impervious to the world around them. Their groups are not only easy to manage; they are hard to damage, even by poor management.
Sounds good, but there is a serious downside to the equilibrium state. Such organizations are very difficult to change, like the car at the bottom of the bowl. When the pressure to change is on, they resist new behavior; when the pressure is off, they revert to old behavior. These organizations do not compete effectively when changes in mission or technology are necessary. There are many examples, such as organizations comfortable with 1960s mainframe-based development methods. Given the amount of change in our field, these stable organizations are doomed. However, organizations in stable equilibrium are the exception.
State 3. Edge of chaos: Unpredictable, but adaptable
For most real systems, small changes in initial states can result in very different results. No amount of precision and detail is enough to set these systems on a course to a predictable end. Unpredictable behavior is intrinsic to these systems and cannot be overcome.
There is a state that is not in equilibrium and not fully chaotic. When systems are in this state, without steering it is impossible to predict their future state from knowledge of the present, like the car in the uneven field. However, these unpredictable systems do respond to external influences, so that they can be influenced to achieve a useful purpose. In the automobile example, a little steering makes it easy to hit the mark.
Edge-of-chaos systems have several remarkable properties that form a basis for understanding how best to organize and lead complex enterprises such as software development organizations. The first property is that small changes have large effects. As with the car experiment, a small change in steering direction makes a big change in the car's eventual position. This property is a defining characteristic of edge-of-chaos systems. It follows that it is impossible to predict exactly how these systems will respond to a plan or a set of directives. In fact, the greater the detail, the greater the unpredictability.
Fortunately, these systems are manageable, if not controllable, as a result of perhaps their most remarkable property: They spontaneously organize themselves into apparently orderly systems that adapt to changes. However, for this to happen, the system must consist of independent entities with the freedom to interact. With this freedom, the entities create the necessary connections and communications paths. System order does not arise from being controlled, but instead by being managed. In fact, any attempt to apply control may result in the system becoming locked in a rigid equilibrium structure that cannot make the necessary connections to deal with a changing environment.