Are Our Decisions in Agile Free of Cognitive Biases?

"I knew this release was bound to fail. We shouldn't have hurried." If you ever heard a Scrum Master mentioning this, he/she could be under the influence of a "hindsight bias." Another scenario is when an Agile team agrees blindly with a confident-sounding (and looking) Product Owner without empirical evidence, they may be subject to the "halo effect." Or, when a tester in good mood agrees to execute 40% higher test cases than their previous average, the tester may be experiencing "optimism bias."

I know, some of you could now be thinking: "That is what Agile is all about. We need to try out and experiment. It could be wrong, but learn lessons from it."  Agreed! But what about understanding the scientific reason for flawed decision-making, which if addressed appropriately, could minimize some of these errors? I am referring here to a psychological phenomenon called "cognitive Bias."

Cognitive bias is a well-researched area in psychology from the1970s onwards. It was originally proposed by Amos Tversky and Daniel Kahneman in a groundbreaking paper titled "Judgment under Uncertainty: Heuristics and Biases." In the field of psychology, cognitive bias is a systematic error in thinking that occurs when people are processing and interpreting information in the world around them and affects the decisions and judgments that they make.

Being a people-centric model, Agile is subject to many cognitive biases. It is important for an Agile leader to be aware of these biases and not allow them to impair a fair and rational decision-making process. Following are some of the cognitive biases that are common in an Agile world.

1. The Confirmation Bias

Confirmation bias is favoring information that confirms our existing thoughts and beliefs. If we like Apple over Android, the information around us will appear to confirm that our choice is good. Social media has amplified this effect, and in many cases is manipulative to influence our perception by only showing us what we like to believe. In Agile, our belief that team morale and cohesion are good may be influenced by the positive signals that we decide to receive. Being aware of this bias will help us to watch out for negative emotions, complaints, lack of interest, etc., and make suitable interventions in a timely manner.

2. The Anchoring Effect

The anchoring effect is the tendency to overly get influenced by the first piece of information, even if it is wrong or irrelevant. If a friend mentioned that she bought a used car for $20,000, our decision to buy a car gets influenced by this number, even if our budget, needs, and driving pattern are way different than hers. This effect is most at play in Agile during estimating and iteration planning discussions. Estimates of size and effort might get influenced by the first information that will get anchored in the minds of the Agile team. Again, the trick here is to approach estimation empirically and use our best judgment without depending too much on the "false baseline" value.

3. Planning Fallacy

Planning fallacy is the tendency to underestimate the effort required to complete an activity, even if it contradicts our historical data. If a student takes 5 days on average to complete a project but agrees to submit the report for a new project in 2 days, planning fallacy is in effect. In Agile, planning fallacy can lead us to take wrong decisions with respect to releases, promised business value, etc. SAFe 5.0 has handled this beautifully by asking us to classify Program Increment (PI) objectives as committed and uncommitted. The best way to handle this bias is to rely on data rather than intuitions, especially when it comes to making commitments.

4. Availability Heuristic

The availability heuristic influences our decisions based on information that comes to mind quickly and easily. If we happen to see Rafael Nadal in the London airport, we tend to believe that Rafa will win that year's Wimbledon, despite his poor track record on the grass-court (disclosure: I am an avid Rafa fan :)). Availability heuristic affects our rational decision making while working on Agile teams. A customer's mention of a particular feature during a Sprint Review meeting may lead us to believe that it is the most valuable feature, despite the Product Owner having his/her own rationale in ordering features based on business value. It is best to base our decisions on collective knowledge and not on chance occurrences of easy and quick information.

5. Bandwagon Effect

The bandwagon effect refers to our habit of following the crowd and doing something because everybody else does it. I majored in Electronics and Communication Engineering for my graduation because most students in my class believed that it was the right thing to do, despite my liking for Computer Science. We tend to buy coffee from Starbucks because there is a long queue; therefore, the coffee must be good. This following of popular opinion is very tricky. In many cases, the large number of people making a choice could actually mean that the choice is good. However, it is important that we keep our minds clear in evaluating the choices clearly as per our individual, team, and organizational context, before following the crowd. A good number of Agile teams may follow SAFe as a framework for scaling because it works for them. That doesn't mean we should abandon Kanban and switch to SAFe only for that reason. Evaluate the frameworks rationally and make an informed decision.

6. IKEA Effect

The IKEA effect is the unreasonable value we place on things that we helped build. We may be willing to pay more for the furniture that we assemble (and spend additional effort) than buying an assembled piece from a store. This is a classical bias in Agile. The Agile team will be unwilling to throw away and stop working on a feature that they spent weeks on, even if the customer says it is not of any use to them. We get tips to handle this bias from good old Project Management principles themselves. When taking a decision to invest more, ALWAYS ignore the sunk cost. Even if you spent 6 months building a feature in .Net, and you realize that it cannot be integrated with a third-party application that the customer is using, do not try to justify and build further. Make a decision and move on. That will be the best decision economically, though not emotionally.

Final Thoughts

There are hundreds of such cognitive biases, which social scientists are uncovering and explaining on a regular basis. While it may be practically impossible for us to be devoid of all of these, it may be in our best interest as Agile leaders and practitioners to be aware of them and rely on scientific evidence to reduce our probability of being wrong. 

Our mind has infinite authority over all our actions, and hence, it is important to learn more about how it behaves in situations. After all, Agile is all about mindset. Like the Napoleon wars, the Agile project gets first executed in our mind, and then on JIRAs, GitHub, and Jenkins.