Chapter 5. Collaboration

Now that the team members were all communicating effectively, it was time to start garnering the strength of the team as a whole. Each individual on the team was extremely bright, but Lydia knew that if the team understood and applied the “Wisdom of Crowds,” it would make the team even more effective.

Moreover, Lydia witnessed some of the natural conflicts that often arise between traditional roles on software project teams. For example, there seemed to be a constant tension between Lisa (who was a tester) and Eric (a developer). This is what Lydia referred to as the yin-yang on software projects. This is one of the reasons why agile teams contain fewer separations of roles and all team members are expected to do whatever is necessary (within their capabilities) for the team to succeed.

Working as a Team

Recall back in school when the teacher announced the requirements for a project, including that the assignment is to be completed in teams of four. Although an occasional student may cherish the opportunity to share the workload, many may likely dread the hassles of working as a group.

Attitudes about collaboration tend to align closely with DISC tendencies. A high D (dominator) doesn’t mind collaborating, as long as everyone else agrees with what he says. A high I (influencer) enjoys the social aspects of collaboration—a captive audience. A high S (supporter) is okay with collaboration as long as everyone is getting along okay, and a high C (critical thinker) tends to see collaboration as interference with getting work done.

Teamwork tends to be work in and of itself. Coordinating times to meet, determining who is best qualified to complete each of the tasks, and ensuring that everyone is contributing their fair share of the workload—these are all givens when working as a team. The most annoying component of teamwork, though, is that others may disagree with you.

Debates, arguments, selling ideas, these are the stuff of teamwork. They can be arduous, time-consuming, and the source of tremendous frustration. Given all these “costs” of teamwork, is it worth it?

Vox Populi

In an article published in the prestigious scientific journal Nature in March 1907, statistician Francis Galton reported the results of a study he performed on data collected at a stock and poultry exhibition in Plymouth, England. Galton titled the article, “Vox Populi,” a Latin expression that means “the voice of the people,” or the opinion of the general public.

As the 800 ticket holders entered the exhibition, they were offered the opportunity to guess the weight of an ox after it had been slaughtered and dressed. A prize was offered to the person with the closest estimate, so ticket holders put some diligence in their guessing. All ticket holders wrote their estimates on the backs of their entry tickets, along with their names and addresses so that they could be contacted if they won.

The stock and poultry exhibition attracted a variety of visitors. Some were butchers or farmers, who may have had expertise in estimating the weight of cattle, whereas others might not have known the difference between an ox and a cow. A scientific approach to ascertaining the weight of the ox based on the estimates might have placed more weight (no pun intended) on the expert’s estimates. However, Galton had a hypothesis that in a heterogeneous group of people, the best estimate would be found smack dab in the middle.

In a previous article titled “One Vote, One Value,” Galton contended that in any group that must ascertain an ordinal value, each participant should be given one vote and that all votes carry equal weight. The optimal number can then be found in the middle. Galton contended that the middle is key—the median, not the mean, should be used. This prevents what he referred to as “cranks” from overly influencing the results.

As an illustration, when a jury awards a financial settlement, using the mean (or straight average) can lead to skewed results. In a civil case in which the jury determines how much to award the plaintiff, it’s possible for the settlement amount to be heavily biased by a single juror. For example, consider the following civil case in which a six-person jury is charged with determining the amount to be awarded:

Using a straight average, the award amount is $97,500. Using the median, the award amount is $95,000. Often, the mean and median are close.

However, if Juror 1 chose to influence the award amount upward by choosing a settlement amount of two million dollars, the average jumps to approximately $414,000. The median value, however, would rise slightly to $100,000. Therefore, use of median offers a less-biased representation of the desires of the group.

So back to the livestock exhibition: The exhibitioners loaned the box of entry tickets to Galton, who analyzed the estimates of the weight of the ox. After discarding 13 illegible entries, Galton calculated the median as 1,207 pounds, which was within 0.8% of the actual weight of 1,198 pounds. In plotting the estimates, there was no symmetry—the estimates ranged widely. However, the middle proved to be extremely close to the correct value.

