How to Identify and Overcome Cognitive Biases on Agile Teams

Our brains are wired to notice patterns and to respond quickly, but not always correctly.

Throughout our day, we receive countless stimuli. We hear noises, we see movement, we smell scents—but to consciously process each and every one would be impossible. Because of this, our brains have developed ways to notice patterns and respond quickly.

Sometimes these patterned responses are helpful and a matter of life-and-death: If we are crossing a street and sense a fast motion from the side, we might freeze or step back instinctively. If we hear a loud yell, we quickly turn our attention toward it, attempting to determine if it is a danger.

Other times, the issue is less existential, and that same talent for reacting quickly produces harmful results. Let me share an example of a non-life-threatening scenario where ingrained responses lead to errors in judgment—or a cognitive bias.

I recently came across a research paper that studied how soccer fouls are perceived. The study focused on tackles, where a defensive player slides on the ground in an attempt to take the ball away from an attacking player. When a referee views a soccer match, sometimes the slide will appear to come from their left to right, and other times it will be viewed as coming from right-to-left.

The study found that people who read text from left-to-right (e.g., written English) are more inclined to perceive a tackle coming from the opposite direction as a foul. So, if the reader reads left-to-right, a soccer tackle coming from right-to-left is more likely to be viewed as a foul. But, a tackle from one side or the other isn’t actually more likely to be a foul; the referees’ error in judgment is influenced by the direction in which they read written text. Thus, players are penalized not because of their action, but because of something ingrained into the referees’ perception.

Given that reading direction impacts something as removed as soccer fouls, what other cues—or biases—might unexpectedly impact our behavior and perception? The biases mentioned above are just flawed response patterns that we typically don’t pay attention to. As a Scrum Master, Agile Coach or team member, it is important to be aware of potential bias and identify strategies to mitigate these biases.

Here are some examples of bias I’ve seen among agile teams, and ways to overcome them:

The Anchoring Problem

Humans often put too much weight on the first piece of information they receive. In other words, the first information we receive—even if it is completely unrelated to the main problem being discussed—will “anchor” us to certain perspectives. When someone offers their opinion first, they can anchor the conversation around that point. This is a common cognitive bias that comes up in areas like assigning story points to backlog items, and even in exploring technical approaches.

For example, if a team is sizing backlog items and somebody says, “I think it is an 8,” the estimate for that item is much more likely to cluster around an 8 than if the estimates were given independently. It is an unconscious act. People don’t consciously decide that they will move toward the anchor, they just do.

Luckily, there are numerous ways to minimize the likelihood of anchoring: One example is to use Planning Poker to get all backlog item sizes shared at the same time. In Planning Poker, all estimates are shown at the same time, thus preventing one person’s perspective from biasing the initial estimate.

Anchoring is not exclusively related to numerical situations. Conversations can get anchored, too. The first topic offered for discussion will anchor the discussion. If you are facilitating a retrospective, you could un-anchor it by allowing participants to do some “silent writing.” Silent writing is a technique where the facilitator proposes a topic or question, then gives participants some time to reflect and capture those reflections on sticky notes. Then, after having time to get one’s own thoughts captured, the facilitator asks participants to share their notes.  Silent writing is an excellent way to allow people to share their individual insights with less likelihood of getting stuck discussing the first topic that is proposed.

Finally, you can also reduce anchoring by generating multiple alternatives to seemingly obvious answers. Research has shown that having team members consider other plausible alternative outcomes for events—not just the opposite—can help de-bias judgments.

The Pronoun Problem

Do members of the team use “they” when referring to the team? When referring to one’s own team, the pronoun “we” is much more applicable because it implies collaboration.

Using “they” in place of “we” might highlight harmful boundaries. For example, if a Product Owner refers to the Scrum team as “they,” instead of viewing themselves as part of the team where a “we” pronoun is more appropriate, it implies that one might be able to succeed without the other, and that’s just not the case.

The Story Owner Problem

Some teams ask members to “put their name on user stories.” For me, the metaphor that comes to mind when I hear this is a dog marking his territory. It communicates, “This is mine, not yours. Stay away.” It is a dis-invitation to collaboration.

The team is responsible for delivering value by getting backlog items to meet the acceptance criteria. Skip putting individual names at the story level; it sends the wrong message.

How to Overcome Biases

As complex creatures, we are going to have cognitive biases and logical flaws in the way we reason. But pretending that they don’t exist, or remaining unaware of them, won’t help.

Additionally, even when we are aware that bias might impact our actions, we are still susceptible to them. So, given that, what is one to do?

Continue to increase your knowledge on the subject, and craft mechanisms that might minimize your error in judgment. Borrow techniques from other teams and companies. Be especially alert for where they might crop up in your workplace, and bring it to the attention of your team when they do.

Knowing that we have errors in judgment, make it safe to be wrong and be generous in your response when people have errors in judgment. Remember, you have them too, but you’re less likely to see your own.

Looking for more ways to cultivate a successful agile team? Get advice and insights on all things agile by visiting our blog.