Not all puppies and kittens.

Cognitive biases are important decision-making tools.  The help to make snap decisions based on patterns of behavior that have been successful in the past. However cognitive biases are not all kittens and puppies.  Cognitive biases can also lead us to miss problems we are not trained to recognize or to ignore better solutions to problems we have solved before.  With some rules, effort, and support most of the problems caused by cognitive biases can be avoided. Tools to avoid the downsides of cognitive biases include:  (more…)


Creative thinking can help you combat cognitive biases.

Cognitive biases are shortcuts that people use in decision making.  The shortcuts generated by cognitive biases are typically helpful, which leads to people to internalize the bias. These internalized biases are therefore used unconsciously.  Any behavior that becomes an unconscious response can lead to actions and decisions that are perceived as irrational if the context or the environment has shifted.  For example, a colleague recently related a story about an organization with an emergent product quality problem that occurred after they had disbanded their independent test group. The response was to immediately reconstitute the test group based on the belief that if the independent testing had worked before it would work again. The response was based on a cognitive bias, not a root cause analysis or some form of mindfulness.   (more…)

Five Dysfunctions of a Team

Five Dysfunctions of a Team

It is nearly 2017!  Today we complete the re-read portion of the Re-Read Saturday for The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing).  This installment covers the section titled Understanding and Overcoming The Five Dysfunctions. This section is the most hands-on portion of the book and I suggest spending time with the wide range of ideas Lencioni peppers throughout this section. Note that there are three very short sections that follow the Understanding and Overcoming section. They are interesting reads; however, I will leave them to you to review.  Next week we will conclude this Re-Read with final thoughts. (more…)

What you see is dependent on what you expect.

What you see depends on what you expect.

Cognitive biases are a pattern of behavior that reflects a deviation in judgment that occurs under particular situations. Biases develop as filters or shortcuts that help us perceive information quickly in a manner that turns out to be beneficial to a decision-making process. Biases that help us recognize patterns helped early humans stay alive by recognizing predators. The shortcut kept our ancestors alive even if there were false positives (you can survive lots of false positives, but you aren’t likely to survive a false negative). Project teams (Agile or not) use or fall prey to a wide range of biases that affect perceptions and decisions. A sample of common biases that affect project teams in this category include:

Anchor bias refers to the tendency to rely heavily on one piece of information when making decisions. This bias is often seen when early estimates for a project or a tasks are made. The instant they are placed on the table they become a reference point to which all changes will be compared.

Clustering illusion (or clustering bias) is the tendency to see patterns in clusters or streaks of in a smaller sample of data inside larger data sets. For example, a team I recently worked with had an average velocity of 30 story points per sprint (ranged between 20 – 36) had three sprints in a row that delivered 40+ story points. While nothing significant had changed with how the team was working, outsiders saw a pattern and believed something out of the ordinary was occurring. (FYI – if there is no statistical significance to the data what we are seeing is “common cause” variance.)

The curse of knowledge bias generates a filter that blocks the ability think about a topic from a different and generally less informed perspective. In many cases being an expert on a topic makes it very difficult to see an out-of-the-box solution. This is one of the reasons significant changes in IT platforms or concepts come as new players enter the organization that have less experience with current tools and techniques. In a similar manner to the curse of knowledge, the status quo bias or the tendency to want things to stay relatively the same, creates a perception filter that helps the individual or team seek out and fixate data and concepts which makes them comfortable so they do not need to change.

An availability cascade causes a concept to become more and more plausible the more it is repeated publicly.  An availability cascade generates a self-reinforcing feedback loop. Perhaps that is why Pokemon became more popular the more it was shown on the Cartoon Network. Daniel Pink, author of To Sell Is Human, in a Salesforce.Com webinar on July 9th pointed out that repetition increases process fluency, which makes the repeated item seem to be more true through repetition. Sales, marketing and 24 hour news channels understand and use the availability cascade bias to great effect.

A final example of biases that affect behavior and perception is optimism bias. Optimism bias is the tendency to be overoptimistic about favorable outcomes. This bias is often exhibited in status reports or in promises made early in a project. These are generally not lies, but rather due to optimism bias we believe that we can deliver. Dr. Ricardo Validri in Software Process and Measurement Cast 84 suggests that optimism bias is one of major reasons IT personnel are poor estimators.

