Chapter 3. Team Dynamics

It was Monday morning, and Lydia was excited to observe the team’s sprint planning meeting. When she entered the room, the team was already assembled around the task board actively discussing the project’s user stories. People were smiling and listening intently. At first glance, all seemed good with this picture. Then as Lydia joined the group and watched for a while, she witnessed something she had never seen before on an agile team. Sean was at the task board assigning tasks to all members of the team. From Lydia’s observations of Sean last Friday (see Chapter 2, “Behavior and Individuals”), she knew Sean’s behavior was a very high D; therefore he tended to be outspoken and drive things perhaps a little more than he should. However, this issue was much deeper than communication style. Lydia knew that as a ScrumMaster, Sean should be more of a facilitator than a dictator. He was not allowing the team to self-organize.

This chapter explains what self-organization means and why self-organization is critical to optimize a team’s performance.

An Apoplectic Dilemma

When Apollo 13 was headed toward the Moon on April 13, 1970, nobody had planned for how to handle the explosion of an oxygen tank on board. The project to build the spaceship had been meticulously planned and executed. Every step, every task was carefully and thoughtfully carried out. There were countless people involved in the project, and everyone performed the role they were hired to do. The NASA project culture was extremely structured and chock-full of predictability.

When flight controllers heard Commander Lovell say, “Houston, we’ve had a problem,” all prescriptive processes, defined roles, and project protocol were quickly forgotten. There was no time to prepare timelines and draw Gantt Charts. Solution proposals were not solely the responsibility of those with the proper engineering credentials. Experts rallied together to perform emergency innovation, which resulted in a creative solution that safely returned the crew to Earth by converting the Lunar Module into a space “lifeboat.” This extreme situation may not be indicative of a typical project setting; however, it is a clear illustration of a team self-organizing to accomplish a goal.

A Different Approach to Teams

In 1986, Takeuchi and Nonaka introduced an approach to product development teams that was analogous to the sport of rugby. The emphasis was on a team as a singular, holistic unit. Citing examples of successful product development projects at several companies, projects were initiated when senior management kicked off the process with a stretch goal—an extreme target that would raise the adrenaline of the team and bind them together with a singular focus on achieving the goal.

The stretch goal instilled a tension-filled atmosphere that could be a time bomb if mixed with traditional organizational structures, roles, processes, and expectations. Other changes were necessary.

Self-organizing project teams operate in an entrepreneurial manner. Prior expectations of individuals on the team performing prescribed roles are abandoned. The problem to be solved becomes the center of the team’s attention, and the urgency of solving that problem together causes the team to self-organize and find its optimal state.

For self-organizing to work, three conditions must be present:

• Empowerment: Top management specifies the goal, funds the effort, sets boundaries, and is responsive to the team when approached for support. Otherwise, the team is left to operate and make decisions within the boundaries of the project.

• Continuous improvement: Simply put, the team continuously raises the bar and works together to reach that bar. The team improves together as a holistic unit and shares in the satisfaction of becoming better. Through the process each team member’s strengths will be revealed, and they will reach out to one another to leverage one another’s strengths when needed.

The “bar” is not just related to individual skills. It also refers to busting through conventional business and societal expectations. Conventional wisdom can constrain the field of possible solutions to problems, and a self-transcendent team doesn’t allow those barriers to limit its capabilities.

• Multifunctional teams: Self-organizing teams require abandonment of the conventional “relay race” where one functional group completes a task and hands its deliverables to the next group that performs tasks related to its specialty. Instead, all specialties required of a project are combined into one cohesive team. Multifunctional teams are key to accelerating the progress of the project. For example, multifunctional teams could include experts in sales, marketing, design, engineering, and quality assurance.

In addition to specialized skills, cross-fertilization not only refers to behavioral diversity, but there is also added value in combining team members with different complementary behavioral profiles. See Chapter 2 for a description of behavioral profiles.

Capitalizing on Strengths

In his popular book Now, Discover Your Strengths, Marcus Buckingham discusses a Gallup poll that found that only a small percentage of people surveyed believe that their jobs enable them to work on tasks that leverage what they do best.