Jack Treynor wrote an article in the Financial Analysts Journal about a jellybean experiment he conducted with students in a Finance class he was teaching at the University of Southern California.

Professor Treynor put jellybeans in a jar and had 56 students guess how many there were. The average of the group was 871, which was closer to the actual number (850) than all but one of the students.

James Surowiecki discusses this concept in his popular book The Wisdom of Crowds, and he has conducted the jelly-bean counting experiment with his audiences during speaking engagements. The average of all the guesses in the room is usually within 3% to 5% of the actual number of jellybeans, and the average is usually closer to the actual number than more than 95% of the guesses.

Although Treynor and Surowiecki chose to use mean (average) instead of median, as Galton had done, the sample size was most likely large enough to dilute the impact of bias imposed by a few participants.

Sean, a colleague at Improving Enterprises, tried this out at a wedding he attended. As individuals signed the guestbook when they got to the reception, they were asked to jot down a guess for the number of jellybeans in a jar. Sean glanced down the list of guesses that had been written down so far, calculated a quick average, and submitted that as his guess. Sean’s guess was closest to the mark, and he won a prize—the jar of jellybeans!

Group Survival

Years ago, the U.S. and U.K. militaries developed team building exercises that helped participants understand the power of many. The power of many is a label used to describe how a group in and of itself has greater wisdom than that of any individual within that group. NASA later developed its own version for training astronauts, and it now offers this exercise for the general public’s use. Instructions and materials for the NASA Moon Survival exercise can be found in Chapter 12, “Moon Survival.” Everything needed to conduct this exercise with a group is included. It’s suggested that the facilitator read through all the material to become familiar with it, and that the participants not read about it so that they can participate more fully in the exercise.

Moon Survival and other similar exercises provide participants with experiential understanding of the benefits of group interaction. This is particularly useful with high C team members, who often get frustrated by the effort required and time spent when participating in group interactions.

Problem-Solving Versus Decision Making

In a typical project setting, many decisions are made. Individuals make some decisions, whereas other decisions are made by groups of people. There are not necessarily any official definitions for the terms decision making and problem solving, so any interpretation is valid. For the purposes of this book, the following distinction will be used:

• Problem solving: A series of tasks focused on determining, testing, and implementing solutions to a given problem.

• Decision making: The process of making a choice for each step of a problem-solving process.

Hence, problem solving can involve a lot of decision making, and the purpose of most decisions is usually to support a larger problem-solving effort.

The value in distinguishing between problem solving and decision making is to better understand the motivations and dynamics of each.

Individuals and Decisions

The DISC tendencies of an individual can influence how decisions are made and how problems are solved. Bearing in mind that problem solving is heavily dependent on decision making, the efficiency and quality of decision making can influence the productivity of an individual.

A team member who is a high D will usually make decisions with little hesitation and often with little interaction. A team member who is a high I is comfortable making decisions quickly and without proof of all the facts. He will tend to trust team member’s opinions and will take an optimistic point of view. A team member who is a high S is likely to make slower decisions and will want to hear all the inputs of the team. A team member who is a high C will usually not feel comfortable making a decision unless she knows all the facts and has time to analyze and contemplate them.

Groups and Decisions

In addition to individual behavioral tendencies, it’s also important to recognize that the DISC makeup of a group of people can greatly influence the approach the group will use to make decisions. It can also affect the quality of decisions; therefore, it’s helpful to recognize how a team’s DISC mix is affecting its decision-making behavior.

A DISC-homogeneous group is one that is made up of individuals with predominant membership from one of the four DISC profiles. Recall that most everyone has some D, I, S, and C but that usually one or two of these are the dominant in an individual’s behavioral tendencies.

DISC-homogeneous groups are not unusual, especially on teams made up of people with similar backgrounds, skills, and roles. A team of computer programmers could have a predominance of high C members, whereas a team of marketing people may be made up of mostly high I members. In a congressional committee meeting, it’s likely that most members of the committee are high D’s.

