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


Every task requires the right tools.

Every task requires the right tools.

Team based decision making requires mechanisms for creating consensus among team members. In the Daily Process Thoughts of June 26th we described the prerequisites teams must satisfy to make a decision. The prerequisites are a decision to be made, trust, knowledge and the tools to make a decisions. In many instances team members are assumed to have the required tools and techniques in their arsenal. Unless team members have been trained in tools to generate consensus and decisions this is rarely the case. I suggest three decision making techniques each team should have; voting, Fist to Five and the Nominal Group Technique. Note each technique is more complex than the next and is representative of many other similar techniques.

Voting is a decision making technique that almost everyone understands. The simplicity of the process is a major positive of this technique. The downside to voting as a decision making mechanism is that someone (or some group of someones) will lose. The win / lose mechanism can create a divide within the team which will pull it apart over time or generate passive aggressive behavior.

Fist to Five is a tool that combines consensus building and voting. The technique has been attributed to numerous people or organizations ranging from Jim Highsmith to the American Youth Foundation. Fist to Five introduces an element of the quality of the common “yes”/”no” vote. Each participant responds to a proposed solutions with a fist or up to five fingers. A fist is designated as a “no” (and I will try to block the decision) or some number of fingers. The number of fingers is a “yes,” with an indication of how good a “yes” is, it usually ranging from one meaning the voters still has some issues to five meaning the voter will man the barricades to fight for the decision. Fist to Five provides a way to check the “sense of the group,” and the quality of the consensus on a scale.

Consensus decision making requires involvement and commitment. Many group oriented techniques have been developed to generate involvement such as brainstorming. The goal of brainstorming is to give team members an opportunity to engage. The nominal group technique (NGT), uses a more structured format to obtain multiple inputs from team on a particular problem or issue. This mechanism is often useful to help new teams as they build relationships and for distributed teams where formality can be used to combat distance.

NGT is a structured group discussion / voting method. The format prevents the domination by a single person or subject matter expert and passive group members to participate. The output of the process is a set of prioritized ideas, solutions or recommendations. The steps for a sprint team: 1) State an open-ended question (“How are we going to solve a business problem?”). 2) Each team member will spend 5 – 10 minutes in silence individually brainstorming all the possible ideas. Write each idea on sticky note (if in person) or write the ideas in an electronic note (distributed). 3) Share the ideas in a round robin manner with someone acting as a recorder adding each idea to a flip chart or shareable mind map. (Round Robin is one response per person rotating until all ideas are recorded.). Use the classic brainstorming rules of allowing no criticism and allowing requests for clarification. 4) Have each person evaluate the ideas and then individually anonymously vote for the best ones (I typically suggest voting for the top five, five being best and one being the lowest). The idea with the most votes wins. Variant: discuss the top vote getters and then revote.

There are a myriad of group decision making techniques. They vary in complexity and each try to address issues that a team might have when creating a decision. However, none of these techniques have ANY value if the team is not aware of the technique or cannot execute the technique. Teams can struggle creating a consensus, become passionately split on an idea or simply struggle understanding the options that are appropriate. Each team needs a pallet of decision making tools available (or a coach with those techniques) or risk failing to make good decisions or decisions in a timely manner.

Having a camera is a prerequisite to taking a picture.

Agile teams make decisions continuously, all shapes and sizes. These decisions are critical to keeping work continuously moving forward.  Having to search for someone to make a decision or to setup a meeting to make a decision can be difference between completing or not completing a piece of work during an iteration. What are the prerequisites for Agile teams to make decisions?  There are some obvious prerequisites, like the need to make a decision, but assuming that basic need is met I would suggest that addition the team needs trust, knowledge and the tools to make a decisions.


Team decision making is a collaborative process and requires trust (this even more important when the team is distributed) and a sense of shared responsibility. Trust among team members is generated from a set of interactions, either facilitated or organic, in which team members learn the capabilities and opinions of their teammates. These interactions generate a common team culture that as it deepens allows team members to develop a better understanding of each person’s (and by extension the team’s) capabilities and behaviors. Assuming actions and communications that lead to decisions are made in line with the profile we have developed for the team we can work together to make decisions.


Knowledge is one of those prerequisite that can be rectified relatively quickly. Diversity helps broaden the team’s knowledge however teams need to understand the knowledge capabilities as deeply as skills based capabilities. When there are deficiencies team members need to work to fill the gap. Without the knowledge to make a decisions the answer derived will be correct only by accident.


There are numerous methods and techniques to make decisions. We will explore a few in Daily Process Thoughts on June 27th.  Decision making frameworks provide team members with the knowledge of tools that can help the team approach decision making. Many of us have one or two mechanisms for making a team decision. The most common technique leverages PowerPoint, boredom and arguing. Techniques like De Bono’s 6 Thinking Hats, Highsmith’s Fist to Five and maybe even roshambo might be valuable tools to have in your decision making tool box.


A team without trust, knowledge and the tools to make decisions is going to struggle. The struggle to make decisions will translate into making poor decisions or worse, into asking someone else to make the decision. Bad decisions are not the worst problem because feedback from mistakes will help the team learn make BETTER decisions or to learn HOW to make decisions.


Our guide acted as a servant leader.

Our guide acted as a servant leader.

The servant leader works to empower and serve the people he or she leads. Empowerment on an Agile team is reflected by the removing of impediments and coaching the team so it performs to its capability using Agile practices. If you are leveraging Scrum, this is the role described as a Scrum Master. In xP this is the role of a coach, Skip Prichard observes that servant leadership is a blend and balance between leader and servant. You don’t lose leadership qualities when becoming a servant leader. Different writers describe the seven pillars of servant leadership, the nine qualities of the servant leader or the 12 key practices of a servant leader. All of these lists can consolidated into four attributes which are fosters learning, facilitates collaboration, generates trust and acts as the team’s advocate.

A servant leader fosters an atmosphere in which a team continuously learns. Teams learn new skills, gain deeper understanding of the business, of the technology, of the capability of the team and how to deliver greater value. The servant leader helps to create an environment that supports the respectful and safe expression of ideas. They lead by example, through coaching and teaching.

A servant leader facilitates collaboration not only by creating a learning environment but by helping the team to establish a vision and goals which the team can use as a guide. The servant leader provides the tools and techniques needed for the team to self-organize and to make decisions. Collaborating is the action of working with someone (or someones) to generate an outcome. The servant, when needed, coaches and mentors team members to work together to achieve the goals they have committed to meeting.

A servant leader builds trust through trusting. When leaders exhibit trust of team members, team members show significantly higher levels of trust[1].  Trust is an important ingredient for working in teams because it underpins effective co-operative[2] behaviors. Trust creates an environment that makes communication flow more easily and allows the team self-organize rather than to be organized.

In old western movies the settlers would circle the wagons when threatened. Agile teams can’t circle the wagons however someone must advocate for the team. The servant leader is the voice of the team. Helping to remove impediments and to help deflect other demands that could deflect the team from living up to their capability.

Teams are a core component of work today. Agile teams are more efficient when they are empowered. Servant leaders help the team learn and collaborate. Servant leaders deliver and foster trust which makes the team more effective. Without someone to be the team’s voice and advocate, teams will be buffeted by the capricious demands of the organization making it difficult to deliver consistent value.


[1] Sen Sendjaya, Andre Pekerti, (2010) “Servant leadership as antecedent of trust in organizations”, Leadership & Organization Development Journal, Vol. 31 Iss: 7, pp.643 – 663


Get every new post delivered to your Inbox.

Join 3,669 other followers