This is a sample of cognitive biases that affect how we perceive information and then how we make decisions. Each of the biases reflects some basic component of human psychology and has been found to be generally beneficial. However all biases can create blind spots. A good coach or leader will first be aware of his or her biases and then help the team understand their blind spots while not abandoning the shortcuts that can help us perceive what is important and make timely decisions.

An archetypal user of dresses.

An archetypal user of dresses.

A persona represents an archetypical user that interacts with a system or product. Typically the first introduction a developer or product owner might have to the concept is when they are writing user stories in the form of <persona><goal><benefit>. If the concept of persona was just used in user stories they would be interesting, however personas have other uses. Other uses of personas include:

  1. Identifying requirements. Personas provide teams with a platform for developing scenarios that incorporate both who will use the system or product and how it will be used. Scenarios delineate purpose-driven interactions between a persona(s) and the product or system. The expectations, motivations and needs defined as part of a persona gives team members the information needed to playact solving problems as if they were an archetypical user. This allows the team to mirror real content and usage without tying the scenario to a specific system solution.
  2. Guiding decisions. As the development process moves from user story to delivered functionality, teams will make innumerable decisions. Personas help teams make better decisions by providing them with a tool to ground or justify a decision. I recently watched a team use a set of personas to make a decision about how they would structure a user survey. The team asked themselves how each persona would react to the design choice being considered. Several tweaks were adopted based on how the team felt the personas would react. The team in question keeps a copy of each persona on the wall in their team room and references the personas as a matter of course. A secondary impact of using a common set of personas to guide decisions is foe the team to align to the common goal of being user focused.
  3. Identifying releases.   While there are a wide variety of release strategies including continuous deployment and minimum viable products, teams and product owners often struggle with grouping functions and features for release. Personas can be used to identify which features and functions are related so that a release can used to solve a persona’s (or group of personas’) specific needs. I often use personas and the scenarios used to generate requirements to identify a minimum viable product.  Once a release candidate is identified I ask the team whether the group of functions being considered could be used by a specific persona and then whether the use would generate useful feedback. If the answer is yes for this part but no for another part, the release can be trimmed down to just the yes part. Alternately if the answer is no because we need something else, I generally start the campaign to increase the prioritization of that “something else.”
  4. Facilitating communication. All projects require well thought out communications. Personas provide the team with information needed to plan communications. Jo Ann Sweeney, author of the Explaining Change column on the Software Process and Measurement Cast strongly suggests that knowing your audience is a critical step in getting communications right (albeit she says it with a British accent). Personas are a tool to define your audience. The details of the persona’s needs, motivation and backstory provide a wealth of information needed to shape and develop a communication plan.

Personas are not just for user stories. Personas represent a lot of valuable information about who will use the system or product  the intrinsic benefit they expect. The information documented is useful across the entire development life cycle. A simple way of reminding a team that it really isn’t just about the system or product is to tape the personas to the project team room wall to create information radiators that remind the team that the users have an identity.

Affinity Diagramming With Multi-voting

Affinity Diagramming With Multi-voting

Affinity diagramming is one of my favorite quality techniques. The technique is useful in any situation that requires generating ideas or getting a team talking. After generating ideas the technique provides a platform for organizing those ideas. I have used the technique for any scenario in which brainstorming would be appropriate, such as requirements definition, solution generation, process improvement and retrospectives. Affinity diagramming is generally a group technique with a facilitator acting as an anchor.

You need:

  1. Sticky notes (square, 3 inches by 3 inches)
  2. Flat surface (wall or other flat surface)
  3. White board/Flip Chart and dry erase markers