Group Influence

A typical individual within a given group often conforms to the will of the group. In the jellybean exercise described earlier in this chapter, the guesses were blind; each guesser does not have access to the rest of the group’s guesses (with the exception of Sean at the wedding reception.)

Because free will is always at play, not all groups will necessarily demonstrate conformance behavior. It’s useful to have awareness of the behavioral tendencies of a team you are working on. It is often worth investing some time assessing whether a team demonstrates more conformant behavior or more discordant behavior. Conformant versus discordant isn’t an either/or condition. Teams tend to have varying degrees of conformity. The graph in Figure 5.1 is a conceptual depiction of this scale. In decision-making situations, teams that center on one or just a couple closely related decision points is considered highly conformant. On the other end of the scale are teams with widely varying opinions. These teams are considered highly discordant.

Figure 5.1 Assessing the group influence of a team

On highly discordant teams, making a decision isn’t likely as simple as finding the median point among the opinions of all team members. This isn’t usually practical, and for subjective decisions that have no concretely measurable value, this isn’t even possible. Awareness of the team’s adaptability to the wisdom of the overall group can help leaders be more productive when facilitating group decisions.

As a ScrumMaster assigned to a new team, John wanted to determine how conformant or discordant the team was going to be. John got the team together and asked them to each guess how much he weighed, writing down their guesses on a piece of paper.

John gathered up the guesses without making any note of who made which guess and plotted them on a chart. John noticed that the estimates ranged from 155 pounds to 220 pounds, with various guesses at points in between those numbers.

Next, John showed the chart to everyone on the team and asked each person to review the chart and make another private guess at his weight. Again, John gathered up the guesses, plotted them, and showed the plotted data to everyone. After one more round of guesses, John made a final plot (see Figure 5.2).

Figure 5.2 Assessing the group influence of a team: Group A

After three rounds, John learned a few things about the team. Notice how the data clusters closer together during the second round and even closer during the third round. This is an indicator to John that the team exhibits conformant behavior. This helps raise John’s awareness of how the team is likely to behave in collaborative situations.

It would be naïve for John to assume that this is a demonstration of desirable behavior. It is possible that the “center” is not the optimal place to be in all decision making. The jelly-bean counting and ox weight examples may cause us to assume that the center is always accurate; however, many other factors can influence the group consensus.

The plot depicting the behavior of Group B (see Figure 5.3) demonstrates a different outcome. Most members of the group are stubbornly sticking with their original guesses. It’s possible that some members of the group won’t allow themselves to be influenced and drawn away from their own opinions. If John were leading a group like this, he should plan on spending much more time monitoring decision making. It’s probable with a group like this that there can be a lot of arguments and debates about even the most trivial decisions. Because the members of this group demonstrated that they are unyielding on something as unimportant as guessing weight, they are likely to drag out conversations about more important project-related topics.

Figure 5.3 A different outcome: Group B

Six Degrees of the Perfect Ice Cream Sundae

Late one Saturday night while watching a movie with Mary, John developed a craving for an ice cream sundae. After John clicked pause and announced his craving, Mary offered to build sundaes for both of them. Mary asked John what he wanted on his sundae. John was very particular about his ice cream sundaes, and he took pause before acknowledging Mary’s offer. Mary had never made a sundae for John before, and even if he provided a list of the ingredients he wanted, there was no way that Mary would know John’s preferences for quantities and layering of those ingredients.

Although John didn’t want to scoff at Mary’s kind offer to make a sundae for him, he realized that it would be so much easier to go to the kitchen and make it himself. Imagine the same scenario with one added degree of communication: John provided his requirements to Mary, who then went to the ice cream shop. At the ice cream shop, Mary gave John’s requirements to the teenager behind the counter. Imagine if the clerk behind the counter wrote down the ice cream sundae instructions and handed it to yet another person to create the sundae. Each additional participant in the sundae-making process introduces additional opportunities for John’s requirements to be misapplied.

