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 regardless of intent 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. An experiment or a bit of prototyping might be needed 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. 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 experiments will not 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 (testing hypotheses) to generate knowledge and decisions so that teams and projects deliver more value.

What you see is dependent on what you expect.

What you see is dependent on what you expect.

Cognitive bias refers to a pattern of behavior that reflect a deviation in judgment that occurs under particular situations. Biases develop as filters and / or shortcuts that help us perceive information quickly in a manner that turns out to be beneficial to a decision process. Biases that help us recognize patterns help early humans stay alive by recognizing situations where predators tended to exist. The short cut in the decision process that the bias provided kept our ancestors alive even if there were false positives (you could have lots of false positives but only one 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 bias 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) that 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, the tendency to want things to stay relatively the same, creates a perception filter that helps the individual or team identify data and concepts which makes them comfortable.

An availability cascade causes a concept to become more and more plausible the more it is repeated publicly.  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 increase process fluency which makes the repeated item perceived to 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 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 short cuts that can help us perceive what is important and make timely decisions.

Many of us have a cognitive bias toward eating scorpions!

Many of us have a cognitive bias toward eating scorpions!

Cognitive bias refers to a pattern of behavior that reflects a deviation in judgment that occurs under particular situations. The phrase cognitive bias was introduced by Amos Tversky and Daniel Kahneman in 1972. Biases can affect how information is perceived, how teams and individuals behave and even, potentially, the perception of ourselves. Biases are a part of nearly every human interaction therefore the different biases must be understood if we are going to help teams grow and evolve.

Project teams make decisions on continuous basis. Most decisions are made based on how the decision maker perceives the information he or she has at hand. One bias that can affect how information is perceived is the illusory correlation. The illusory correlation is the perception of a relationship between two or more variables when no relationship exists. An example would be the perception that a team that works more hours a week has higher productivity because working longer gives the perception of creating more output. The perception of a relationship causes the other factors to be paid less attention (such as the higher level of effort they are expending). There are numerous biases that affect how information is perceived. Biases that affect how data is perceived can impact the outcome of decisions or even whether we make needed decisions at all.   

Biases can affect behavior. Neglect of probability is a type of cognitive bias common in IT organizations planning and estimating projects or in risk management. For example, most estimates should be represented as a range based on probability. Techniques like Monte Carlo analysis can be used to generate a range of probability based estimates. However, almost all estimates are represented as a single number and regardless of all the caveats attached the continuum of probability is ignored. Lottery ticket sales are another reflection of the neglect of probability bias; buying one or 10 doesn’t materially affect the probability of winning but it does not stop those who think buying ten tickets increases their chances of winning. In both cases neglecting probability affects how we behave and make decisions.  

Biases can effect motivation attitudes of ourselves. For example, a self-serving attributional bias, occurs when success is attributed to internal factions and failures to external factors. The type of bias can occur at an individual level or at the team level. While self-serving bias can improve self-esteem (or a team self-esteem) it can also cloud judgment by causing an overestimation of capability. For example, if a team is able to deliver more than their long-term productivity or velocity would predict, the team might then perceive that they have increased their capability to deliver. If no fundamental changes have occurred such as an infusion of knowledge, training or new tools, the higher velocity may not be attributable to the team. A good coach will help teams examine these types of biases during retrospectives.

Bias are powerful psychological filters that affect how both individuals and teams perceive the world around themselves and then how they behave. Biases reflect shortcuts in how we interpret and react to stimulus. In many cases these reactions are valuable however they can also cause problems (as many shortcuts occasionally can). Understanding how biases impact how individuals and teams perceive the world around them can help team make better decisions and therefore deliver value more effectively. 

Where do our cultures overlap?

Where do our cultures overlap?

I discussed the impact of organizational culture on decision making. Organizational culture has been shown to trump team culture. Many organizations make sourcing decisions that create teams with members from multiple organizations. Each organization will have its own organizational culture and goals. The more in common each of organization’s culture has with each other, the more apt groups of people are to form teams and make decisions effectively. Components of culture, such as the dichotomy between individualistic cultures and collective cultures, and the differences in business goals are important drivers that need to be understood.

Organizations with teams that historically had been staffed with team members that are individualistic by nature are often shocked when teams suddenly become blended with members that have a more collective nature.  This can be exacerbated if the new team members are offshore. The decision making styles will be different. Organizations centered in the USA, Britain, and Canada are typically staffed with employees that are individualistic, while many outsourcing organizations are perceived to be staffed with personnel that have a more collective outlook. A best practice suggested by Raja Bavani (SPaMCAST 190 – Raja Bavani, Distributed Agile) is to bring team members together for at least one sprint in person. The act of working together towards a common goal builds trust and helps the team members learn each other’s decision making styles.

