In a series of blog posts, I want to share how you can use Systems Thinking to resolve complex problems. Systems Thinking aims at understanding and possibly solving complex problems. In this episode, I will focus on complex adaptive problems, also known as “Wicked Problems”.
Wicked problems are very difficult problems that don’t seem to have a simple solution. They’re like an inextricable knot. When you’ve unraveled one thread of the problem, new problems keep popping up.
Some examples of wicked problems you probably know:
- Global warming
- The boat refugees
- Traffic jams
- The Brexit
In Scrum, we also experience Wicked Problems. Some examples of Wicked Problems Scrum Masters have to deal with:
- Your team keeps on rejecting items prepared by their Product Owner.
- Your team cannot finish the work in the Sprint for many Sprints in a row.
- The system is so complex, every change we do creates many bugs.
- How can you (the Scrum Master) tell the team to be on time without being a boss?
- The amount of meeting time keeps on growing since we started working with Scrum.
Key characteristics of Wicked Problems
They are not formulaic. This means you cannot describe them in a formula. This also implies there is no universal solution to these problems. Because of the complexity caused by the high number of unknown variables and relationships between them, we cannot describe solutions in the form of formulas, also known as “best practices”. The behaviour of these problems is unpredictable.
They have fuzzy boundaries and are highly connected to other problems. There is no way we can discover a clear root cause for these problems. Consider “We continuously have these crazy deadlines”. This can be because the PO is not inclined to split items small enough. Or maybe the sales department is not connected to IT R&D and promises impossible software ideas to customers with a set deadline. Maybe crazy deadlines is a team perception problem. Or maybe management thinks the teams are lazy and feels the need to raise the bar as an attempt to increase output. Wicked Problems have a series of root causes. It makes sense to say that there is no single root cause, but there are many root causes.
Applied solutions lead to other problems (unintended consequences). What makes problems wicked is that there are delayed effects hidden in them. Humans are not very good at understanding behaviour with long delays between an event and a delayed response. We tend to focus on the short term and look for short term relationships between cause and effect.
A great example cited in many Systems Thinking literature is the story of the Borneo cats, aka Borneo cat drop. The problem on the island of Borneo started when they were hit by Malaria in the 1950s. The World Health Organisation (WHO) was called to rescue. The WHO sprayed the island with DDT to kill the malaria mosquitos. This effectively killed the mosquitos which made malaria become contained. However, there were many unknown side effects: The DDT also killed wasps that normally would have eaten larvae which now became a plague and destroyed the thatch roofs that started collapsing on peoples’ heads.
Over the next eight years, animals like geckos, feeding on insects, stored an increasing amount of DDT in their system without dying of it due to their slow metabolism. Geckos are eaten by cats, but because of the high concentration of DDT in the geckos, the cats started to die massively. With the cats gone, a rat plague emerged, killing the grain stores and caused the plague. The WHO decided to parachute cats across the island, which stabilised the situation. (Read the story in detail).
Wicked Problems involve multiple perspectives. Wicked problems contain many layers, with many angles to consider when studying them. For example, when teams are slow in delivering software, ways of looking at this problem might be the organisational structure (siloed component teams?), the value stream (what is our product?), the costs involved (organisational optimisation goals?), the team happiness, etc.
Wicked problems are systems with complex behaviour. If we want to solve them or at least improve the situation, a behaviour change is required. We need to understand their behaviour to help us find an intervention that will make the system behave differently. We need to strive not to solve the problem, but to make intervention decisions that can improve the situation whilst limiting any possible negative consequence of the intervention. In other words: Solving wicked problems is often not possible, but understanding them is possible and beneficial. Let’s consider a homeless person. Giving a house to a homeless person is a possible solution. By studying the system, which is studying the dynamics that led this person to become homeless, might reveal that this person is mentally damaged and does not take any form of responsibility for his own life. Knowing this makes providing a house, not a solution that fixes the problem. This will only temporarily improve the situation or even make it worse in the long run.
Finding the right intervention.
When we think we understand a problem and we think to know how to intervene, then it makes sense to do so. However, if the problem reoccurs later, we know that we did not address a true root cause. For example, we might have a problem with the number of bugs being so high that there is no time available to work on new functionality. Sending every developer to a “clean code” workshop is likely to be beneficial in the short term. However, it is also very likely the problem will reoccur at a later point in time. What happened? We delayed the “setpoint” of the system to show certain behaviour. We did not apply an intervention that changes the behaviour of the system permanently. This is because there are other factors at play that have a stronger causal relationship to the number of bugs. (For example, the pressure on the team applied by the Product Owner causing too much work in the Sprint and causing the developers to cut corners in the code which creates bugs.)
Unravelling Wicked Problems is not easy. To better understand them we need awareness of two capital concepts: Cognitive Biases and the Imperfection of Modelling.
Cognitive biases are filters that we apply unknowingly when processing information. It’s like not being aware of the taste of water. Cognitive biases make us subjective: we interpret while we think we are being objective (observe). To be able to understand a Wicked Problem, we need to be aware of what our cognitive bias is in order to form an image in our brain that gets closer to reality. There are many cognitive biases. A very common bias is seeing what you want to see (confirmation bias). The belief that we experience the real world directly is called reality bias. In fact, we experience the real world by relating it to our past experiences and preconceived assumptions. We continuously compare the world around us with our understanding of the world thus far.
Imperfection of Modelling
It is important to understand that humans use models in their brain to make sense of reality. Our brain likes easily understandable simplifications of reality. However, we need to be aware that models are handy but never correct. Even Einstein’s best ideas were imperfect. His general relativity explains how the universe works in many situations, but it breaks down for black holes. That does not make relativity useless. The problem with models is that they pre-program (bias) our brain. You have a mental model about everything: lions, solar system, elevators, teams, women, Scrum, etc. They form your current understanding of those concepts. When you would study Scrum in-depth, you will adapt your mental model about Scrum. In summary, we need to be aware that models are both useful and imperfect.
How can Systems Thinking help resolving Wicked Problems?
A key aspect of Systems Thinking is it makes us aware of how our thinking works. Mental models are a core building block in our thinking. We know that models are imperfect and that our mental model, our understanding of reality, is skewed by biases. This awareness in itself is already valuable as it reduces the impact of our assumptions in trying to understand Wicked Problems.
Systems Thinking is different from analytical thinking. When we analyse, we take things apart to learn how things work. However, it is useless to take a British car apart if we want to understand why the British drive on the left side of the road. Where the answer to a question in analysis lies inside the subject we study, with Systems Thinking, it lies outside the subject. Systems thinking is thinking inside out.
Solving a Wicked Problem is Intervening in a complex system. If you face a very tough problem, it is a flaw to think it’s just one single problem. There are many factors, many interrelated problems with many root-causes to consider. To understand Wicked Problems, System Thinking advises to identify as many associated problems as possible and then bundle them in groups. Clustering or bundling problem groups and then labelling the groups will reveal first- and second-order effects in the system behaviour. Interventions on first-order effects are more likely to permanently change the behaviour of a system, i.e. solve the Wicked Problem.
Understanding Wicked Problems is useful for Scrum Masters when they cluster and unravel problems raised at the Sprint Retrospective, when they try to understand complex dynamics of the organizational system and when they try to understand what stops Scrum from functioning optimally.