Optimism can be a bias.

Optimism can be a bias.

 

Cognitive biases can affect projects in every step in which humans are involved. The impact of cognitive biases tend to clustered around how people behave and how they communicate. Cognitive biases are not just psychological theory. As an example of the impact of cognitive biases on real life, lets use a typical planning meeting to provide examples of how common cognitive biases can impact an Agile project.

A typical Scrum planning session is a two-step affair. In first step of the process, the product owner selects the work he or she wants to accomplish in the current sprint from the prioritized backlog. The product owner is acting based on business value and input from the team and other stakeholders. While the selection is made based on an informed process, the mere fact that an amount of work has been places on the table leverages the anchor bias and sets an expectation of what is needed. The discussion that occurs during the first step of the process can be impacted by the cognitive bias of each individual participating. The types of biases can range from the halo effect (overweighting the input from an individual based on another attribute), intergroup bias (ideas constrained by the teams boundaries) and if the product owner is not listening to external stakeholders. This is a form of the bandwagon effect in which the product owner pulls the team with him or her.  Coaches need to spend time to facilitate ensuring that the backlog is prioritized well (real business value that has been vetted) and that the selection process is sensitive to the team’s capacity (selecting to the team velocity or productivity rate).

During the second step in the planning process the teams breaks down the work and determine how much they really can accomplish and that they commit to completing. The team begins with an understanding of what they are being asked for (the other side of the anchor bias) from the first step in the process and any further conversations that occurred while the work was being selected. Once they have the list from the product owner they can begins to plan (identify, order and size tasks). The planning process is apt to be affected by many of the planning and motivational biases noted during the first step of the process and other that are more prevalent in the IT personal. For example, optimism bias, which is the tendency to be overoptimistic about favorable outcomes (IT personnel are trained problems solvers and generally have not met a problem they do not think they can solve), can lead a team astray when addressing uniques business or technical problems. Another bias that impacts planning is the planning fallacy. The planning fallacy is the tendency to underestimate task completion times (remember all those late nights late in a project trying to get things done).  Dr. Ricardo Valerdi in an interview for the Software Process and Measurement Cast 84 stated that his research has shown that IT personnel are overly optimistic when planning and estimating which is a reflection of an assortment of cognitive biases. The power of group planning sessions is that many eyes can be brought to bear on the topic and assuming that the team has not become insular and fallen prey to intergroup bias, a diverse team will be able to avoid many of the biases that plague individuals. During the team component of the planning process the Scrum Master or Coach should observe how the team is interacting and to facilitate the interactions among the team so that the diversity is used to plan the work.

The discussion of cognitive biases is not a theoretical exercise. Even a relatively simple process such as sprint planning in Scrum is influenced by the cognitive biases of the participants. Even the planning process itself is built to use cognitive biases like the anchor bias to help the team come to consensus efficiently. How all the members of the team perceive their environment and the work they commit to delivering will influence the probability of success therefore cognitive biases need to be understood and managed. All team whether Agile or not need to ensure that the biases we all carry do not lead us astray.