What if “Agile” is nothing more than the dynamic of a system?
As an agile coach, it is utterly annoying to be considered as an evangelist or whatever guru. This role 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 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, and it is like when your five years old child is showing up it is 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 year’s new people are coming with the same ideas, the same old ideas and even hijack the original 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 them, 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 borders 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 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 to collect “good practices” or to validate an outcome.
- Simple: The information shared from the “top” is evident for all participants in the system and doesn’t need to be discussed. Ex. Fire alarm = get out.
- Chaos: nobody is interacting, and all the people are working in their 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, and it helps to define “Chaos” and another form of dynamics and not as an anonymous 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 evident 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. That interaction 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 “Complicated”.
- As the teacher, then I validate the “Good Practice” with “Best practice”, and the result might be evident for all attendees. Back to Simple.
This demonstration 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 two stages worked well, and I brought the crowd into the Complex. Then I saw that one member was answering emails on his Mobile Phone. I waited until the student was finished and told the crowd that I had forgotten something. I pulled them out of Complex to Complicated. I had to explain the goal of that exercise again, and I ensured that all phones are moved away, and relaunch the loop with better results.
Here is the model. If we take a scrum as an 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 tries 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 and negotiate with the Product Owner and try to make a deal on 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 the teams align 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 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 asks 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 are you having a visiting agile coach?
It happens to like my student answering email during my class. The dynamic 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 is enormous 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 order is an authority, and it 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 sufficiently 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). Emergent means that the system learns by itself while experimenting (praxis) and discovering his abilities allowing to modify its boundaries: tight enough to see its limits, large enough to have the freedom to progress. D. Snowden is often using the metaphor on the 8th child birthday party, and here I have to consider all the birthday parties of a growing child (this is the purpose of the retrospective in scrum).
By adding Flocking behaviour theory with the Cynefin model, then your scrum looks again a bit more different and exciting:
- 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 and 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 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 nine principles:
Now, you have all the tools to move on into agile and take care of:
As a conclusion, I didn’t address how to build a system in this post and nor what a system is. One thing for you to take into account that the system works when decisions are bringing 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
