In Scrum, we rely on Teams, not “Working Groups,” to get the work done and deliver value by the end of the Sprint. Without a Team – Scrum will not work. So what is this term “Working Group?” Why do we avoid Working Groups in Scrum? And what do we mean, when we talk about “Team?” I know – the concept of “Team” is obvious, but I think Katzenbach’s and Smith’s book makes this distinction very clear and is helpful to understand where we are going when we decide to use Scrum in our organization.
In their book, Katzenbach and Smith identify these seven characteristics of a Working Group (see the list below). For me, the key ideas to take away from this list is efficiency and individuality. Another concept that stands out is there is no identity for the Working Group beyond the vision of the leader and the organization goals. Take away the leader, you have no Working Group. Take away (or change) the organization goals and the Working Group has no purpose.
- Strong, clearly focused leader.
- Individual accountability.
- The group’s purpose is the same at the broader organization goals.
- Individual work products.
- Runs efficient meetings.
- Measures its effectiveness indirectly by its influence on other, i.e. percentage increases in sales.
- Discusses, decides and delegates
Teams, on the other hand, have their own corresponding seven characteristics that differ from a Working Group. In this list below (I highlighted the terms I think are essential to focus on from a Scrum perspective), please notice how many the concepts are around sharing and the collective identity of the Team. The work, leadership, performance and decision-making are all shared by the Team. Another interesting difference between Team and Working Group is the Team must do the real work together in order to succeed. This is not the case in a Working Group, where the work can de delegated to some type of expert.
- Shared leadership roles.
- Individual and mutual accountability.
- Specific purpose that only the Team can deliver.
- Collective work products.
- Encourages open-ended discussions and active-problem solving.
- Measures performance directly by assessing collective work products.
- Discuss, decides and does the real work together.
So what is the connection to Scrum here? In Scrum, the goal is to provide a significant business goal that forces a collection of individuals to transcend the uninspired performance of a Working Group. The Scrum challenge of producing potentially shippable software that provides discrete business value within a short timebox at the end of each-and-every Sprint knocks people out of their focus individual accountability and individual work products into the space of Team. Each functional role working in their functional silo cannot produce the outcome the business is expecting with Scrum. In order to succeed, they must do the real work together.
In order to figure out the best solution that meets the business needs, avoid duplication of effort and meets the short deadline of the timebox, Team members must engage one another in open-ended discussions and active-problem solving. To support these types of conversations, many different members of the Team need to feel comfortable taking a leadership role from time-to-time and designated leaders must feel comfortable passing the mantle of leadership to others. As group, the Team must discuss and decide on who is going to do the work and when it must be complete. This encourages both individual and mutual accountability. All of this is enabled by self-organization – a belief that the people best suited to solve the problem are given the authority to come up with the solution and implement it. Without self-organization, a group of people will not transcend from Working Group to Team.
This focus on a real Team – not these mediocre Working Groups masquerading as Teams – is what I consider the real difference with Scrum. If you can create real Teams, then you get the effects of synergy where 1+1+1 ≠ 3, but 1+1+1 = 5 or 7 or even 10!.