Much of our professional behavior has been taught and learned. What we see from our colleagues is often just the shell around the oyster. This becomes really clear when we get under pressure. When cortisol levels rise, you (yes, you too) will fall back on your ‘basic’ behavior. This fact is of great importance in creating more effective scrum teams. Problems – impediments as we like to call them in Agile – can arise from this psychologic division between what we are expected to do and our actual behaviour. Let’s take you on a monkey ride.
Systems 1 and 2
Do we have a free will? Although scientists are in fierce debate on this, it is clear that most of the behavior that we exhibit is unconsciously driven. You can have an intense phone call in the car and suddenly realize that something ‘in you’ has led you safely through miles and miles of busy traffic. Professor Daniel Kahneman has spent his entire life studying conscious and unconscious behavior*. He has invented a language for this new field in behavioral science: unconscious behavior comes from ‘System 1’, conscious behavior from ‘System 2’. Where the latter can be seen as the wise grown-up in us, the first is more like an impulsive child. And the child does most of the decision making.
System 1 is extremely effective. Without this system we wouldn’t be here as humans (our great great grandfather would be eaten by the great great grandfather of the tiger many years ago). System 1 has no time (or need) for nuanced considerations, but works pre-programmed. Often it’s decisions are totally irrational. At the same time this system is a master of disguise, that conceals the idiocy of it’s decisions. We are good at fooling ourselves. A single program of system 1 is called a cognitive bias. And we all have quite a lot of them.
Biases in real life
As an Agile marketeer I use to describe the behavior of system 1 with the term ‘monkey behavior’. Marketeers want to persuade the monkey to buy a product. To do so, they should know what system 1 likes and chooses. In short: what’s the gain, where’s the pain? For most products that we don’t really need the marketing adagium is simple: ‘Beware of System 2 and close the deal when in System 1’. Provided with enough time, your wannabee customer might start to wonder if he really needs your product, what else he could do with the money and if the fact that he likes you is actually a good reason to buy product X. No, we want him to be minimally involved.
Scrum teams under pressure
A Scrum team consists of people. In scrumming, the stress increases towards the end of the sprint. ‘My God, we will never get that functionality finished in time!’, ‘That bloody PHP programmer has been sleeping, look what a monster of a bug I got out of testing!’. As you might have noticed at the end of a sprint, Scrum is often exchanged for Kanban (we call this scrumban). But more important: as the sprint deadline comes near, we get insights in team members; In behaviour that not only surprise us but can also be highly counterproductive.
So we need our team members to stick to the plan. But these are not robots but people of flesh, blood and feelings. We could train our team to cope better under stressful situations. We could make protocols on what to do when cortisol-levels rise. We could call on more leadership, punishment even.
A wise product owner of scrum master would know the ‘stress’ pattern, see the implications upfront and take measures in the beginning of each sprint. This is a wise thing to do, but in most cases ineffective. It is always good to be one step ahead of things, but in my opinion this will not solve the issue. People will still fall back on their basic behaviour and act like, well, monkeys. Increase of management pressure on already stressed-out team members will not make them more productive. On the contrary: they will stretch and bend but eventually break. They end up sick. And team members that drop out (thus increasing pressure on the remaining ones) is the last thing you want.
Biases in scrum projects
Before coming up with a solution, lets first introduce some cognitive biases that play a role in scrum projects. I will give some examples, but the list of biases applying is sheer endless. My three examples ‘hook’ on three agile basics: be agile, be open and be communicative. Note that insights into this matter can be worthwhile for both product owners and scrum masters, depending whether the issue concerns products (PO) or processes (SM). And in my opinion these insights are mandatory for Agile coaches.
Bias example 1: Tendency to Consistency (anchoring)
This cognitive bias, in short, states that people have a tendency to hold on to their behavior and choices, even if they are ineffective or incorrect. The core of Agile is that we act fluently, that we move with the changing tides. But this is a system 2 thing. As explained, under stress we fall back on system 1. This means that we no longer act fluent, but rigid. We tend to stick to the plan even if we know that it’s not the right way to go. This is not very Agile and certainly not creating value for our customer. But it is the way humans work.
Bias example 2: Bandwagon Effect
This bias concerns the tendency to do (or believe) things because many other people do (or believe) the same. Groupthink, in short. Scrum teams are self-managing and the team members ‘self-thinking’. Peer review is a formalized tool for control, but the courage to go against the current should be in each team member’s DNA. And often, in our rational system 2 it is. But as you guessed already, when system 1 takes over ‘herd behavior’ arises. This can have disastrous effects on product development.
Bias example 3: Curse of Knowledge
A scrum team consists of specialists. Bright people that are (hopefully) the best in their field of expertise. But they are part of a multi-disciplinary team. And that’s where the Curse of Knowledge Bias comes into play. When system 1 is activated, better-informed people find it extremely difficult to think about problems from the perspective of lesser-informed people. And that can be very frustrating for both parties. If they not manage to get in line, the product development is in serious danger.
Feed the Scrum Monkey
My advice is to feed the monkey. Feed it in a way that relieves the stress, so that system 2 can be activated again. And just as monkeys, human beings (read: your team members) have their own preferences for food, tastes, flavours.
A good team lead gets to know all team members and their unique blueprint upfront. An introvert team member might need a room alone to focus and reduce stress levels. The extravert specialist on the other hand might need more peer review to regain self confidence. This personnel ‘manual’ is best explored in a non-stress setting. The monkey rock is not seldom the fine pub just around the corner. Or the face-to-face lunchbreak. Investing in people gives you tools to manage them when the are stressed out. To get them back to system 2 and make the best possible product for the customer.
A good team lead is also a foreman. Someone who jumps in the gap for his or her team members if they encounter severe difficulties. It is the mission of the Scrum master to remove obstacles, especially when they are stress related. As a product owner you might have chosen never to interfere with the content, but there is always a grey area. Getting the pressure from the boiler creates trust in you as a competent leader and lowers stress levels. Be agile in this.
Last but not least, a good team lead is a coach. I don’t refer to the Agile coach (whose focus is on the Agile process), but a listening ear. Who takes up the role of mediator to mediate between team members, especially when they do not understand each other. This is not solely a mission for the scrum master but also for the product owner and any other team member that can take up this role.
A scrum team consists of people and especially when under a lot of stress, people show primary behaviour. Like monkeys. Instead of caging the monkey, we’d better feed it. There is suitable food for everyone. Know your team members and you know what to give them when the going gets tough. Instead of getting a new coloured ‘belt’ in Agile you might want to consider a degree in psychology.
Tip: As a PO or SM beware of the ‘Blind spot bias’. This bias – also called the Bias Bias – concerns the tendency to see oneself as less biased than other people 🙂
* I recommend Kahneman’s book ‘Thinking Fast and Slow’.