Agile Development requires close collaboration. But most programmers and testers have been trained to value competition and individual effort through their schooling and professional experiences.

Is it any surprise that working collaboratively on an agile team may not come naturally? Along with learning new technical skills and development methods, successful agile teams learn – or strengthen – interpersonal skills. Teams that do not invest in these skills may see improvement but miss the potential for high-performance.

In my work, I see three areas that help boost a team to the next level of performance. They are the ability to do the following:

• Give congruent feedback.
• Navigate conflict.
• Think and decide together.

In this article, I outline each of these areas and talk about pitfalls for teams that lack these essential skills.

In more traditional organizations, the manager or project manager makes assignments and follows up to make sure the work is on track. People retreat to their own cubicles and may communicate via instant messaging or e-mail, even when the other person is only down the hall.

On agile teams, the team organizes its own work, making commitments to all on the team. Ideally, team members are in the same open workspace, and agile methods emphasize frequent interaction and face-to-face communication. This increases the probability that sooner or later, one person’s behavior will irritate someone or someone will fail to meet a commitment made to a peer.

When team members cannot talk to each other about missed commitments or behavior that affects the working relationship, resentment builds up. However, taking problems to a coach or manager creates an unhealthy triangulation – like the tattletale on the playground.

Further, there is a cost to withholding feedback. Not long ago, a developer approached me for advice about a problem team member. The developer reported that one team member was alienating other team members. No one wanted to work with him, and most of the team refused to pair program with him.

As the story unfolded, I learned that the offending team member, Joe, had an unpleasant habit: He picked his nose. The team coach had made vague references to good manners in a team meeting, but the problem persisted (not surprising, since general pronouncements are not a substitute for clear, direct feedback).

By the time I talked to the developer, the problem had been going on for three months. Joe was confused by the way people were treating him. The team was losing the benefit of his knowledge, and it was showing up in the quality of the code.

Joe’s habit was a problem. The bigger problem was that no one on the team knew how to talk to him about it.

The following is a simple feedback model to help team members have a feedback conversation:

• Create an opening to give feedback.
• Describe the behavior or result without using labels.
• State the impact (on you, the feedback giver, or on the team).
• If necessary, make a request.

This formula helps people stick to I language and avoid labels and blame. People are more likely to make a change when the feedback giver does not blame, shame, or evaluate the feedback receiver. Feedback is information, and the over-arching goal of feedback is to improve work and social relationships.

With some coaching, the developer approached Joe directly. He worked up his courage and told Joe about his habit and the effect it had on him. The developer was surprised to learn that Joe was completely unaware of his habit. Joe was embarrassed, but also grateful that someone had finally told him.

All teams have disappointments and friction. Contrary to a widespread fear, congruent feedback does not damage relationships; it increases trust and openness. Clear and early feedback keeps small irritations from growing into major resentments [1].

Conflict is normal and inevitable when more than one person is on a project. That is not necessarily bad; lack of conflict indicates apathy, not harmony [2]. The way people handle conflict determines whether a conflict is productive or destructive. People whose work is interdependent are more productive when they learn to recognize the causes of disagreements and navigate conflicts productively [3].

In my work with groups, I see four basic sources of interpersonal conflict: misunderstanding, focusing on positions, differing values, and bringing up past history.

Sometimes people disagree because they do not understand each other. Sometimes the misunderstanding is over the use of a term that has many meanings ( system testing is a common culprit; done is another). Or, people may not understand the details under discussion.

I attended a planning meeting where the participants argued in circles for 20 minutes about which of three approaches to follow for a release. I felt confused as I tried to follow the discussion.

“Wait a minute,” I said. “Can someone write down the different options you’re considering?”

By the time the team members finished writing down the options, it was clear there were actually four main options – and three variations.

The simplest strategy when people disagree is to review the data and write it down where everyone can see it.

Many of us grow up with the idea that one side wins and one side loses. That leads us to focusing on a position – pushing our favored solution [4] rather than talking about the problem and how we might solve it in a mutually agreeable way.

To bring focus back to the problem, ask what problem are we trying to solve? Then ask about the concerns behind both (or all) positions. When team members see the interests behind the position, they may find common ground or see a third option that incorporates interests from both sides.

