Overcoming the false dichotomy of Specialization vs Generalization with Scrum

Virtually every Team in their first Sprint is confronted with the problem of single-specialization causing work imbalance. What happens? The Product Owner orders the Product Backlog to maximize value. But when the team members are specialized in a single dimension - such as QA, Java development, front-end development - some team members regularly will find themselves with no work related to their area of specialization. Single-specialization inevitably causes work imbalance.

Organizations typically react by applying the following quick-fixes, (1) have people be on more than one team, (2) give additional work to the team, or (3) do work for the next Sprint (e.g. design) or work related to the previous Sprint (e.g. QA). The latter two quick-fixes are easily recognized as they lead to half-done items at the end of the Sprint, often referred to as ‘carry-over’ or ‘spill-over’ work.

Key point: The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.

Each of these quick-fixes inhibit well-oiled teams and reinforce responsibility at the level of individual members. For most organizations, Scrum entails a change in teams from individual responsibility (of my area of expertise) to a team-shared responsibility (for all work required to achieve the goal of the Sprint). Scrum makes this explicit by having a role: ‘Team’ – a single role of multiple people, rather than roles of team members.

Shared responsibility through balanced specialization

How do teams resolve the problem of specialization and work imbalance? Although it is up to the team, most teams have members learn and create secondary areas of specialization. This does not mean that all team members become generalists – either single-specialization or generalist is a false dichotomy.

Team behaviors that lead to balanced specialization are:

• Whenever the team has the right expertise for current work, every task is a learning opportunity. Any team member can either pick it up and do individually or request to pair or mob.
• Whenever the team feels there is currently enough learning going on, the tasks tend to be picked up by the team members with the most expertise in them.
• Whenever the team does not have the right expertise for the current work, the team discusses how to gain that knowledge through learning and collaboration.

Implications for organizational structure

Most organizational structures, such as functional departments, functional career paths, or component teams cause single-specialization in either functional skill or technology area. When these structures are kept in place while adopting Scrum, they cause conflicting loyalties. Team members have one loyalty towards their team for their shared work and another loyalty to their organizational unit. The organizational loyalty is involved in performance reviews, promotions, and bonuses and therefore tends to ‘win.’ Shared team responsibility only happens when these traditional single-specialization focused organizational structures are eliminated.

Scrum implies a shift from individual responsibility to shared team responsibility, which in turn implies a change from single-specialization to multi-learning. This can only be achieved by eliminating organizational structures that promote single-specialization. Scrum adoptions by ignorant managers that avoid these changes are likely to lead to pretend-Scrum – the same old with new words.