The process:

  1. The first step in the affinity diagramming process is for the facilitator to generate a set of framing questions that will be used to elicit ideas, comments or statements about area being studied. For example
  2. The second step is brainstorming. The facilitator will use the framing questions to get the team to generate ideas, comments or statements. As the team members think of a comment based on the framing question, they write the idea on a sticky note, call out what was written and then hold it up for the facilitator to post on the wall or other flat surfaces. Lettering on the sticky note should be able to be read from across the room. The brainstorming process goes on until the team has exhausted the subject or the time box is used up. Small sticky notes are used to ensure that each note contains a single, short idea.   Typically a team of 5 – 9 can generate 50 to 100 sticky notes during a 30 minute brainstorming session. The facilitator should ensure everyone participates. The facilitator should shift the seed questions as idea generation slows down.
  3. After the competing of the brainstorming phase, the team goes to the wall (or other surface) and re-arranges the sticky notes without conversation. The goal is to discover the relationships in the data. Time box the mute mapping exercise to about 1/3rd of the time of the brainstorming phase. A team is done re-grouping the data when everyone sits down or one item begins shifting spots without other changes. The facilitator should ensure everyone participates without talking. While atypical, not all items will be able to be grouped. Occasionally one or a few ideas will be outliers.
  4. After completing the mute mapping, the facilitator should walk the team through the groups of ideas that have been created. The facilitator begins listing off the entries in the group and then asking the team to name the group. The goal of this phase in the technique is to validate that each idea belongs in the group. The team is free to move notes to the groups if they fit better somewhere else.

Affinity diagramming with mute mapping is a tool to generate and sort a large number of ideas, comments or concepts into a more manageable order. Affinity diagramming is good for decision making, generating an initial product backlog, generating personas for user stories and retrospectives. Affinity diagramming with mute mapping might not be as versatile as duct tape, BUT it is close!

Making decisions on travel based on view that the world is flat and that you fall off if you get too close to the edge will generate far different decision than if the team knows that the earth is a sphere.

Making decisions on travel based on view that the world is flat and that you fall off if you get too close to the edge will generate far different decision than if the team knows that the earth is a sphere.

Over the past few hours I have had conversation or two about Teams: Making Decisions that reminded me that that effective decisions are the reflection of more than just an outcome of a process. Effective decisions are also a reflections of the information that is input into the process, the filters that information is passed through to make a choice and how well the decision is communicated.

Good decisions can’t be made without relevant and accurate knowledge and information (except by luck). Very early in my professional career I worked for a woman’s clothing manufacturer.  During the time I was with the firm the market changed fundamentally. The primary place women shopped shifted from department stores to specialty stores in malls.  The information we had to make market decisions did not reflect the change, therefore we made erroneous decisions that caused a significant market share loss. The input into the decision process was not accurate or relevant, therefore, regardless of the decision processes an effective decision could not be made.

All decision processes pass the information that has been collected and will be used as basis for a decision through a set of filters.  In informal decision-making processes, those filters are in the decision makers mind. In more formal, standardized approaches those filters are embodied in published decision criteria. All filters or decisions criteria reflect the cognitive biases of the decision makers. Cognitive biases refers to a pattern of behavior that reflects a deviation in judgment that occurs under particular situations. The filters that are used to make decisions, whether formally or informally, need to be reviewed and periodically challenged to ensure they have not become myopic. As the level of criticality of the decision increases, the more the decision-making criteria need to be collaboratively reviewed by the team and others outside the team.

Once a decision has been made, the decision and the process used to make the decision need to be communicated to those impacted by the decision. I am aware that outcome of decision needs to be controlled for some period of time.  For example a decision to buy a software product during a project may not be made public while the price and support services are still in progress. This example and others like it are the exception, not the rule. Teams should and must share the majority of decisions and the rationale behind those decisions as there effects can ripple through a project. For example, I recently saw the impact of an imperfectly communicated decision on a project. In this case the product owner and chief architect decided that the project they were involved with was to leverage external SAAS (Software as a Service) provider rather than building an internal application.  The offshore development team heard about the decision in an end of sprint demo. Consider the cost in dollars and motivation when the output of seven developers working for two weeks was thrown out as not relevant.  Communicate decisions to everyone impacted or risk wasting time and money.

Making decisions does require a standard well understood process, but that is not enough. The inputs into the decision-making process needs to accurate and relevant. That data then needs to be passed through equally relevant filters. Making decisions on travel based on view that the world is flat and that you fall off if you get too close to the edge will generate far different decision than if the team knows that the earth is a sphere. Effective decisions require process, people, information and communication.