A variation on this type of conflict comes from considering too few options. One group I worked with fought over decisions every week. In each case, they looked at only two options: either we do A or we do B. Having only two options is inherently polarizing. Generating additional options reduces unproductive conflict and increases analytical thinking.

When people are unable to reach agreement, even when both options would solve the problem and both parties seem interested in moving forward, they may be at odds over core beliefs about what is true and good.

Surface the values behind an option by asking about the strengths of the option. The words that people use to describe the strengths offer a clue about what the person values. Look for a third (or fourth or fifth) option that includes the top strengths from each option.

For most teams, the majority of the disagreements they face fall into the previous three categories: misunderstanding, focusing on position, or differing values. When team members learn to recognize the source of the disagreement, they can move quickly to resolve the disagreement – without being disagreeable.

When people are not able to give congruent feedback and navigate disagreements productively, simple disagreements escalate into ruptured relationships which show up as cheap shots and sniping. Trying to resolve the argument on the merits of the facts will not work because the argument is not about the facts. When the disagreement reaches this point, it is about the belief that the warring parties hold about each others motivations and intentions [5].

Ruptured relationships are poison on any team. On an agile team, where achieving the goal depends on every team member’s contribution, ruptures can be fatal. Unless at least one person is willing to improve the situation and look at how he or she has contributed, there is little hope of positive resolution. The good news is that when people learn how to give congruent feedback and know how to recognize sources of disagreement, working relationships are not likely to sink to that level.

Knowing the sources of conflict does not ensure people navigate conflict successfully. Most people have a default approach to conflict, which may or may not be effective depending on the situation. There are five basic approaches to conflict.

1. Competition assumes that one person will win and the other will lose. People press their own preferred solution rather than seek to understand the other person’s interests. People who approach conflicts as competition may argue their point and undermine the other’s point.
2. In collaborative problem solving, both parties seek to find options that will satisfy both of them.
3. When one person gives into another’s wishes without representing his or her own interests, it is called yielding.
4. Sometimes people do everything they can to avoid a conflict. They pretend the difference does not exist to save themselves from the unpleasantness of confrontation.
5. In compromise, people try to meet halfway. Each gives up some of what he wants and achieves some of what he wants. Compromise is common, though not always satisfying since no one is completely happy with the solution.

All of these are valid and useful ways to approach conflict in some situations. And each can be destructive when misapplied. Members of successful teams have the self-awareness to recognize their own preferred styles and know when to move out of their default approach to conflict.

Competition can damage relationships, especially when every disagreement or conflict becomes an I win/You lose proposition. Competition over small issues feels like browbeating or bullying. When one or more team members over-rely on this conflict approach, relationships and productivity suffer.

Collaborative problem-solving might not be helpful when there is a clear downside to meeting the other’s interest, for example, if the other person wants to pursue an illegal or unethical action. A collaborative approach also takes time in order to uncover interests, generate options, and reach a mutually satisfying outcome. It is worth the time when long-term relationships are at stake, but may not be when time is of the essence or the relationship is transitory.

Yielding is fine when one person does not have much investment in the outcome and the other person does. Yielding hurts when it is habitual – one person always gives in to the other. Others may perceive habitual yielders as doormats and walk all over them. Habitual yielding carries a cost. For example, a team that always says yes to the customer’s requests during iteration planning meetings avoids the short term stress of an unpleasant conversation. But in the long term, the team risks burnout if they struggle to deliver on unrealistic commitments. They risk their reputation as trustworthy professionals if they fail to deliver. Over time, habitual yielding results in resentment, depression, anger, and contempt [6].

Avoidance may be a reasonable course when there is nothing to gain by pursuing an argument; savvy team members learn how to pick their battles.

Compromise often ends in a half-horse, half-camel solution that is not fully satisfying to anyone, and can cause teams to miss novel solutions. But compromise is the best option when it is clear that a collaborative solution is not feasible.

Most people have a preferred style for approaching conflict. Teams suffer when people on the team approach every conflict with the same style, regardless of what is at stake and without consideration for maintaining important relationships.

On many traditional teams, the manager makes important decisions. But agile teams work best when they have the authority to make decisions that affect their own work (within the context of organizational standards). In order to make timely decisions that the team can support, teams need three broad skills:

1. Generating ideas.
2. Narrowing the number of options.
3. Reaching agreement [7].