It may be possible to drive a screw into a piece of wood using a hammer, and it may be possible to use a screwdriver to drive a nail. Common sense indicates that it would make better sense to use the hammer to drive the nail and use the screwdriver with the screw. But what if you have a screw and a nail and only a hammer? It’s common to be handed a problem and not have access to an optimal set of resources. The logical solution in this case would be to get your hands on a screwdriver, even if you don’t have one in your toolbox.

On projects, though, individuals are often asked to perform tasks that they are not qualified to do. This can happen when project plans are meticulously laid out that marry tasks with available resources. A high-performing team would recognize strength-task mismatches and take corrective action. That could include shuffling assignments around, or it could mean reaching outside the team to leverage skills that don’t exist on the team.

At face value, this approach could potentially discourage employee development and growth. When there is a goal to develop and expand the skills of a team member, it’s important for that goal to be stated and completely transparent. When a high-performing team adopts a shared goal to help Fred improve his design skills, Fred’s progress can be accelerated through the encouragement and support of the team. Recognize that when employee growth becomes part of a project’s charter, it can consume resources and time that cannot be spent on other project goals.

So again, high-performing, self-transcendent teams are skillful at leveraging each individual’s seminal strengths. Additionally, these teams can recognize skill gaps and work rigorously to fill them.

The Anarchical Team

When considering self-organizing teams, it’s possible that management may fear anarchy. In the novel Lord of the Flies, when a group of boys are stranded on an island with no adults, they are forced to self-organize to survive. In this situation, self-organization is not reliable on its own. Although some of the boys were focused on doing what was necessary for survival and the rescue, others were focused solely on individual needs. Eventually, individuality led to irrational primal and savage behavior, which overpowered efforts by the few focused on survival.

When individual needs take precedence over the needs of the overall group, an environment similar to anarchy (lack of government) can occur—a.k.a., “Every man for himself.” In this situation, goals in the best interest of the group overall are not likely to be met. But who decides what is in the best interest of the group overall? Should those values and overarching naturally reveal themselves, or should some representative of authority prescribe them?

The Evolution of a Maturing Team

When a new team is formed, a natural maturing process occurs. Tuckman described the evolution of a team in four stages:

• Forming

• Members get to know each other.

• Participants agree on goals and begin completing tasks.

• Individuals seek to understand each others’ skills and behavioral tendencies.

• Emphasis of team members tends to be on individual needs.

• Strong direct leadership is typical at this stage.

• Storming

• Divergent ideas are raised, which can lead to conflict.

• Group goals from the Forming stage may be questioned.

• Individuals from some behavioral profiles suffer through this stage, [whereas] others enjoy the drama.

• Strong leadership is necessary to pass from this stage to the next.

• Norming

• Give and take occurs between team members.

• Individuals adapt their behavior and start to focus on accomplishing team goals rather than individual goals.

• In this stage, it’s important to ensure that team members don’t abandon important individual values and ideas just to avoid conflict.

• Leaders in this stage tend to operate more as facilitators than managers.

• Performing

• The team possesses all the skills and knowledge needed.

• Team members operate as a singular, holistic unit.

• All team members are motivated to accomplish the team’s goals.

• When conflict arises, the team knows how to work through it.

• Minimal supervision is needed.

Figure 3.1 provides a visual representation of the Tuckman model.

Figure 3.1 Tuckman’s Stages of Team Development

When forming a new team for an agile project, it’s natural to assume that armed with the right processes and tools, the team will jump to Norming or even Performing, but this is not usually the case. Strong leadership is needed to swiftly coach the team through the early stages of the team’s maturity. This is why there is great value in keeping teams together that have worked well together in the past.

Conflict

When teams work together to create or fix something, it’s rare that everyone will agree on everything. Interacting and coming to consensus on project decisions can be fun for some and a real pain for others. Often teams don’t always understand why some decisions are easier to make than others. Ralph Stacey described recommended strategies for group decision making based on agreement of the group and the level of uncertainty about the consequences of a decision (see Figure 3.2).

Figure 3.2 Stacey’s Zone of Complexity

