3 Simplification Strategies you are using with your teams
and you may not even realise
There are three simplification strategies that scientists use to make sense of the world. Often we couch our work as agilists as being some kind of mad scientist for the team, running experiments, gathering data and trying to understand our teams the same way a scientist studies nature.
Dr Mazviita Chirimuuta of the University of Edinburgh writes about these simplification strategies as they apply to studying the brain and mind1. In the interest of exploring how tools and approaches from Cognitive Science can help us to build Intelligent Teams, I wanted to explore briefly today how they might apply to us in our work.
Why use simplification strategies at all?
The world out there is infinitely data rich and complex, yet somehow we are able to make sense of it and divide the world up into useful things. When a scientist chooses an object of study they can’t address the whole universe in one helping, there’s just too much complexity there. A scientist has to be selective in the way that they only choose certain bit and look for patterns amongst the chaos. These are simplification strategies - taking a complex and gnarly world and simplifying it into something more manageable to try to make sense of it.
Using these simplifying strategies is inevitable, you can’t make sense of the world without them. I’m arguing that we should be aware that this is going on in our thinking so that we do it consciously and don’t let the lenses that we use to help us actually blur our perspective.
Strategy 1 - Mathematicisation (ie turning things into maths)
When I count things and represent them numerically, I am essentially saying that they belong in the same group and I’m therefore more interested in the things they have in common than the things that make them different. If I count the number of people in a room I am saying ‘these 11 creatures are essentially identical for the purpose of what I’m counting them for’.
This is a bit of a mind bender - we’re so used to trying to represent the world through numbers that we forget that it is a particular strategy that we are using to make the world make sense to us. It’s not without its drawbacks. In order to make sense of large data sets sometimes you ignore outliers to make your graph look pretty and easier to interpret. Sometimes those outliers are actually significant, and by turning the problem into a mathematical one you miss the significant part.
As an example from the world of software - many agilists are familiar with cycle time - working out the average length of time it takes for the team to complete a piece of work. If I have a stable cycle time for my team I can use that as a proxy for their efficiency or performance, and maybe use that number to forecast when work will be done. I am simplifying the richness of the reality down to a useful number.
The problem is that with pretty much every team I work with, there is one project that has taken 20 times as long as the average and sucks up 80% of the team’s energy. The outlier is significant. When working out my team’s cycle time I can choose to ignore that outlier, or I can include it and skew the average. Neither is a ‘true’ reflection of ‘how long does the team take to do some work’.
On the other hand, some teams and types of work can happily use cycle times really effectively. If the work that comes in is relatively similarly sized and don’t tend to vary wildly then mathematising is a useful and reasonable simplifying strategy.
Both are ways of simplifying the richness of ‘the work’ into numbers that can be calculated. Sometimes it helps, sometimes it doesn’t. In either case it’s important to recognise that using maths on a problem is a type of simplification.
Strategy 2 - Analogy
Is the brain a computer? Is your software team similar to a manufacturing facility? Is your manager like an orchestra conductor or a prison guard? These are all analogies, where we take a problem and compare it to something else to see if there is something in common that helps us. This is a simplifying strategy, where we take our complex and difficult to access problem and try to compare it to something we already know about to make it easier.
The Computational Theory of Mind does this for the brain and mind, drawing a strong analogy between brains and computers. Whilst this allows for lots of cool technological advances in the field of computational neuroscience, it also misses lots of the important biological richness that is also taking place in the brain. By assuming that the brain is a computer, and that neurons are like the 1s and 0s of a binary computer, I miss out on understanding how other chemicals like neurotransmitters and hormones are also important for cognition, as well as the biological importance of the rest of the body.
The agile world is rife with analogies, as thinkers in the space have grappled with simplifying the domain of teams to something more tractable. We’ve taken analogies from rugby teams with Scrum and from manufacturing with Lean and Kanban. One minute my team is a family when I’m running a retrospective and using family therapy techniques, the next minute they are a nuclear submarine crew.
As with any simplifying strategy there are ways in which this is essential and ways in which it can be harmful. Toyota developed some groundbreaking ideas about manufacturing in the 1970s that helped make it a leading car company. There are ways in which my team is like a 1970s Japanese car company, and there are ways in which it is not. If I’m not aware that I am making an analogy as a simplifying strategy I’ll probably make some dumb decisions.
Strategy 3: Reduction
The third strategy is to take a complex scenario and break it into smaller more manageable chunks which allow themselves more easily to be studied. This is reduction. Ivan Pavlov did this when he looked at certain types of conditioned responses in doggies (I wrote more in depth about his here).
In his experiments Pavlov was reducing behaviour down to reflexes - he created strange and unnatural conditions to test whether a dog salivated upon the appearance of food and a bell, on the assumption that this would help us understand something about the same dog’s behaviour out and about in the wild.
The assumption was that by reducing something complex like behaviour down into something measurable and understandable like a reflex we could piece together the bigger picture. In the end Pavlov’s reflexology was of limited use in understanding more complex behaviour (and is mostly used now by marketing executives to make us buy stuff).
There’s an important lesson here. Some things can be studied very well by breaking them down into smaller problems which can individually be understood, and then reassembling them back together. Others cannot.
Often well intentioned managers will find a problem that can be controlled or understood and assume that if they improve that bit they will improve the whole team or department. Beware of anyone saying that the answer to making your team better is just psychological safety, measuring flow, or eliminating waste.
To be clear, those approaches totally might help your team. There’s nothing wrong with them per se. My argument is that focussing on just those elements is a type of reduction which you are using as a simplifying strategy to make sense of a situation. Use reduction, but do it with caution - maybe you’re being reductionist about a problem space that can’t be reduced.
And that’s all! If you liked this blog, you’ll love my conversation with Dr Chirimuuta coming out in the near future for the Agile On The Mind podcast. To make sure you catch it and all my blogs and podcasts about building Intelligent Teams with the help of agility and cognitive science, subscribe to Agile On The Mind. See you next time.
In her fascinating (and Open Access aka free) book The Brain Abstracted . We have an episode of of the Agile On The Mind podcast coming out in the next few weeks. Keep your eyes peeled (or just Subscribe to this substack)