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.”
Is it a Group or a Team?
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[1] Scrum “Teams” that fail to meet this most basic definition.
Teamwork vs. Group work
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
- 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 Goal.[2] A Group may indeed consist of skilled, well-intentioned individuals with a common goal, but without the collaborative effort to reach that 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 endpoint, 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 goals and determine how best to meet those goals. Another implication is that a Team is small. The standard Scrum guideline for Team size (between three and nine, with a ‘sweet spot’ of five) 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?
Looking for ways to help your Team function more like a Team?
We’ve got training for that.
Or ways for your Team to improve their Team-based Agility?
We’ve got a white paper for that.
As Always, Stay Agile.
Notes and Sources
- “Cross-Functional.” Scrum Dictionary, accessed July 13, 2017, https://scrumdictionary.com.
- “The Scrum Guide.” Scrum Alliance, accessed July 13, 2017. https://www.scrumalliance.org/why-scrum/scrum-guide/.