In Stacey’s model, agreement refers to the degree to which members of the team concur about a proposed solution to a problem, design choice, importance of a task, or some other item that could potentially yield differing opinions. When the group is “close to agreement,” most if not all members of the team are on the same page. When the group is “far from agreement,” there could be multiple opinions, or there could be just a couple strong dissenting opinions.

Certainty refers to the access to information about past results based on similar decisions. If others made this same decision in the past, what were the results? What were the consequences? Although past results are no guarantee of future performance, they can be less risky than making decisions in a vacuum.

Based on the characteristics of each of Stacey’s five zones, a team can employ strategies to optimize the decision-making process.

In zone 1 (see Figure 3.3), there is sufficient access to reliable data from the past related to the decision being made. Decision making is deterministic because a cause-and-effect relationship between a decision and its results/consequences can be drawn.

Figure 3.3 Zone 1—high agreement, high certainty

For example, if a team tries to determine how to design a user interface for a user to retrieve a forgotten password, numerous examples of previous designs for this problem exist. Each previous implementation has determinable characteristics related to security, user friendliness, and compatibility with the target implementation environment. The target solution can easily be designed based on other implementations that satisfy decision-making criteria specified by the team.

The safest strategy for this type of decision is to repeat what has been shown to work in the past. Tasks associated with these decisions tend to include research, data gathering—generally harvesting content and solutions that have worked in the past.

In this zone, there is virtually no negative impact to team dynamics, so no best practices are needed to maintain the unity of the team.

In zone 2 (see Figure 3.4), there is also sufficient historical information to offer predictability of future results. However, there is still disagreement on the team. More often than not, disagreement has to do with different creative choices regarding aesthetics or usability.

Figure 3.4 Zone 2—low agreement, high certainty

The forgotten password example could fall into this zone if team members have different opinions about the look and feel of the user interface and/or the number of steps required to reset a password. Some solutions may be high in user friendliness but may expose security issues. In this example, team members may fall into different camps: Those championing user friendliness and those championing tight security.

In this zone, politics often come into play—idea selling, negotiation, and compromise. Critical thinkers on the team may develop matrices or decision trees to justify a choice. These could be met with resistance by those on the team who are not easily impressed with algorithms and models. It could also be met with resistance by other critical thinkers who would have chosen different decision-making criteria.

When decisions are made in this zone, shared team goals can be disrupted by these tactical choices. If a team had reached the performing stage, it could drift back a stage or two, although this is usually a temporary setback. When emotional moments caused by disagreement occur, it’s important for team members to avoid taking criticism personally. This will be easier for some than others based on their behavioral profiles.

In zone 3 (see Figure 3.5), a cause-effect relationship between decisions and their consequences is indeterminable based on prior work. In this zone there may not be a rational explanation for general agreement on the team.

Figure 3.5 Zone 3—high agreement, low certainty

Although things may seem hunky-dory when in this zone, there is a danger in not paying attention to risks associated with uncertainty. It’s not uncommon for a cohesive group in the performing stage to fall into the trap of groupthink. Groupthink happens when team members value a nonconfrontational work environment, and nobody on the team wants to do anything to stir things up.

In this zone, it’s important to ensure that the team’s consensus is not based on gut instinct or convenience. Instead, the team may need a reminder that decisions should be made based on the vision and goals of those funding the project. It may be useful to pay added attention to testing assumptions that are made and soliciting input from customers and others outside the team to reduce the risk of making poor decisions.

There’s an inherent fallacy that to be a high-performing team, there should be little conflict. Actually, there can be great value in dissenting opinions if managed properly. See Chapter 5, “Collaboration,” for more on how to capitalize on collaboration.

When there is a high level of uncertainty about the outcome of a decision and a high degree of disagreement on the team, the environment can be chaotic and even hostile.

When a team enters zone 4, the zone of chaos (see Figure 3.6), there is a tendency to avoid decision making, especially by those who are averse to conflict. The churn caused by avoiding decisions of high importance can cause project delays and ultimately negatively affect the success of the project.

Figure 3.6 Zone 4—zone of chaos: low agreement, low certainty

