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.
- Change through connections
- Adapt to uncertainty
- Emerging Goal, Plans, and Structures
- Amplify Difference
- 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.
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.
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.
8 thoughts on “Lessons from complexity thinking”
You are very right, that just if someone claims something to be complex doesn’t necessarily mean that it is. Complexity in IT-systems become interesting when components are interacting in a way so that results are not always predictable.
To me, complexity is particularly interesting where it is the cause of incidents, disasters, accidents – Black Swans. Of course, just because a system is complex system doesn’t make it prone to break downs or incidents, but certain systems are.
There is’nt much litterature on the subject (certainly not about IT), but I’m currently reading Charles Perrow’s “Normal Accidents” and Nassim Taleb has some interesting thoughts on the subject.
Not only is a complex system not necessarily more prone to breakdowns or incidents – there are actually a lot of situations where a complex adaptive system is likely to perform much better and reliably than other types of systems. Particularly situations where you need the system to adapt quickly to unforeseen changes.
This reminds me of a lesson I learned from James Bach, in which he challenged me to find at least three different situations in which context does not drive your actions. He could present me three, and now I see the parallels between context-driven testing and complexity thinking.
you write “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”. I don’t think that’s the same type of complexity the book talks about. A Complex System doesn’t have to be hard to understand what it’s all about. It’s just typically hard to impossible to predict future behavior. A double pendulum, for example, is simple, physically very well understood, and shows chaotic behavior – it’s a complex system: http://www.youtube.com/watch?v=U39RMUzCjiU
That reminds me of and you might find interesting the simplicity model by Jurgen Appelo http://www.noop.nl/2010/09/simplicity-a-new-model.html
In this model he refers also to the double pendulum. He actually made a two dimensional matrix, where one axis shows the ability to understand and the other the ability to predict.
I found this model sometimes very useful.
having attended the course, I am aware of the model, and I found it not so useful for me. I also noticed the motivator for Jurgen’s model, while I read in the book. The authors have the complexity dimensions pointed out in the book. I do not resonate so much with the complicated dimension.
I know about that. My first reaction was rather triggered by the notion that the Relative Rule applies to the term complexity. Once I understood the model, I became aware that it has a different meaning in this context.
One more comment: Differences don’t have to be between containers, they also (need to) exist inside containers. Also, not all differences are good – it’s only the significant one (those that “make a difference” for the job at hand) that should be amplified.
You are right about consensus. That’s what I like about consent (as an alternative decision making approach): you don’t need all “agents” in a system to agree on something, you just need to have talked through the differences to the point where you found a solution that everyone can *support* (and therefore doesn’t feel the need to veto).