The Shape of Change on Agile Teams

• 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