Software projects are usually far too complex to be accomplished by one individual. To add to this complexity, it’s one thing for John to create the perfect ice cream sundae for himself, and it is yet another thing altogether to create the perfect ice cream sundae to satisfy the requirements of a large group of people. Specialized skills and the quantity of work favor the need for multiple participants in the process. As the number of participants increases, there is an increased likelihood of differences of opinion on the team.

What should John have done? The only way John can truly get the sundae he wanted was to participate directly in the process of sundae building. Anything else introduces risk that he will not get what he wants. The same holds true on agile project teams. This illustrates why stakeholder involvement is key to the success of projects.

Diametrically Opposing Forces

In Taoist philosophy, the concept of yin and yang describes two diametrically opposing forces. Each of the forces exists independently while at the same time are in opposition to one another. For example, light and dark are opposites. The concept of light would make no sense if it weren’t for dark. Thus, dark defines light, and light defines dark. Together, dark and light oppose one another and form a more profound thing that is both dark and light. The symbol for yin and yang is shown in Figure 5.4.

Figure 5.4 Yin and yang

Understanding yin yang and its surrounding philosophies can be complex. For the purposes of this book, suffice it to say that yin and yang are opposing, rooted together, transforming each other, and are balanced.

On typical project teams, traditionally there are certain roles played by individuals that have inherent opposition to other roles. Let’s call the person funding a project the “product owner,” and let’s call the person managing the project the “project manager.” The product owner seems to be continuously concerned with staying on budget and meeting deadlines, whereas the project manager seems to be concerned with excessive requirements changes and complaints about the productivity of the project team. This conflict can cause frustration and tension between these individuals. At the same time, the conflict cultivates interactions that positively contribute to the success of the project.

It’s natural for many individuals to avoid conflict as much as possible. However, certain project role pairings have built-in conflict that play an important part in the dynamics of a high-functioning project team, including the following:

• Business analysis versus business domain experts

• Development versus systems analysis

• Quality assurance versus development

• Project management versus business management

Figure 5.5 further summarizes these relationships.

Figure 5.5 Yin and yang of roles

In many organizations, the business analyst (BA) role was born out of a business role. Sometimes a BA role begins as a temporary assignment for a major project and evolves into a full-time position in the software development organization. Regardless of where the BA role is found in an organization, the BA is a proxy representative of the business. Over time, however, the authority of the BA can diminish, and the power to make business decisions can be taken away. When this happens, the BA becomes an arbiter of opinions between the project organization and the business domain experts (and the actual business decision makers).

Without the tension normally present when BAs collaborate with business domain experts, the best and most important requirements are unlikely to surface. When BAs and business experts interact, each individual has a different context: background, experiences, opinions, and dogmas. At the intersection of these items for multiple people, both agreement and conflict occur. Through the hassles of arguing, debating, agreeing, and disagreeing, the most important priority requirements are often revealed.

Similarly, developers may clash with domain experts when determining how to implement a solution to a business problem. Developers also tend to have a lot of conflict with those in quality assurance roles. When one of the authors was managing a QA group for a large company, the developers fumed when the daily “Bug Report” was published. After a bit of diplomacy, a compromise was reached, and from that point forward the daily report was renamed the “Findings Report.” Regardless of the name, the conflict between the QA and developer roles is engineered to increase the quality of the software being built.

Without all the conflict that occurs when these roles are brought together, quality and productivity would suffer. Some may see the existence of conflict as harming productivity because it takes time away from “production.” However, if conflict were avoided, quality is likely to suffer. Building the wrong thing or building the thing the wrong way is often the result of conflict avoidance.

Closing

Collaboration is costly and time-consuming. It requires much less energy to solve a problem individually than with a group. However, the quality of group performance has been demonstrated time and time again to far exceed individual performance.

When collaborating, it’s natural to want to avoid conflict. However, allowing conflict to happen and leveraging the wisdom of the group is likely to lead to higher quality results. The process may take longer, but the savings of delivering the right thing now far exceeds the cost of building the wrong thing with poor quality.