When one or more of these elements is missing, teams struggle to make decisions. The good news is that most agile teams can learn techniques that will help them self-facilitate without investing in extensive facilitation training.

A combination of individual brainstorming and affinity clustering can help a team generate many ideas in a short period of time [8]. Pairing these two techniques allows the group to integrate ideas and find common threads.

When I see a team stuck evaluating alternatives, it is usually for one of the two following reasons: 1) People do not have a common definition of the options under discussion (a common source of disagreement described earlier), or 2) the group is talking about all the options at the same time.

Overcoming the second problem takes some discipline: Evaluate each option on its own before comparing options to each other.

Draw two lines on a piece of flip-chart paper, creating three columns, as shown in Table 1. List the pros and cons of the options in the first two columns. Make a note of what is interesting about the option in the third column. Answer all three questions for one alternative before moving on to the next. After the group has completed this activity for all the options, it is usually obvious that some of the ideas are unsuitable.

Table 1: Pros and Cons

Teams need a way to test their agreement and discuss concerns before they arrive at a final agreement. A simple hand sign can help a team gauge their level of agreement:

• Thumbs up = I support this proposal.
• Thumbs sideways = I’ll go along with the will of the group.
• Thumbs down = I do not support this proposal and wish to speak.

If all thumbs are down, eliminate the option. On a mixed vote, listen to what the thumbs-down people have to say, and re-check the agreement. Thumb-sideways helps show where support is lukewarm.

Finally, teams need to decide how they will decide and identify a fall-back decision rule (in case they are unable to reach agreement).

With skills in these areas – congruent feedback, navigating conflict, and thinking and deciding together – teams have a basis to work through the inevitable friction. Without collaboration skills, teams struggle to manage both the upside and downside of collaboration. In my work, I see a predictable progression for teams adopting agile methods.

In the first months, teams concentrate on structures: daily stand-up meetings, iteration planning meetings, and mechanisms to keep progress visible.

Next, they face the difficulties of organizing their working in short (one week to 30 days) iterations.

When those pieces are in place, teams typically recognize that their engineering practices are not adequate to the job and attack those.

Finally, teams realize that in order to work effectively with their customer and with each other, they need collaboration skills. As Jerry Weinberg famously said, “It’s always a people problem.”

However, pushing collaboration skills before a team recognizes the need is not helpful. Adults are motivated to learn when they see the value of new ideas for solving the problems they face. When agile teams recognize that collaboration skills will help them deliver valuable software, perhaps with some nudging from their coach, they are eager to learn.

1. Seashore, Charles N., Edith Whitfield Seashore, and Gerald M. Weinberg. What Did You Say? The Art of Giving and Receiving Feedback . Bingham House Books, 1992.
2. Eisenhardt, Kahwajy, and L.J. Bourgeois. “How Management Teams Can Have A Good Fight.” Harvard Business Review (July/Aug. 1997).
3. Katzenbach, Jon R., and Douglas K. Smith. The Wisdom of Teams: Creating the High-Performance Organization . Harper Collins, 1999.
4. Fisher, Roger, and William Ury. Getting to Yes: Negotiating Agreement Without Giving In . Penguin Books, 1983.
5. Stone, Douglas, Bruce Patton, and Sheila Heen. Difficult Conversations: How to Discuss What Matters Most . Penguin Books, 1999.
6. Satir, Virginia, John Banman, Jane Gerber, and Maria Gomori. The Satir Model: Family Therapy and Beyond . Science and Behavior Books, 1991.
7. Kaner, Sam. Facilitator’s Guide to Participatory Decision-Making . New Society Publishers, 1996.
8. Sanfield, Brian R. The Workshop Book: From Individual Creativity to Group Action . New Society Publishers, 2002.

Esther Derby is known for her work in helping teams grow to new levels of productivity and coaching technical people who are making the transition to management. She is one of the founders of the Amplifying Your Effectiveness Conference and is co-author of Behind Closed Doors: Secrets of Great Management. Her latest book is Agile Retrospectives: Making Good Teams Great. Derby has a master’s degree in organizational leadership and more than two decades experience in the wonderful world of software.

3620 11th AVE S
Minneapolis, MN 55407
Phone: (612) 724-8114
Fax: (612) 724-8115
E-mail: derby@estherderby.com