Is it a Group or a Team?

This question often occurs to me when I'm on training or coaching assignments. The provocation is usually a statement similar to the following: "We have a development team of 250 highly skilled engineers...." or "Our QA team just can't seem to keep up with development...." or "The business analysis team writes all of our requirements...." or "Our middleware team serves multiple simultaneous projects."

It is common usage to apply the term "team" to mean any collection of individuals who perform some related function, regardless of how those individuals actually work. To me, a team is a very specific type of human organizational unit, defined by how it works, rather than by what it works on. Simply put, teams are distinguished by teamwork. I have even, very occasionally, encountered fair approximations of cross-functional Scrum "teams" that fail to meet this most basic definition.

Teamwork describes a particular way of working toward a shared goal. I have distilled the essential characteristics of teamwork into the following (incomplete) list:

• sublimation of individual ego and need for recognition to the needs of the team
  
• sharing and balancing workload dynamically at daily or finer granularity
  
• individuals offering and requesting help in an environment of trust
• willingness to make personal sacrifices in support of the team
• recognition that the team's goal outweighs (but does not exclude) individual goals
  

I'm certain there are many more traits that one could apply to describe teamwork, but this works for me as a starting point for the discussion. The key distinction I see between a team and a group is the collaborative effort a team engages in to meet its collective goal, for example, a Sprint commitment. A group, on the other hand, may indeed consist of skilled, well-intentioned individuals, but without a collaborative framework and a collective goal, teamwork is absent. The common example is the group of developers, each individually working on their assigned tasks, head down, blinders on, either unable or unwilling to share the load with their fellow group members. Sure, they're all working toward the same end point, but on parallel tracks that by their very nature cannot converge. Group work results in the standard array of dysfunctions and failures that characterize traditional software projects.

Implied in my list of teamwork traits is a self-organizing, empowered team that has the authority to set its own commitments and determine how best to meet those commitments. Another implication is that a team is small. The standard Scrum guideline for team size (seven plus/minus two) has always worked brilliantly in my coaching experience.

So the next time you hear a client or colleague talking about a "team," make sure you know what they really mean: Is it a Team or a Group?

All for now....

...-.-