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.

Decisions, decisions...

Decisions, decisions…

Teams make lots of decisions, big and small. Effective teams have an agreed upon process for making decisions that is context specific. Effective decision making processes have several attributes. It requires:

  • Process
  • Team involvement
  • Commitment
  • Context

Process is sometimes perceived as a bad word. A simple decision process will include six steps:

  1. Define the problem. – This step ensures that the team knows the problem they are try to solve.
  2. Determine who is responsible for making the decision. – Depending on the type of problem a leader may have to make the decision or a more participative from of decision-making might be required.
  3. Involve the right people and a right sized group (Rule of 7) – Even in the most democratic teams every decision is not made by every team member. Each decision should be made by the minimum number of participants and AVOID large groups.
  4. Agree on how the decision will be made. – The team should decide how they will make the decision before they start to gather data and/or deliberate. Understanding how the decision will be made before you start can limit the possibility of analysis paralysis (analysis and decision making that goes on forever) or jumping to an overly abrupt decision.
  5. Generate ideas. – Making a decision requires at least two options. A good rule of thumb is that the more critical and complex the decision, the more formal the idea generation process needs to be.  Affinity Diagraming is one technique for idea generation.
  6. Make a decision. – The final step is the culmination of the process.  You have the criteria and the data . .  . just make the decision!

Team involvement is critical when buy-in is needed.  The degree of involvement is generally driven by the level of critically and complexity. Individuals make simple or mundane decisions on a nearly continuous basis. In general the more critical and complex the decision, the more involvement is required.

Getting to a decision in a repeatable way requires a commitment to the process. In many cases, the stress of making decisions can cause teams to abandon their normal process. This will lead to less repeatable decisions and possibly worse decisions. Once a decision is made, continuing to adjudicate the decisions or actively dissent will reduce team effectiveness. Commitment to both the decision and the decision-making process is important.

A one-sized decision-making process never fits all needs. It must scale based on the context, which includes criticality, complexity the level of buy-in needed and required decision-making speed. Fast decisions are almost never made by groups.  For example, if driving, would you want to have to consult with your team in order to hit the brake if the car in front of stops short.

Effective decisions are generally a reflection of a standard, repeatable, context driven decision-making process. Decision making processes that scale to meet the needs of the decision can be as  rigorous or light as required.  Without a process it is generally too easy to ignore team input, which will reduce the number of options and the team’s commitment to the final decision.

Safe to fail experiments are about education.

Safe to fail experiments are about learning

In IT, ‘safe to fail’ describes activities that are used to generate knowledge. Additional terms that might be used are probes, spikes, R&D and prototypes. The outcome of a safe to fail experiment can be innovation, the information necessary to make decisions or to discover alternatives.  All these scenarios are appropriate for a safe to fail experiment, however sometimes safe to fail experiment are not safe nor are they appropriate.

Safe to fail experiments are appropriate in situations where learning is required to deliver a project. You might need an experiment or a bit of prototyping to learn whether something is possible or if there is a more effective way to perform a repetitive task. For example, earlier in my career my team converted credit card portfolios from one provider to another. We used a standard process for most of the hard work. Yet, we were always looking for a way to make the process more efficient using mock conversions as experiments. The goal was to find better processes and techniques.  These experiments did not always yield process changes, but they always added to our knowledge of what would and wouldn’t work. Another opportunity for safe to fail experiments is in situations where several possible alternatives exist. You need an experiment to determine which (if any) of the alternatives make sense. A test or an experiment is considered successful if it proves either that an alternative is a good choice OR if the results can be used to cross an alternative off the list. Organizations that judge results that can disqualify an alternative as a failure are apt sort out alternatives in the market place rather than before they go into production because their experiments will not truly be safe. Finally, safe to fail experiments are useful tools in formal decision-making frameworks. For example, frameworks built to comply with the CMMI process area, Decision Analysis and Resolution (DAR), often leverage safe to fail experiments to generate data for formal, structured decision-making.

Safe to fail experiments are not always appropriate.  Many projects exist with a both fairly well understood solution and a hard deadline. In some portion of these projects the solution may not be perfectly optimal or the coolest possible solution, but it is doable in the timeframe. Experimenting to find a more optimal solution when taking the time and effort could cause you to miss the due date is not appropriate. In the credit card example mentioned earlier, we explored new ideas and optimization between projects to avoid experiments that would put the conversion at risk or cause the team to miss more of their weekend than was already necessary. Experiments that imperil the commitments a team has made or inhibits their ability to effectively deliver are not experiments and are safe to fail. Experimenting is also not appropriate where negative results are thought of as a black mark on a career. In this case straying from the tried and true approaches are generally a bad idea. This scenario tends to occur in highly politicized or overly competitive organizations. In this type of scenario if you can’t change the environment, I would suggest experimenting with other job opportunities. A third scenario is more questionable than absolutely inappropriate. In scenarios where there is little potential upside to the experiment experimentation is probably not a good idea. In most organizations, time and attention are always in short supply. Every team needs to judge what it needs to learn and ration resources that are in short supply when there is little or no perceived upside.

Safe to fail experiments are scenarios where an organization or team truly wants to sift through possible alternatives before using them in a project or in production. Safe to fail experimentation is an application of the scientific method to generate knowledge and decisions so that teams and projects deliver more value.