A journey around complexity that might just help your agile transformation (or culture change, or response to an incident).
“Experience tells us that true solutions are often not obvious. Yet in our haste, actions are often driven solely by what is available and obvious.”
Anon
It’s peak time for the London underground and you’re waiting for a train on the platform. You’re boxed in by hundreds of other commuters, and there’s almost a predatorial atmosphere with people jostling and competing to board the next train. A train finally pulls in, but there’s only room for a few passengers to get on and you’re not one of them. As the train leaves the station you notice that there are yet more people joining the platform, and you can’t help wishing that Transport for London (TfL) would just run more trains.
And it’s a very logical idea: Number of people wanting trains > Trains available, therefore add more trains. Apparently, there are 543 trains in service at peak times in London, so a few more should be fine, right?
Perhaps they should double it!
We might imagine a harmonious commute, with seats for everyone and happier passengers. Fewer awkward glances, carriages that smell better and arriving at our destination a picture of calm.
But if the number of trains increases, other consequences are likely too, for example:
- Less passengers per train leads to an increase in train fares
- The new trains and their support services create additional manufacturing jobs
- TfL recruit and train additional staff, creating jobs
- Other jobs are created in London due to increase in candidates able to travel
- UK distribution of business continues to grow unfairly in favour of London
- The improved train experience encourages more commuters to take the tube
- The additional load on the infrastructure causes structural damage
- The new power requirement leads to additional wind and solar farms
- The time and margin of error for trains negotiating signals reduces
- The new trains cause a chance meeting, leading to a new £1bln company
- Use of the bus network reduces as people take trains instead
- There’s a higher chance of collision on the network
- More passengers overload station capabilities and passenger injuries increase
I’m sure there are many more, and some better, some worse. The one thing we can be certain of however is that the result won’t just be a few now-happy commuters, so be careful what you wish for!
It’s also logical that some analysis could be done to predict or model these outcomes should TfL consider adding more trains. Indeed, before the new cross rail project commenced to connect east to west London, (I assume) some of these ramifications will have been considered in detail or were the prompt for the project in the first place.
A complex system
The London underground is a good example of a complex system, and there are many others too, from ecosystems like rainforests and coral reefs, to our own bodies and the inner workings or culture of a large organisation. In all these cases, and even with detailed models, an action we take could spread out into unforeseen (and in advance, unknowable) outcomes.
So, what is a complex system and how is it defined?
A very useful model here is that of Cynefin (pronounced c-nev-in), developed by Dave Snowden. Cynefin is a conceptual framework designed to help us make better decisions (and indeed learn from them), by understanding the characteristics of where we are.
The framework is divided into five domains, as follows:
Simple: The domain of predictability. There is a clear link between actions we take and their effect, meaning that in this domain we can apply ‘best’ practice to achieve a known and reliable outcome.
Complicated: In this domain we can still predict the cause and effect chain if we apply the right knowledge and analyse what’s happening. Using the Eurofighter here to illustrate, with the right skills we could accurately plan for the outcomes of a change we want to make, model a fault and so on. This domain doesn’t have absolute best practice therefore, but good practices apply.
Complex: In this domain, cause and effect relationships can be identified, but only after the fact. For example, making a change in a coral reef could result in unforeseen consequences, the cause of which only identifiable after the event.
Chaos: This domain describes a need for immediacy. A considered response would be too slow, and the changing situation means diagnosing cause and effect relationships isn’t possible (practical at least) over the need for action. Examples might be the rapidly changing nature of a riot, a fire or other emergency.
Disorder: The final central domain is where we do not know which of the main four domains we are currently working in (and it may be more than one).
Getting clearer
On discovery, the Cynefin framework was a revelation for me. It connected the dots as to why so many changes, transformations, projects or strategies fell flat: we didn’t know, or even stop to consider, where we were and what that might mean.
To illustrate, take a simple and not unusual, example: A team decides to implement Scrum.
Into which domain is that change being made? Let’s think about it.
Simple: Do we believe that there is an absolute best practice for getting Scrum implemented into a team? Hopefully not (and don’t believe anyone who says there is!)
Complicated: Do we believe that there is knowledge and good practice available that can get Scrum implemented? There is plenty of good practice around Scrum, so definitely possible.
Complex: Do we believe that we are working in an environment where outcomes (good or bad) won’t all be predicted, like the trains or coral reef? Almost certainly. Implementing a process into a team, unless it truly runs in isolation, will have impact and needs from other teams.
Chaos: Do we need to take immediate action to put out a fire? No – we’re making a planned change here.
Against this list, the Scrum implementation falls into Complex. We can’t predict all the outcomes in advance and without recognising that, we might assume that best or even good practice is enough. That opens a risk of failure when something unexpected or contrary to our expectations happens like being asked to budget in annual cycles, produce extensive design documentation or midway learning that the team have bad experiences and ‘hate Scrum’.
And all that leads to Scrum being abandoned and probably blamed for the failure too.
NB the little ‘curl’ at the bottom of the domain diagram signifies this risk – the painful shelf when we realise the situation isn’t simple and we suddenly fall into chaos.
Approaches to domains
Being clearer about which domain we’re in, we can look at the recommended approach through Cynefin.
In the Simple domain, our approach would be to sense (from data we have available), categorise and then respond accordingly. “It’s one of those, do this.”
For Complicated, we can’t readily categorise, so analysis and expertise are needed before our response. Without this we’re just guessing.
In the Complex domain, our primary action would be to use probes – to experiment and test out hypotheses. Based on the results of these experiments, we can choose a response.
In Chaos, with no time or value in analysis, we act first and see what happens. We might literally reach for the fire extinguisher here, see the results and then choose our next response.
Lastly, for disorder (not in the diagram), our approach would be to break the situation apart such that individual parts could be categorised into the other four.
Wishing for the right things
Looking back at the trains example, it should be clearer why ‘just adding more trains’ is reckless: we were acting from the Simple (or possibly Chaos) domain. The addition of trains wasn’t analysed, and nor was it experimental.
Taking a Complex domain approach, we need a hypothesis before taking any action. As a simple example, we want to test that adding trains improves commuter experience, so we might plan to make a change on one route. With a scientific approach here, we will understand how the probe will be orchestrated and measured, allowing us to Sense and then Respond accordingly.
The same idea could be applied to our implementation of Scrum into a team. We attempt changes to practice (whether Scrum itself or in the surrounding team) and approach the implementation as an experimental and learning activity, and crucially one that doesn’t presume we have the exact answer.
And that brings me to the final, important angle to look at here. With our commuter or Scrum implementation, what was our actual aim? The aim of the team wasn’t to implement Scrum (not I hope, for the sake of it) – it was probably a desire to increase productivity, delight customers or another commercial outcome.
Similarly, behind the wish to increase trains was a desire to improve passenger experience. Perhaps behind that, the aim was a calmer state of mind at work leading to higher focus.
Mapping this out, we learn that the aim is to increase focus, and we’re free to consider alternatives. Apart from improving the commute, how else could we be more focused at work? We might try meditation, listening to music, working from home, taking breaks, or other experiments. We might take a job in an area that avoids the commute, and we might just get our wish without needing them to run more trains.
Image credit: Image by Rudy and Peter Skitterians from Pixabay
Leave a Reply