As an agile coach, it is completely boring to be considered as an evangelist or whatever guru. This is perhaps a mark of respect and that’s fine but when you are working daily with teams this becomes weird while trying to help, and people just see you as another “Moses” and not as a helper.
Every year new agile coaches are emerging and they are doing the same that I and some of my friends did a decade to 20 years ago. Genuinely this is okay, it is like when your 5 years old child is showing up its drawing. You are amazed by this mix of curves and stripes because you acknowledge the effort. But in fact, you have to admit that your child isn’t that great artist. That’s all to say that every years new people are coming with the same ideas, the same old ideas and even hijack the early sense of a concept without improving the early concept or worse transform very tiny subparts and develop their thoughts like a syllogism. So let´s try something new.
In 2011, I attended the seminar of Leading in Complexity by Dave Snowden in Frankfurt(Germany) and it was a blast for me. The explanation of the Cynefin framework helped me to understand how systems are behaving and how to act on it. Much later, in a very passionate conversation on LinkedIn this year, I discover that my understanding is a bit different from the average mass of Snowden´s fan, maybe I´m wrong but I want to explain how different it is.
Most of my colleagues are using Cynefin like a static measure to understand how a system is. The problem, this is an assumption, this is an observation from somebody outside of that system. You have to know that every observer is impacting the system and the only choice you have is to be part of that system.
What is happening in the system from the Cynefin perspective?
On the boarders of the Cynefin diagram, you can see links and dots. The dots are related to the agents in the system (can be a bunch of things, but in my case, it will be people). The links are representing how the interaction of those dots (people) is in a particular domain:
- Complex: the 3 “people” on the base are interacting together and the one on the top doesn´t.
- Complicated: all people are linked
- Simple: only a top-down link exist
- Chaos: none of them are linked.
Since 2011, I considered the yellow dot like the representation of leader or manager or authority, and the black ones like “team members”.
Then I translate the Cynefin model a slightly differently:
- Complex: the “team members” are autonomously interacting together and co-create together a new “emerging” solution. Ex. building on the top of each one’s idea.
- Complicated: all participants are interacting together to analyse something in order to collect “good practices” or to validate an outcome.
- Simple: the information shared from the “top” is obvious for all participants in the system and doesn´t need to be discussed. Ex. Fire alarm = get out.
- Chaos: nobody is interacting, all the people are working in their own area.
This learning loop was for me a second blast even I do not fully agree on that picture. My pain point is on the crossing of “Disorder”, the black hole in the middle. “Disorder” is the unknown and is like the “0” in numbers, it helps to define “Chaos” and another form of dynamics and not as an unknown form. I don’t like it because it gives credit to take actions in a system which we have no data (unknown). A bit contradictory but I’m pretty sure there is a perfect answer on that.
Anyway, from my first interpretation and while using the Learning representation, I started to design a facilitation process called PLöRK. This model works like that:
- Start at Simple: The purpose of the workshop, of the learning point has to be obvious for all attendees. The invitation has to be crystal clear to ensure where do we want to go with our learning.
- During a couple of minutes, each attendee has to think individually what and how the purpose resonates. That´s my Chaos.
- After that time-box, you ask the crowd to work together to solve that learning problem. This is also time-boxed and takes the majority of the time. (Complex)
- Once the time is over, we all debrief together and some points are clarified, adjusted, improved (Good practice). Here comes my.
- As the teacher, then I validate the “Good Practice” with “Best practice” and the result might be obvious for all attendees. Back to Simple.
This sounds easy. Once I made a train-the-trainer session in an insurance company because they wanted to know more about PLöRK. The first 2 stages worked well and I brought the crowd into Complex. Then I saw that one member was answering emails on his Mobile Phone. I waited until the student was finished and told to the crowd that I have forgotten something. Pulled them out of Complex to Complicated. Explained again the goal of that exercise, ensured that all phones are moved away, and relaunch the loop with better results.
Here is the model. If we take a scrum as example, it looks like this:
- scrum starts with a vision (simple) or a sprint goal. That goal is not deterministic, it is a forecast, an expected goal.
- then during the sprint planning phase, each of the team members try to show up what is this all about. (Chaos)
- then the team, collectively try to design what and how the solution might be (Complex)
- the team discuss negotiate with the Product Owner and try to make a dealon what has the highest business value and lowest complexity, or what needs to be fixed now (Complicated).
- then the improved sprint goal is agreed (Simple) and the team starts their sprint (Chaos) until next days daily scrum where to team aligns and works together until the end of the sprint (Complex).
- the sprint ends in a Review (Complicated) and a Retrospective(Complicated) and a potentially shippable increment is marked “done” and the working model has been improved according to good practice (deviation from the initial working model) for Simple.
- then the loop is starting again.
So, let´s assume that you agree with my demonstration. What happens if someone ask a team member during the sprint to do something not aligned with the sprint goal? What happens if someone interrupts the sprint like a manager making an unplanned All-hands meeting? or having a visiting agile coach?
It happens like my student answering email during my class. The dynamic is broken and you have to relaunch the loop.
To ensure the adequate dynamic, the scrum master has to care about that. I say scrum master for that example, but it can be the Process Manager (in Kanban) or an Agile coach. The responsibility for those roles are huge because they have to care about the system created by the team. They are part of the team and protect the system from external threats. They can’t be an authority (yellow dot), in fact no one in the system is an authority and it is managed on its own (self management principle).
In my example, I used scrum to tell a story about agile system dynamics. I believe that scrum brings the minimal organisational setup with just enough roles to ensure a great dynamic with less “authority” impact.
At the early stages of agile, a team is on its way to complex adaptive system behaviour but cannot fulfil the expectation of a complex adaptive system due to the strong result oriented context. In parallel, R&D tracks are working in a fully complex mode with the only constraint to show up monthly their findings like below (complex-complicated-complex dynamic in fact):
The Cynefin model isn´t enough to understand agile systems dynamics. The core principle is to build a system allowing “agile behaviour” and that behaviour is emergent (empirical) this means that the system learns by itself while experimenting (praxis) and discovering his own abilities allowing to modify its boundaries: tight enough to see its limits, large enough to have the freedom to progress. If you know D. Snowden´s metaphor on the 8th child birthday party, here I have to consider all the birthday parties of a growing child (this is the purpose of retrospective in scrum).
By adding Flocking behaviour theory with the Cynefin model, then your scrum looks again a bit more different and interesting:
- scrum starts with a vision (simple) → alignment of the agents (stakeholders, design alliance, design the system)
- then during the sprint planning (Chaos) → self commitment
- then the team, collectively try to design what and how the solution might be (Complex) → cohesion of the agents (stakeholders) ensures complex behaviour
- the team discuss negotiate with the Product Owner and try to make a deal (not imposing) on what has the highest business value and lowest complexity, or what needs to be fixed now (Complicated)→ alignment.
- then the improved sprint goal is agreed (Simple) and the team starts their sprint (Chaos) until next days daily scrum where to team aligns and works together until the end of the sprint (Complex)→ alignment + cohesion
- the sprint ends in a Review (Complicated) and a Retrospective (Complicated) and a potentially shippable increment is marked “done” and the working model has been improved according to good practice (deviation from the initial working model) for Simple→ separation
- then the loop is starting again.
I agree that this can be an obscure explanation but I will sum it like this:
Simples rules applied to scrum and agile:
- point to the destination: goal, roadmap, true north, vision
- avoid collision: scrum-of-scrums, impediment bashing, daily stand up
- planning skills: planning poker, magic estimation, customer journeys, …
- follow the line: scrum ceremonies and rules
How does scrum looks alike when applying Agile Systems Dynamics then?
You take the basic rules defined in the scrum guide and improve it with these 9 principles:
Now, you have all the tools to move on into agile and take care about:
As conclusion, I didn’t addressed how to build a system in this post and nor what a system is. One think for you to take into account, that system works when decisions are taking into the system and not outside-in. If you are a scrum practitioner and your Product Owner isn’t part of the team. he or she is not in the system.
Heidelberg, May 1st 2019
Pierre
the agile agency 