While Diana Larsen was in Germany in July she spoke about a course she was currently taking called Human Systems Dynamics. Since then some of my colleagues started to dive into it. So did I. I didn’t take the course, but decided to go for some of the books on it. The first one I came across is called Facilitating Organization Change – Lessons from complexity science, and deals with a lot of stuff on complexity science, self-organization, and how to introduce changes in a complex adaptive system (CAS). These are some of my first thoughts after finishing the book.

I must admit that my first reaction to complexity thinking, complexity science, whatever was grounded in Michael Bolton‘s Reltive Rule:

A description of something intagible as “X” really means “X to some person, at some time”.

Complexity is complexity to some person at some time. Indeed in the past I have made bad experiences when someone claimed a product to be complex while I was still able to understand what it’s all about. The same notion hit me when I saw the word complexity on the book cover in the subtitle. But as I dived deeper, I got some takeaways.

The main takeaways from the book is the model from complexity theory. The authors put emphasis on three main aspects of a team, a company, or whatever your system might consist of: the container, significant differences, and transformational exchanges.

The container consists of the environment of the team. At one point I confused it with the context, but context is just on part of it. The container has boundaries to other departments, companies, and teams. Containers I became aware of are for example Waterfall, Agile, Scrum, Kanban, ISTQB, TMAP, programmers, testers, the context-driven school of testing, etc.

Significant differences are the things that distinguishes the folks inside a container from the others outside of it. For example one significant difference between context-driven testers and testers in the standards school of thought is the neglection of “best practices”. One significant difference between Scrum and Kanban folks is the need for an iteration in which development occurs. Usually there are more than one differences, and you can identify differences to a multitude of other systems.

Transformational exchanges happen when folks from at least two container with significant differences get together, and exchange their thoughts. One such transformational exchange happened ten years ago when Uncle Bob invited for a convention of thoughtleaders – resulting in the Agile Manifesto. Another transformational exchange is the annual Agile conference. The first ALE (un)conference was another one to get Europeans together to self-organize for the next big thing.

Considering the examples I gave, you might already notice that this model seems to be powerful – or at least you can use it in multiple circumstances. (I apologize if I misapplied the model somewhere.) The authors describe also how this model helps to understand why traditional change efforts might not work in complex adaptive systems. They also provide their own model how to bring change to an organization. Here are the six things to keep an eye for – which will be elaborated later.

1. Change through connections
2. Adapt to uncertainty
3. Emerging Goal, Plans, and Structures
4. Amplify Difference
5. Self-similarity
6. Success as Fit with the Environment

Change through connections

The authors contrast this point to top-down imposed change initiatives. Rather than demanding that the whole company follows the new structure, it’s more important to connect people. This is what Jurgen Appelo initiated with the Agile Lean Europe network. Rather than demanding a change in how European Agilists work together, he got everyone together, and have them work out the details. (And I think this had something to do with the fact that there is no single European leader on Agile or Lean – sorry Arne, not even you.)

Adapt to uncertainty

Outcome is uncertain in a complex system. There is no prescribed medicine for change. In a complex system with many interactions between the agents in that system things change quickly. That also means that it’s uncertain where the change effort will lead to. But instead of giving in to some illusion about certainty, you should start coping with the uncertainty.

Emerging Goal, Plans, and Structures

On a similar note goals, plans, and structures are doomed if the future is uncertain. You may have a goal. But while you start to reach it, this same goal will as well change as the system starts to change. That’s why Agile Retrospectives focus on at most three different actions for the next iteration. These will already change the system enough so that other goals will shift as well.

Amplify Difference

Differences are good. You shouldn’t try to find consensus everywhere. Rather get the people together, and amplify that Paul is specialized in programming, and Thomas is specialized in testing. That still means that these two may work together, each one of them providing their special skills.

Self-similarity

Changes happen in similar ways on multiple levels in the company hierarchy. The system adapts to changes in similar ways. The authors contrast this to the traditional viewpoint that there are differences between the different levels in a change initiative.

Success as Fit with the Environment

The environment helps to define success. If you succeed, but your product does not fit into the environment, you end up with “technical success” – a business failure. The authors contrast this with the traditional viewpoint to close the gap with some ideal. As James Bach taught me, there is is no one to define such an ideal.

If I transport these thoughts further to other aspects of my professional worklife, I see such connections at conferences like EuroSTAR where a bunch of testers from different backgrounds get together to exchange their thoughts. Though I think the discussions of the folks there are too limited to result in meaningful transformations. From my last year’s experiences we should strive for more debate – something James Bach and other context-driven testers call for since decades.

Another opportunity for connections could be a get-together of Scrum and Kanban folks. Being someone watching the fights from the outside, I think a convention for Scrum and Kanban thoughtleaders to settle their disagreement would be a good way to see how they cope with their differences – and I would be excited about the self-organizing structure that results from that. As Diana Larsen said back in July, Agile is changing. The emergence of a new methodology like Kanban showed this to me. Now, it’s up to Agile leaders to prove that “Responding to change” is indeed more worth than “following a plan”. And just consider what Agile would mean if it’s incapable to handle changes inside itself. Ewww.

Finally, I think testing is changing. Previously on traditional projects testers were asked to work with a clear goal according to a plan. In complex adaptive systems testers need to shift their personal responsibility to support the team. We have to cope with uncertainty. While this meant beforehand to wait for an uncertain build, only to find out that it’s broken and working long hours, in a CAS we are asked to help the team have the exchange to self-organize their work accordingly. This is a major struggle most testers face wile transitioning from traditional to Agile methods. My point here is that a traditional company would also benefit from such a shift in attitude and mind-set. Over the course of the next two decades I believe that more and more traditional testers will either need to transform their thinking to this new paradigm, or shift their jobs to something different.