April 6, 2008 by
Filed under: People, Teamwork 

What happens when something that has been hastily crafted to hold a team together is used in ways that were never intended? A team agreement can easily become a Weapon of Team Destruction.

We were working with a number of teams recently in the context of project management training, and one of their early assignments was to craft up a team agreement that could be used to ensure that the interactions between the group were positive and constructive. The team assignments were a significant portion of the work to be completed, and it was critical for overall success that the team be able to function in a cooperative manner.

As is often the case, the teams start the session unaware of what’s in store for them, and they can quickly feel that they have been ‘dropped into the deep end’. For one group, the overwhelming amount of work drove them to the decision to divide and conquer – a couple of people work on putting the team agreement together, while the others work on the project charter. On the surface, this was a good tactic, as both assignments were completed on time. The true ramifications of this, though, didn’t take long to manifest themselves.

I’ve noted before that it can be deceptively easy for a subset of the team to produce an artifact and assume that it is good enough to use as a basis for moving forward. In requirements training, I intentionally get everyone in the class to independently craft a vision statement in 5 minutes, and the consensus is that it is a relatively easy exercise. When we’re the only one involved in filling out a template, it’s easy. There is rarely any internal debate about what goes into which field, we have a strong tendency to simply use the first piece of information that fits. We come at it from our own self-consistent perspective, and the job is done quite efficiently. This happens when we develop a charter, or use cases, or any other artifact. We have produced the deliverable, but we have not nearly solved the problem.

That’s why we need to consider all of these artifacts as tools for collaboration. Their content is intended to focus and drive the discussion in a specific direction, and to pull out all those differences of opinion that need to be accommodated. The structure of the artifact should be seen as a template for extracting and exploring all the alternative interpretations the team can think of, and resolving these differences now, rather than only thinking of one approach later when one of is tasked with dealing with the issue on our own. This is true for most of the information we produce, but I think it is most essential when we are producing a team agreement. Indeed, if we are careful to work through all our differences in the context of crafting this agreement, then even if we do take a divide and conquer approach for later information on the project, our differences are less likely to destroy the team.

This was not the case with this group. The agreement covered many of the typical things we would deal with in a team agreement, but in a superficial way. As it turns out, one of the points that got them into trouble was the decision to fall back to a majority vote when there was a disagreement about any particular issue. The problem here was that the group (I’ve used ‘group’ rather than ‘team’ intentionally) was made up of individuals with a broad range of experience, and an even broader range of cultural backgrounds. The different experiences had led to different rates of learning, and one of the people in the group quickly grew impatient as others struggled to keep up. As a result, when frustrated with not being able to quickly explain a particular point, this person would call for a majority vote (as per the team agreement). The others in the group weren’t equipped to vote in a considered manner. A downward spiral, which quickly resulted in collapse of the group, backed by the argument that they were just following the team agreement.

The range of backgrounds and experience was a problem with this group only because they didn’t manage to gel as a team that appreciated and harnessed these distinctions to their advantage. Had they been able to understand each other and see their differences as a collective team strength, they may have made it past this point. Given the context of training over a constrained time period, all we could do was break up the group and adjust the makeup of the teams, despite the fact that we walked away from what I believe could have been one of the richest learning opportunities the group could have experienced. Had this been a real project with a real company, the cost of this breakdown would have made it worthwhile to work through these issues. In a real-life situation, a well crafted team agreement is a critical component for success, even more so as the pressure rises.

A poorly crafted agreement, on the other hand, can support disastrous results. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!


Feel free to leave a comment...

  • What’s Happening

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • Blissfully at home in Vancouver, BC over the summer!
  • What People are Saying

    Jim Brosseau’s understanding of the true dynamics of the IT workplace shows through in Software Teamwork. For those on the IT solution delivery front lines, and for those who manage them, his insights and wisdom will lead to not only better projects, but a better work life as well.

    — Bruce A. Stewart, Chief Executive Officer, Accendor Research, Inc.