How ‘Thinking, fast and slow’ applies to your Agile team


By guest blogger Anders Ivarsson

I just read Thinking, fast and slow by Daniel Kahneman. It’s a great overview of how the mind works in some different situations and problems that this commonly leads to. So many of the concepts are directly applicable to teams, organisations and software development.

Note that all of those concepts, effects and behaviors are validated and proven over and over in many studies  – so even if you believe that they are not true for you or for your team, they most likely are.

Question substitution

Question substitution is replacing a hard question with a simple one – without being aware of it. In our setting, my guess is that this happens a lot. Consider the question “How likely is it that this project will be finished on time?” It’s a very difficult question to answer and requires a lot of analysis. It will be much easier answering the question “How do I feel about my current tasks?” or “How likely is it that I will finish my tasks on time?” and I believe that this is what most team members will answer when they are asked about the likelihood a project will finish on time.

It has also been proven that if you like something, you tend to overestimate the positive effects and underestimate the risks and negative effects. This means that if you believe in the product or new feature that you are building, you will likely believe that the positive effects of the product will be bigger than they really will, and you will most likely believe that the risks of building the product is smaller than they really are.

Those are serious biases that needs to be taken into account when prioritising and estimating different features or projects.

Smiling and frowning

Male portrait

When you work on a very hard task, you will start frowning. And when a task is easy, you will start smiling ever so slightly. It turns out that it works the other way as well – if you are frowning you will actually find that solving a task takes a bit longer, requires more energy and will fail more often.

Happy man

The lesson is clear – make sure that you create an environment where people are smiling a lot, especially when trying to solve tricky problems.

Energy depletion

When we engage in tasks that require hard cognitive work, the body will use a lot of glucose. This leads to energy depletion fairly quickly and this has a huge effect on our ability to perform well in cognitive tasks or logical decision making. A study showed that judges in Israel would approve parole for as much as 65% of their cases right after a meal, only to lower that rate significantly and be close to 0% after two hours.

So when you conduct meetings, retrospectives and planning sessions – make sure that all participants can refill their glucose levels every hour, or they will not be very effective.


There are several different states of mind when a person is more likely to listen to their gut feeling and disregard facts or critical thinking. One that stands out for me is the feeling of power. When a person feels powerful, they are more likely to listen to their intuition and disregard facts. This is worth keeping in mind when working with management, team leads and product owners – they might need an extra reminder to look at the numbers, take a step back and consider something more thoroughly and challenge their intuition.


The anchoring effect is a phenomenon where hearing a number will greatly influence your ability to estimate something. For example, if we ask our team to estimate a project that we believe take approximately 5 months, that number will create a very strong anchoring effect and any estimate will be greatly affected by this number. Always try to avoid anchoring if you can – this is one of the reasons for why planning poker is very useful for creating estimates within teams.

This holds true even if you know that the number has no connection to what you are estimating, if it is random or obviously false. The scary thing is that this effect holds true whether you are guessing numbers you don’t really know (such as the age of Gandhi when he died), and also when deciding numbers that are part of your expertise. This has been proven on real-estate agents estimating buying price of a house, judges deciding prison sentences and software teams estimating the size of a project.

The anchor index in different studies is usually in the range of 30-50%, which means that raising or lowering the anchor will change the estimate with 30-50% of that. It’s a huge effect!

Planning fallacy

Plans and forecasts tend to be unrealistically close to a best-case scenario. One reason for this is we plan for everything that we can foresee, add some margin for foreseeable risks, but we’re completely unable to take into account risks that we do not foresee.

If you work as a project leader in a company that has only completed 20% of their projects on time, budget and scope, then a good guess is that you only have a 20% chance to complete your project on time, budget and scope.

One way to avoid planning fallacy is to use statistical information from similar ventures. When a team estimates how long it will take them to release their feature on a new platform, have them look at how long it has taken other teams to release features on that platform. If the estimate is still very different, challenge them on why they believe they will be faster or slower than most other teams.


Individuals and organisations tend to be overly optimistic about their chances of success. The more coherent a constructed plan feels, the more confident you will feel about it. A way to avoid this is to run ‘premortems’.

We are all familiar with postmortems – gathering everyone after the end of a project or iteration to figure out what went wrong or how we could have improved. The only problem is that those postmortems are held after the fact. Instead, before you commit to any major decision you should run a ‘premortem’ session where you ask the team to “imagine that we are a year into the future. We implemented the plan as it now exists. The outcome was a disaster. Please take 5 to 10 minutes to write a brief history of that disaster”. This is a great way to challenge a team to think about risks and doubts that they have been unconsciously suppressing because they feel confident about what they’ve planned.

Anders Ivarsson will speaking about Spotify’s Agile implementation at Agile Australia 2015, and leading a workshop on ‘Organisational Improvement: Design inspired Problem Solving.’


This blog post was originally published in the AgileTODAY publication, and on his blog.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s