Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Can a team have 100 (or more) members?

DZone's Guide to

Can a team have 100 (or more) members?

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

I recently set aside my analog wrist watch and started wearing a runners watch. It’s accurate to the second on the face, and to a 100th of a second on the split timer.

I’ve noticed that when I have a precise measure, sometimes I use it, even when precision isn’t necessary.  For example, when someone in a workshop asks me how much time is left in a simulation or exercise, they don’t need to know that there are 2 minutes and 27.15 seconds remaining.  “Two minutes” would be an adequate response.

But there are times when a bit more precision is helpful– like in the way we name the social units that perform work in organizations.  Take the term “team,” for example.

I hear the term used for any group of people who share almost any common characteristic.

In some organizations functional groups are referred to as “teams” even though the people in those groups don’t work on a common project and their work isn’t interdependent or aimed at creating a whole product.

Teams have these characteristics:

Teams….

  • Share a compelling work goal, and that goal is well-understood by all members of the team. Some person(s)  in the organization eagerly await the product the team is producing–else there is no reason for the team. Without an external goals, a group may form a social unit, but they are not a team.
  • Members are mutually accountable for achieving the external goal. Team members do focus on completing their work; but they know that completing individual tasks–by themselves–isn’t enough for success.  Success comes from achieving the overall goal.
  • Are doing interdependent work that requires the skills of all to create a finished product.   Their skills are complementary and it is the combination of their skills that enables them to reach their goal.  It’s not like a ski team where everyone has the same skills, and the team result is the sum of individual scores.  On a team, the results aren’t additive, they’re integrative, generative, and collective.
  • Have a shared approach (though not a rigid process).  Team members make agreements on how they will work together.  They choose methods that fit the work and the goal.  They need enough constraints on their process so that they can work creatively–avoiding both anarchy and stifling routine.
  • Teams almost always have fewer than ten members. Some say five is the sweet spot.  When there are fewer than five members, there’s not much sense of teaminess.  When there are more than ten, the work is so big that it breaks on along natural lines…and so do the people, falling into sub-groups that act more like a team than the bigger unit.
  • Have shared history/identity.  This implies that a group is not a team on it’s first day together.  It also implies that shaking up groups every few weeks or months ensures that you’ll never really achieve the surpassing results that cohesive teams are capable of.

But what about a group of 100 people focused on a common goal of creating a whole product?

At a local user group, there was discussion about such “teams.”

That stretches the definition of “team” too far. Teams are small enough that they can coordinate planning and the flow of information necessary for day-to-day work themselves. They may use task boards, build lights, and other mechanisms to help disseminate information and reduce the load on interactions between individuals.  But they seldom need a person whose job is coordinating efforts of individuals. They’re small enough that they don’t break down into sub-groups.

One of the participants in the discussion asked how teams that large made decisions quickly.  The person advocating large teams (100+ people) described  how the overall manager pulled together people and information and then /he/ made the decision.  That’s a perfectly reasonable way to handle decision-making when there are 100 people working towards a whole product in a commercial enterprise.

But if there’s an overall coordinating structure, it’s not a team.  Teams are small enough that  they don’t need additional coordinating structures and people in coordinating roles who are not working members of the team.  (They still need managers who provide support and create an enabling conditions.)

Some times it does require the coordinated effort of hundreds of people to create a whole product.  Within that collection of people there may be units of social organization that are teams.  There may be work groups and individual contributors.  And there are people whose role is the efficient coordination of communication, activity, and decision-making across the various sub-units within the overall structure.

Each of these units–work groups, real teams, conglomerations of workgroups and teams–are different social organizations and have different needs.  Each requires different support structures, boundaries, and infrastructure.

Calling such disparate arrangements by the same term causes confusion, inappropriate expectations, and mismatched actions.

So let’s have a little more precision, please.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:

Published at DZone with permission of Esther Derby , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}