This zone tends to cultivate anarchy, so more rigid leadership may be needed to keep the team from regressing too far back into the “storming” stage. The team dynamics in this zone can be complex, and it’s not realistic for management to prescribe a straightforward solution because a manager’s guess about the appropriate course of action is as good (or as bad) as anyone else’s.

A rational exit strategy from this zone is to either reduce uncertainty or increase agreement. Of the two factors, uncertainty may be the easiest variable to change. On a software project, uncertainty can be reduced with tactics such as prototyping, researching, and focus-group testing. Armed with more information, the team can drift back to zone 2 or zone 3 and employ the strategies for those zones.

Not to be ignored, the area between the zone of chaos and the zones of rational, methodical decision making can be the most interesting (see Figure 3.7). When there are slight levels of agreement and the presence of some data to base decisions on, the team could drift toward zone 4 or back toward zones 1–3.

Figure 3.7 Zone 5—the zone of complexity

The environment in this zone tends to be entrepreneurial. This has the potential to cultivate creativity and the discovery of new ideas that could be innovative and profitable. This is the zone in which teams developing new products spend much of their time. This zone will be stimulating and enriching for some and exhausting and frustrating for others. The behavioral profile of team members can offer some predictability of how they will behave in the zone of complexity (see Chapter 2).

An example of a scenario that could occur in this zone is a team member who draws conclusions about the consequences of a decision based on collected data. Others on the team may question the validity of the data (and/or the assumptions that were made). When this happens, the scenario can play out differently based on the behavioral profile of the team members:

• A high D (dominator) may demand that others accept (or ignore) the data.

• A high I (influencer) may sell his/her opinion of the data.

• A high S (supporter) may feel uneasy with the disagreement that exists and try to encourage others to come to some level of agreement.

• A high C (critical thinker) may pour through Wikipedia, books, and documentation to find additional data to support the decision.

The primary goal of the team in this zone is to allow creativity and innovation to occur without drifting into the chaotic zone 4. Some may want to simplify the problem being solved so that a simpler decision-making processes in zones 1–3 could be employed. However, this could ignore complexity that can potentially lead to innovation and creativity and even in breakthrough results.

The identity and true mission of a project team will reveal itself in the zone of complexity, zone 5. If a team’s primary motivator is to all get along while getting a project done, the net result may be tactical success (project is completed on time and under budget), yet they may not have experienced breakthrough results. This may be sufficient for some projects and insufficient for others.

Now What?

All these studies, theories, and stories might be interesting, but how can this information help your team?

When the topic of self-organizing arises, some people fear impending chaos, disorder, dysfunction, or worse. Putting it in civics terms, some think of anarchy. With no formal designated leadership, a team will eventually align or disband. When alignment happens, the direction it takes is completely directed by its membership. When self-organizing teams are employed on an agile project, it’s imperative that the team includes representation of the goals of the business.

A key to getting value from the content of this book is to understand team dynamics and to learn how to adapt to the various situations a team finds itself in. It would be a fruitless endeavor to create a prescriptive decision-making model for teams. For example, not all decisions can be clearly articulated as a series of nonambiguous steps as could be depicted in a decision tree. Subjectivity is often present throughout projects, and subjectivity can trigger behavioral responses that must be dealt with.

Not all projects are created equal, and not all decisions made on a project are created equal. Team dynamics play a significant role in how a team handles unknowns and uncertainty, which are inevitable on most projects. Understanding those dynamics and why individuals behave the way they do in a situation can help a team focus and drive to resolution.

Human behavior is complex, and combining human beings to work together to solve problems and create things is exponentially more complex. There are numerous scientific studies and theories about individual behavior and team behavior that offer insight into the workings of a team. Access to the information in this chapter may offer some understanding of why teams behave the way they do and enable team members to behave with a more informed understanding of one another.

Closing

Armed with knowledge of the behavior of your team and why it behaves the way it does can be helpful to expose individual behaviors and team dynamics in a controlled setting. The Bridge exercise was designed to help a team capitalize on each other’s strengths and optimize team dynamics in a high-pressure project situation.

Instructions for facilitating the Bridge Building exercise are found in Chapter 11, “Bridge Building.”