Each organization pursues growth and being as profitable as possible. The devil is in the details thought. These goals are pursued in different ways and can create conflict that is translated down to a team level.  For example, several years ago I heard a salesman from a contracting firm say they weren’t worried as much about quality of what they delivered as making the project delivery date, because they would be paid after delivery to fix the defects and maintain the application. A best practice I have observed for long-term sourcing partners is to formulate an arrangement in which both share in the return on investment delivered by work the organizations do together. By creating more of a partnership the goals of both organizations will be more closely synchronized, making easier for team members to trust each other’s motives and for increased transparency in the decision making process.

When teams are comprised of members from multiple organizations, the cultures and goals of both organizations need to be identified and the ramifications of the differences need to be understood.  The more the cultures and goals can be synchronized the greater the likelihood that there will be a  true partnership. Partnerships develop the deeper level of trust and transparency that is needed for effective and efficient team decision making.

Distance and language make communication difficult.

Distance and language make communication difficult.

Distributed teams are a fact of life in many, if not most, IT organizations. Distributed teams are always less efficient than a co-located teams all things being equal. It is the last phrase, “all things being equal” that causes organizations to leverage distributed teams. Distributed teams have more challenges in making team decisions than co-located team due to potential culture differences and physical separation.

Culture is an often used term that describes typical behaviors and the mean ascribed to those behaviors. All groups have a culture. Within a group, culture allows members to interpret behavior and communication therefore building a bond of trust. When team members perceive differences in the behavior they anticipate a disruption in the bonds of trust occur. Since trust is a prerequisite to effective decision making disruptions to trust are serious issues to the health of a team. In corporate scenarios three types of cultures are generally considered to be important. Team, organization and national cultures are most often mentioned. Research has shown that organizational culture generally trumps all other types of cultures.

One mechanism to avoiding culture clashes is to ensure that the goals of a project are strongly tired to the goals of the organization. A second is to make sure that the techniques the team is being asked to use do not cause behaviors that are seen to be at odds with the corporate culture. Ensuring that no one is surprised by how the team will act or that it will be making decisions (or requiring them) will help establish a base of trust. When team and organization cultures are sympathetic they reinforce each other supporting a trust relationship and a more efficient decision making processes.

Physical separation influences decision making in a number of different ways. The first is through the potential for affecting communication frequency. Distance reduces the frequency of interaction (time zones only exacerbate problems).  Herbsleb and Grinter] found that communication frequency contributes to the inefficiency of distributed teams thus decisions must often be made quickly with the limited information available[1]. Inefficient decisions can lead to defects and rework which reduces the value a team can deliver or force them to embrace unsustainable practices. Red Bull anyone?

Solutions for physical separation are many. First, don’t do it. If you your organization is distributed try to organize teams in each location and leverage a scrum of scrums to coordinate. A second technique is to leverage video conferencing as continuously as possible to emulate physical presence. Tools like instant messengers and other forms of chat are also very useful but are best when used in combination with video. A third technique where significant time zone differences (more than 5 hours) exist is to ensure some shared day and the shared day should inconvenience everyone (everyone should share the time zone pain).

Research[2] has shown that distributed team, especially when team members are predominately from collective cultures, tend rely on a leader act as the focal point for decisions. This can be problematic for Agile teams where self-organization has not become an ingrained behavior. Reliance on a leader to champion a decision process becomes a problem to an Agile team when they start to generate a hierarchy which tends to reduce team cohesiveness. One solution is for the Scrum Master or coach to facilitate making sure that all team members get involved with decision making and that the right person drives the process. When one person starts to be the only decision maker, the coach, during the retrospective, should help the team discuss how the team can broaden its capabilities so that it avoids developing a single point of failure.

Distributed teams have all of the same issues that co-located teams have when wrestling with decisions plus potential culture issues and issues caused by physical separation. In a perfect world we would not have a distributed team but rather have distributed teams. The added problems that a distributed team has making decisions are not insurmountable. They do require that we recognize the risks, ensure as continuous communication as humanly possible and have active coaching available to help the team learn and institutionalize the concept of self-organization.


[1] Herbsleb J, Grinter R. Architectures, coordination and distance: Conway’s law and beyond. IEEESoftware 16(5): 1999, 963–70.[2] Investigating Decision Making Processes in Distributed Development Teams: Findings of a Comparative Empirical Study, Ban Al-ani , David Redmiles

 

Follow

Get every new post delivered to your Inbox.

Join 3,774 other followers