Last week I did a quick introduction to the Cynefin framework, and I talked about the essence of the framework and described framework domains and their properties. This article will give a few scenarios to understand the framework usage, but let’s take a look at the system dynamics first.
Movement between domains
Things are always dynamic, and we might have to change our management style at various project stages as the project nature moves between the framework domains.
The most stable movement pattern is a constant iteration between Complex and Complicated domains. Things move to Clear when sufficient stability is assured, and the risk of getting things wrong is low. This movement is represented as a blue line.
From time to time, when we want to challenge entrained expert thinking in the Complicated domain, we dip into the aporetic liminal part of the framework. This movement is represented as a red line.
We also have a movement pattern that constantly moves from the Complex domain through all liminal zones and back again. This movement is represented as a purple line.
The α, β, γ and δ are key monitoring points for making decisions.
Managing a party for a bunch of 9-year-old kids
A shortened satirised version of managing a kids’ party by Dave Snowden. You can see this example on this YouTube talk.
To manage a party for a bunch of 9-year-old kids, we first need to decide on the management style. What type of system is it? Is it an Ordered, Complex, or Chaotic system?
Chaotic approach
We have no effective constraints, and kids act entirely random. That means they will probably discover drugs and alcohol and go on a personal experience of self-discovery. Your house might be destroyed in the process, but it was socially constructed in the first place, so why are you worried about it? Treating a party as chaotic is probably a mistake.
Ordered approach
We have a vast amount of agile certifications available, and you agree with learning objectives for the party in advance of the party itself. The learning objectives are aligned with the mission statement for education in the community to which you belong. They are clearly articulated and printed on motivational posters with pictures of eagles soaring over valleys and water dropping into ponds. You place those posters around the room where you can hold the party.
You don’t ask kids that come into the party, you give them a Disney playing card with a company value statement printed on the back, so they’re aware of what they meant to do, and of course, you produce a project plan for the party.
The project plan should have clear milestones throughout the party against which you can measure progress against the ideal party outcome. The senior adult should start the party with a motivational videotape - you don’t want the children wasting time in play which isn’t aligned with the learning objectives. Then you use PowerPoint to demonstrate their commitment to the party objectives and show the children that their allowance is the link to achieving the outcome targets.
Following the party’s highly successful completion, you conduct an after-action review and mandate new best practices across your local community. If at this stage, for any remote reason, the children aren’t happy, then you either require an appreciative practitioner who will tell them happy-clappy stories so they have happier mental models, or you bring in a happiness consultant or any of those variations.
Complex system approach
We start by drawing a line in the sand. This line is a constraint or a boundary in complexity terms. We look at children squarely in the eye and say: “cross that, you little bastard, and you die”.
One of the things you learn pretty fast as an adult is the value of flexible, negotiable boundaries because rigid boundaries have a habit of breaking catastrophically when you least expect them.
Then you introduce chaotic catalytic probes (a football, a videotape, a barbecue, a computer game) and hope a pattern of play will form. That’s called an attractor. If it’s beneficial, we give it resources. If it’s not beneficial, that’s when you deploy the fire hoses. We manage the emergence of beneficial coherence within attractors within boundaries.
You would never manage a party like in this example, just like you would not manage a car manufacturing plant and a software project the same way. Still, that is what happens.
When you think about software design like this, you start to think about it very differently. This brings me to another example.
Scrum project
Product development in the software world is an inherently complex type of problem. We cannot accurately predict which features a customer might want, how they might use them in various scenarios and how their behaviour might change over time. We might only completely know the requirements for a new software system after users start using it. Also, we cannot predict the behaviour of our competitors and external factors such as new regulations or legislation.
In complexity, we describe the present and see what we can change. We define a direction of the product, not a go because if we start a journey, we will discover things we didn’t know we could discover, which have high utility. We might miss the things we need to discover if we have an explicit goal.
A way to tackle a high level of uncertainty might be a scrum. In scrum, we break up the project into small iterations. The iteration in scrum is called a sprint. The duration of the sprint constraints our safe-to-fail experiments. The items or features in our sprint backlog represent our experiments, and they constrain the work amount in the sprint.
We execute the sprint as if it may be complicated work doing expert analysis through product backlog refinement and sprint planning. We plan the day’s work, then sense whether the plan still makes sense during the daily scrum meeting and change it as appropriate. We work on our sprint backlog items in parallel during the sprint, and the sprint outcome is a shippable product increment. Sprint follows the most stable movement pattern mentioned earlier. Things transition between Complex and Complicated domains.
The sprint review and retrospective allow us to sense the outcomes of our product increment (positive or negative feedback). We then amplify or dampen the probes based on these outcomes as changes to the product backlog (the output of the sprint review meeting) and system improvements (the output of the sprint retrospective meeting).
comments powered by Disqus