Project teams are not teams

May 12, 2009 by Mendelt Siebenga

I want you to do a little experiment. First search for the word 'team' on this site. By the time I wrote this article I got 325 results but that might be more now. Now click on the team tag right between 'TDD' and 'template' in the tag-list, only 26 articles are actually about teams.

What are teams?
Many books and articles are written about team-roles, team-size, team-self-organization or team-cross-functionality to name a few. One of the prerequisites is always stable teams, for many of the agile thought leaders the existence of teams is self evident, it's hardly ever talked about. Unfortunately many organizations do not really have teams. They assign people to projects instead.

Part of the confusion about teams vs. projects is caused by the mistaken assumption that a group of people assigned to a project will work as a team. Unfortunately this is not the case, project teams don't get the chance to behave like teams. Project teams are short-lived, they break up when the project is done or cancelled. They are volatile, people are pulled off the team when needed somewhere else. And often project-teams are unfocussed, older projects still need work so team members work on more than one project and are on more than one team. In this essay I want to look at a few reasons why real teams are preferrable over project-teams.

Real teams collaborate better
Large parts of agile methodologies are about aligning processes with people and their behaviour. Real agility requires gelled teams that take responsibility, self-organize to do work and communicate. These are qualities that take time to build. Shifting people between projects and breaking up teams is something that is detrimental to the ability for people to work together and organize.

Teams are measurable
Also there are practical considerations. In order to fine-tune your process it's a good idea to collect performance metrics. Teams are a natural measurement unit. In the absense of stable teams organizations often measure productivity of individuals. But because software development is a cooperative practice this is not really a useful metric. Performance of people will change depending on who they work with, where they work and on what project they work. This will be problematic when trying to make estimations based on velocity for example. Velocity does not change linearly with team size.

Organizations built on teams scale better
A less obvious drawback to using projects as the central planning unit is that organizations built around project-teams do not scale very well. When you look at estimates for optimal team size in real teams they vary from 5 to 8 people. Planning, coordination and communication overhead get too big in larger teams. Without teams to partition an organization this overhead is even bigger and the organization will have trouble scaling. This might sound a bit theoretical but I've seen a couple of organizations like this. They all have trouble making project teams of more than four or five people work and they all have trouble growing beyond 25 to 40 people. These numbers are based on my observations in three organizations so they should be taken with a grain of salt. I would be very interested to hear your observations to see if these numbers fit more organizations.

Teams perform better for several reasons. Teams allow people to collaborate while minimizing overhead, teams are stable units for measuring performance and teams partition organizations to enable scaling. But you need real teams for that. Breaking up teams between projects and having people work on several project teams may seem efficient but will damage the effectiveness of your organization.

Permalink