Anchoring (a Cognitive Bias) Can Affect Outcome

Anchoring is a cognitive bias about the human propensity to rely on the first piece of information when making decisions. Anchoring can stifle creativity, eliminate alternatives, and affect outcomes and decisions. This article provides a real-world example of calling out anchoring bias and taking action to provide a fair environment, and the difficult but necessary consequences that may follow.

Leading the Witness

Ron is a team member on a newly formed Scrum Team. Prior to being appointed Ron had worked alone building prototypes and solving technical problems for several stakeholders.

Once Ron became part of a team serving those same stakeholders he often struggled with sharing the knowledge and the notion of collaborative work. He frequently pointed out to his new team how he should be their Product Owner given his prior experience and knowledge.

Ron began adding items to the Product Backlog and prioritizing them to the top.  He felt these work items are necessary even though the stakeholders and customers had not asked for them.

Ron also brought up topics at the Sprint Retrospective he felt were important.  However, the team rarely voted to discuss his topics as they usually felt there were other more critical issues.  This frustrated Ron.  A day before a Sprint Retrospective he printed a list of topics and placed a copy on every team member’s desk along with issuing a directive to the team that these were the topics they would discuss at the next Sprint Retrospective.

Difficult Conversations

I do not like confrontation but as a Coach it is our job to help people understand the process and to reflect what we see and the impact they are having.  This means difficult conversations that require tact and empathy, and despite our best efforts sometimes it doesn’t go well.

I called Ron aside and tried to explain how he was influencing the team by declaring he was the expert and then overriding the Product Owner by indicating what work to do next.  I attempted to reflect on the impact of how he was influencing the team by re purposing a Scrum event and giving them an agenda for the Sprint Retrospective.  I gave him several specific examples of how this behaviour in the past had directly impacted the team’s decisions.  I then offered to help Ron get his thoughts across to the team by finding time in the next Sprint for him to explicitly discuss his work and improvement ideas.

Ron did not respond well to this feedback and summarily threw a temper tantrum, tossing his papers in the air, slamming the meeting room door open, storming through the team area, openly crying, and telling each and every one of the team members that I was unfair because I had upset him, was controlling him, and wouldn’t listen.  Needless to say the team was upset and blamed me for upsetting Ron.

Given the response I often ask myself what I could have done differently.   These are lessons for another day, but I strongly believe would not have been an effective coach if I had not spoken up about the anchoring and subverting of the Scrum Framework that I was witnessing.

The Impact

In this case, Ron was providing product backlog items and agenda topics, thereby anchoring the team in what they should work on, how they should do it, and even what topics they should discuss.  In essence he was forcibly attempting to bias the team and affect their outcome.

Although it was a difficult conversation I feel it was necessary to call out the bias I was witnessing and the impact it was having.

As humans we need to be aware of the many biases and prejudices we are subject to.  Unless we are impacted we are often often ignorant to their existence.  I cannot claim the moral high ground because I am just as guilty as anyone else of bias and prejudice, however by writing a series of articles I hope to educate myself and others to recognize patterns so we may all take appropriate action to mitigate or eliminate them.

If you find this useful, please consider contributing with our
“Value for Value” model.