Critical to creating a coherent team is building trust among team members. This is much more difficult on a distributed team. Unable to rely on repeated, frequent face-to-face communication, distributed teams need to take other measures to build trust. Traveling ambassadors, starting meetings with casual conversations, occasional in-person meetings of the full team, working agreements, and similar activities all help. What also helps is early pressure for the team to produce working software by the end of each sprint, even the earliest ones. Unfortunately, many projects schedule too much time for teambuilding exercises and discussions too early in the project. This is a common and dangerous agile project management mistake, as shown by research from Professor Lynda Gratton and her coauthors, as published in the MIT Sloan Management Review.
Guiding these diverse teams to success requires some counterintuitive management practices. In particular, team leaders should focus on tasks at the early stages, rather than on interpersonal relationships, and then switch to relationship building when the time is right. (Gratton, Voigt, and Erickson. “Bridging faultlines in diverse teams.” MIT Sloan Management Review, Summer 2007, 22–29.)
Though this research suggests that the early focus should be on tasks, I do not mean to suggest that product owners or ScrumMasters should be assigning tasks to developers. Rather, I mean that these leaders should emphasize the need for the team to make demonstrable progress even in the early sprints. The problem with an early emphasis on relationship building is that it encourages less-than-ideal subgroups to form. Any large group will inevitably split into subgroups. If these subgroups are allowed to form too early they will form around surface-level attributes—Americans, Swedes, C++ programmers, Java programmers, female database engineers, male programmers, and so on. As Gratton and her coauthors write, “Simply put, in a team’s early going, the more people interact with one another, the more likely they are to make snap judgments and to emphasize their differences” (26).
What we’d like to do is defer relationship building until team members have learned more significant things about each other, such as specific skills, competencies, approaches to work, and so on. This is done through early emphasis on progress rather than relationship building. The subgroups that form at that time will be based on the mutual need to work together to develop the product. To develop a particular user story from the product backlog, you and I need to work together. In doing so we learn each other’s skills and specific competencies. I come to know you not just as a Java programmer but as a Java programmer with a real passion and strength for automated unit testing. You find that I am not just a DBA, but one who is strong at optimizing SQL statements.
Teams with subgroups formed around compatible skills, attitudes, approaches to work, and so on are less likely to lead to a later breakdown in trust than subgroups formed on superficial attributes (such as American, Swede, programmer, tester, and so on). Think back to one or more troubled teams you were a member of. Odds are that conflict on those teams was of an us-versus-them nature based on superficial attributes: this office versus that office, programmer versus DBA, Linux fanatics versus Windows fanatics. When teams feel an immediate need to make progress, those types of subgroups do not have time to form.
After a team has worked together for a few sprints, shift the emphasis toward relationship building by incorporating more social activities and shared downtime into the sprints. A team needs to have a sufficient amount of shared experience before social activities and relationship building can be useful. But when that has been achieved, “instilling confidence in the team and creating opportunities to socialize at that point helps the development of new abilities and allows the team to grow” (29).
I want to be clear that I am not saying that no time for socialization should be included at the start of a project. Seeding visits and whole-team, in-person get-togethers at the start of a project for its initial release planning can be very useful. Three points are key here:
- First, the project should start with intensity and a focus on early demonstrations of progress.
- Second, the entire “budget” for socialization should not be spent in the first couple of sprints.
- Third, early social activities should tie into the work of the project, such as bringing a team together for release planning.
Mike, the first part of this posting leads me astray. I absolutely agree with the final three points. So, I’m going to pick at a few details to try to resolve, or at least identify, the source of this discrepancy.
“many projects schedule too much time for teambuilding exercises and discussions too early in the project”
I’ve not yet seen that. I’ve always seen too little.
“Any large group will inevitably split into subgroups.”
How large a group do you mean? I think that would certainly be larger than the 7+/-2 generally recommended for scrum teams.
If this is a problem, I think it would be rather easy to develop some exercises that encouraged an overlay of different subgroups out of the same large group. People can be members of multiple subgroups simultaneously.
At least, I think that would be possible given the sort of “superficial attributes” you mention. I’ve generally seen the subgroups form on the basis of geography. This is a much harder problem, in my experience, perhaps because of a general lack of budget for travel and face to face meetings.
Have you really seen people form geographically diverse subgroups based on superficial attributes? If so, I’d like to hear more details about that.