How to Know Whether Your Team is Only a Workgroup

All too often in organizations, a team is not actually a team, but a workgroup. Even if it’s cross-functional, folks attend meetings together, and they work off a single plan.

In a workgroup, performance is additive, and the potential exists for equating people with resources. A real team, on the other hand, often experiences a performance multiplier.

How would you know if your team is really being a team, as opposed to a group of individuals doing related work?

Try the following thought exercise. Note: it assumes the team uses Scrum, but if that’s not the case, translate the process and roles to your setup.

Imagine that all team meetings went away. Instead, members send the Product Owner (PO) their individual questions and estimates about backlog items. The PO and the Scrum Master (SM) determine the sprint plan, assign tasks, and answer questions all in the backlog management software. Instead of a daily Scrum (standup) and a sprint retrospective, members send their input to the SM, who then distributes a summary and action items. The PO/SM give demos to stakeholders and subsequently update the backlog.

Now ask yourself: Would this significantly compromise the outcomes that the team’s work produces?

If your honest answer is “no,” you have a workgroup, not a team.

You may be missing out on considerable potential: tackling harder problems, producing better-fit solutions, stopping wrong work early, avoiding perfectionism, increasing responsiveness, and building resilience.

(If you think of your team as an Agile one, this list of benefits is probably why you got Agile in the first place.)

One proven way to grow great teams is to have someone take this responsibility on themselves. That can be an Agile Team Leader (as I described in The Human Side of Agile), a Scrum Master, an engineering manager, or someone else. The key is to make it intentional and explicit.

If you’d like to discuss your team situation with Gil, write to us.