By Nick Butler
Tags: Agile
Playing with Lego has led scientists to identify a new cognitive bias. Recent research shows that our brains are wired to solve problems by adding not subtracting, even when subtraction is the way to go.
This presents a challenge to the Agile principle of simplicity. If we’re going to follow the principle, we’ll have overcome the bias to make things bigger. This post shows you how.
Here’s principle 10 of the Agile manifesto:
Simplicity — the art of maximizing the amount of work not done — is essential
Many people are initially confused by this principle. Shouldn’t we be doing more work? But Agile isn’t about maximising work, it’s about maximising value.
Agile simplicity lets you achieve your highest priority: satisfying the customer by delivering valuable software early and often. That way you can test that the software really is what your users need. You don’t clutter your application with unneeded or unusable features.
The key to delivering value early and often is working in short iterations on small, simple improvements.
The research was carried out by an interdisciplinary team at the University of Virginia.
It all started with Lego. Leidy Klotz, an Associate Professor in the Engineering school, was playing with his son Ezra. They were building a Lego bridge but one column was longer than the other, leaving it wonky and unstable. Leidy reached for a brick to lengthen the shorter column, but before he could, Ezra removed a brick from the longer one.
This got Leidy thinking. He teamed up with Gabrielle Adams, Benjamin Converse and Andrew Hales, colleagues from the public policy and psychology faculty. Together they designed a series of experiments to see if we add when we’d be better subtracting.
In one experiment, they gave people a Lego structure with a top platform supported by a single pillar.
When asked to make the top platform more stable, test subjects tended to add more pillar support bricks, rather than remove the existing one.
When subjects were told that each piece you add cost ten cents but removing pieces is free, they were much more likely to remove a piece. So the way the question was framed influenced the result.
Similar results were found when subjects were given a patterned grid and asked to make it symmetrical top to bottom and left to right by making the fewest changes possible.
The easiest thing to do is to change the 4 orange squares in the top left corner to white. But many people added 4 orange squares to the other 3 corners.
The effect was even greater when people were given another task to complete at the same time, bumping up their cognitive load.
Researcher Benjamin Converse explained it like this.
“Additive ideas come to mind quickly and easily, but subtractive ideas require more cognitive effort. Because people are often moving fast and working with the first ideas that come to mind, they end up accepting additive solutions without considering subtraction at all.”
Sometimes it takes years for humans to see the benefits of simplifying something. For decades we taught kids to ride bikes by adding training wheels. Then along came balance bikes, and we realised that all we needed to do was remove the pedals.
The preference to solve problems by addition is an example of a cognitive bias.
Cognitive bias is the tendency to make calls in ways that aren’t optimal. Other examples include anchoring (letting random numbers skew our decisions) and framing (being swayed by how a situation is described).
Amos Tversky and Daniel Kahneman developed the concept nearly 50 years ago and it hit the mainstream with the publication of Kahneman’s bestseller Thinking, Fast and Slow.
Much as I hope this new cognitive bias gets dubbed the bias to embiggen in honour of The Simpsons — those exemplars of sub-optimal behaviour — it’s more likely to be known as the additive bias.
In Thinking, Fast and Slow, Kahneman presents a solution to cognitive biases.
You can treat your brain as having two different systems, he says. System 1 is fast, automatic, emotional and unconscious. System 2 is slow, effortful, logical and conscious.
To beat cognitive biases, we need to engage System 2 to back up System 1’s rapid responses. And because System 2 is lazy, we need to do this consciously.
So what are some ways we can consciously look to simplify and subtract?
For years, people have found different ways to express the power of simplicity:
Agile even has its own mantra of simplicity, courtesy of Extreme Programming: YAGNI, short for You Ain’t Gonna Need It. The idea is you only build what you know you need now.
Why not pick a new mantra as a team every few iterations and post it prominently on your team board?
Frame the questions you ask in ways that keep simplification and subtraction top of mind.
For example, rather than asking “how can we improve this interface?”, ask “how can we simplify this interface?”.
Plan and scope your projects to keep them as small and simple as possible. Hopefully you’re doing that anyway, because small projects are 4x more likely to succeed than big ones. You can find out how to run successful projects by keeping them small here.
Keep your iterations short and each batch of work small. Running through checklists can engage System 2, so consider checking your requirements to make sure they fit the INVEST criteria. You can get examples of user stories that do and don’t meet INVEST criteria here.
Stick to work in progress limits. This avoids the cognitive overload that comes from context switching, giving System 2 room to move.
Don’t do more work, do the most valuable work. Here’s our guide to prioritising the work that delivers the most value.
This can include deprioritising work you’ve done in the past. For example, you’ll sometimes want to remove existing features that aren’t getting much use.
Break up your routines and don’t do what you always do. Coming off autopilot forces you to concentrate. The Smiley face game is a great illustration of the power of second thoughts.
Use the Five Whys to make sure you’re addressing root causes. Often this means you can subtract work, simply because you solve the problem once, not each time it flares up.
Set aside time to put System 2 to work. For example, give the team time to review the backlog the day before sprint planning or backlog refining. That way they can consciously think of ways to simplify the work ahead.
Collectively coming up with your own ways to activate System 2 means the approaches you pick will make sense to your team.
Maybe you could run a retro to design your own solutions, especially if you’ve found that you’ve been adding work when cutting it would have been better.
Agile methodologies are set up to use our System 2 brains. You’re always consciously inspecting and adapting your product and process to ensure you’ve come up with the best solution.
The good news is that this helps train your System 1. The more you simplify, the better you get at it.
Thinking, Fast and Slow on WorldCat — find copies in a library near you
