Many times, Scrum Masters and agile coaches are confronted with the need to change a team that seems to be stuck in its own behavior. And though team members may be willing to change, they just can’t seem to get out of their current situation. With this article I try to shed a new light on this difficult problem, and I propose to change the environment instead of the team. It could be a much easier strategy.
When I was 15 years old, I was fascinated by books about the shape of the universe. (Other guys of my age were more interested in other shapes. But I’ve always had an eye for the bigger picture.) The things I read about special relativity and the expanding universe led me to try and draw my own four-dimensional object on paper (see Figure 1).
Figure 1
A four-dimensional cube (or “hypercube”)
I created the object in Figure 1 by shifting an ordinary cube into an imaginary fourth dimension, and then connecting the 16 corners, just like one creates a cube by shifting a square in a third dimension, and then connecting the 8 corners. I was thrilled at the time that it was so easy to draw what was in fact a 2D projection of a 3D projection of a 4D object. It was my favorite shape at the time (until I found out other shapes were more important, when I finally started dating.) But when I showed my drawing to my physics teacher he told me it was complete nonsense. I felt defeated and misunderstood. Years later I learned that the thing I had “invented” is called a hypercube, and that my physics teacher missed a great opportunity for learning from a student.
A hypercube is yet nothing when compared to the “shape of improvement” in a complex system (like a software project). When evaluating the many states of a dynamic system, researchers imagine each variable in the system to be an axis in a multi-dimensional space. A small system with just three variables is represented as a phase space in three dimensions. While a system with 20 variables has a phase space of no less than 20 dimensions. I’m afraid that even I would not be able to draw such an object. And that would still be just a small one. Many complex systems consist of thousands or more variables, with a corresponding phase space of a mind-boggling size.
For example, seaweed has roughly 1,000 genes. Suppose, for the sake of simplicity, that each of those genes comes in just two varieties: green leaves vs. brown leaves, big leaves vs. small leaves, flat leaves vs. wrinkled leaves, etc. The number of possible states of seaweed would then be 2^1000, or one thousand dimensions with two possible values in each dimension [Waldrop 1992:167]. (Human DNA is estimated at 25,000 genes, and it has more than two variants per gene. Can you imagine drawing a hypercube for that phase space?)
A specific instance of a system is said to be in one location of its phase space (each variable has one specific value). When any of these variables change, the system is said to move through its phase space. Switching one gene in seaweed DNA (for example: a mutation from green leaves to brown leaves) will move seaweed DNA from one point to a neighboring point in its phase space. But changing many different variables at the same time (for example: mixing the DNA strings from mommy seaweed and daddy seaweed into a brand new DNA string for baby seaweed) is like a hyper-jump through phase space.
By visualizing change as a journey through a space it becomes easier to recognize and discuss the patterns of continuous improvement. It also becomes easier to see which shapes are important, and which ones are not.
Attractors and Convergence
OK, now it gets a bit more mathematical. Just hold on tight, and I’ll try and steer you through this challenging landscape. Trust me; the scenery will be worth it.
When complex systems change, the journeys they take through their vast phase space typically fall in one of a few categories. Consider the example of the famous Game of Life[1]. Regardless of the initial state of the game, after a number of steps the system ends up in a stable situation, in all but a few cases. The stable situation at the end is either one stationary state (a “still life”), or it is an everlasting cycle of a small number of states. We say that the stable situation is an attractor for all other states that lead into it. And the collection of all trajectories that lead to an attractor is called its basin of attraction (see Figure 2). Since each system usually follows trajectories that lead into attractors, the attractors lure the system into small regions of its entire phase space. Despite the vast range of possible states of the system, it finally settles into one of just an orderly few.
Figure 2
Attractors (A), basins of attraction (B), and disturbances (S)
Are you still with me? Good. Let’s make it a bit more concrete with the example of seaweed…
Theoretically there are 2^1000 possible versions of seaweed DNA. That’s a lot, actually. It’s quite a bit more than the number of atoms in the universe. However, the number of real observable forms of seaweed is extremely small, because all other forms are unstable and, within a few generations, would either die out or change and end up in one of the few stable forms. It doesn’t matter that an uncountable number of forms of seaweed is theoretically possible. In practice, the environment forces seaweed to end up in one of a small number of forms that are actually feasible for that environment.
Some scientists think that convergence [2], which is the fact that biological solutions like eyes and wings have been “invented” several times independently, is a good example of the concept of attractors [Lewin 1999:73]. In biological morphology there is an attractor of “things that have four legs,” and an attractor of “things with two wings,” etc. Five legs and one wing are valid forms, but they are not stable. (Except perhaps in the vicinity of an unstable nuclear power plant.)
And so I believe that, in order to make a software project work well in its environment, we must make sure that what works well is also stable. Because projects will converge on stable forms, but that doesn’t mean those forms also work well…
Stability and Disturbances
There are three kinds of attractors in complex systems [Gleick 1987:269]:
- A fixed point attractor keeps a system in one specific state. An organizational hierarchy could be a good example of a fixed point attractor. Almost all organizations end up in that structure, and then they stay there forever [Waldrop 1992:169];
- A limit cycle is an attractor where a system repeatedly goes through the same sequence of states. One example is the cycle of forming, storming, norming, performing, and adjourning, a well-known group development model [Arrow 2000:152];
- A chaotic or “strange” attractor is a trajectory that refuses to end up in any of the other two kinds of attractors. An example of a strange attractor could be a chaotic startup business desperately running from opportunity to opportunity, never settling in a stable situation until the environment finally allows it to do so.
An attractor typically drains an enormous basin. Now suppose that, somehow, the stable system is disturbed. Suddenly the state of one of its variables is arbitrarily switched from one value to another (for example: one development practice is replaced by another). Figure 2 shows that most of these perturbations have no serious effect on the system. It simply stays in the attractor (S1), or it is pushed out of the attractor but finds itself in the same basin of attraction (S2), meaning that the system will still end up in the same attractor anyway. Only when the variables in the system are pushed far enough will the system be pushed from one basin of attraction to another, thereby ending up in another attractor (S3).
Stability, or homeostasis, is an important property of complex systems. No matter how you push and prod, some systems keep on doing whatever they did before. Doesn’t that sound familiar? Doesn’t that sound eerily like the time you tried to introduce agile development practices in a group of people, and the group simply fell back into their old habits? Doesn’t that remind you of the time you wanted to change an organizational culture, and the organization simply resisted all your efforts?
Like any other kind of complex system a group of people can get stuck in an attractor. This can be either good or bad. It is good when great performance keeps the group locked in that state. It is bad when other factors, like an organizational culture, keep a group in a “bad” attractor, preventing them from performing better. The forceful introduction of “change” into such an organization will rarely have an effect. Even if you’re able to push the group out of their attractor, the big basin of attraction around it will simply let them slide back in!
So, what is the solution? How can we make change management work? I believe the answer should be found not in the system but in the environment. The attractors in a system depend on the environment. When the environment changes, the attractors change along with them. Some environmental changes disturb attractors so much that they dissolve altogether, and the system automatically finds itself on a path to another attractor. Maybe even a brand new one.
When changing teams and organizations, the trick is not to try and push them out of their current behavior. That’s just too much work with far too little results. A better idea, for Scrum Masters, agile coaches and other drivers of change, is to change parameters in the environment so that the current situation of the team becomes unstable and disappears all by itself.
Let me give you an example... In several software development teams I have tried to introduce test-driven development (TDD), without any success. Legacy code, technical platforms, team culture, and customer contracts all seemed to conspire against me. Even when team members were willing to adopt TDD, they simply couldn’t sustain their heroic attempts at practicing it. However, I then started from scratch with a new team, with a different business model, different technologies, a different architecture, and most important… different customer contracts. The people in my new team were the same people I worked with before. But I was able to change the environment instead of trying to change the team. And the team was then able to find a stable state that included TDD. Practicing TDD was suddenly very easy.
I think the message is clear: when teams seem to be stuck in their (bad) behavior, try to change the environment, not the team. There’s a good chance the behavior will then change all by itself.
This article is an adaptation from a text out of the book “Management 3.0: Leading Agile Developers, Developing Agile Leaders,” by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.
http://management30.com
http://mikecohnsignatureseries.com
www.informit.com/title/0321712471
References
Waldrop, M. Complexity. New York: Simon amp; Schuster, 1992.
Lewin, Roger. Complexity. Chicago: University of Chicago Press, 1999.
Gleick, James. Chaos. Harmondsworth Eng.: Penguin, 1987.
Arrow, Holly et.al. Small Groups as Complex Systems. Thousand Oaks: Sage, 2000.
