Get certified - Transform your world of work today

Specialization and Generalization in Teams

01/17/2011 by Bas Vodde

Specialization in Scrum has been a hot topic for many years and pops up at every Scrum course I run. It is an important issue that’s particularly relevant for a new team in their first Sprint.

Scrum defines specialization as a cross-functional team. I recommend the members be 100% dedicated to the team and not a member of multiple teams. Most people who are new to Scrum accept that premise without considering the implications, but sometimes someone will ask, “What will the QA person do at the beginning of the Sprint?

There are a couple of false assumptions behind this question. First is that test can only begin after development is done, however this common assumption is simply not true. When adopting modern practices such as Acceptance Test-Driven Development, the test starts before the development even begun.

The second assumption is that a QA specialist can only do QA. I find that one of the greatest skills people have is that they can learn new things, so I don’t believe this assumption to be true either. Many organizations, however, continue to promote this line of thinking in their organizational policies and procedures.

Broadly speaking, the question can be boiled down to, What does a person with blue-specialization do when there is no blue-work? Blue could be testing or working on front-end development, Java, component C, database changes, writing documentation, and so on. Why does this question come up so often with teams using Scrum? Let’s take a look at a common scenario.

In this team, all the members are specialized -- red, green, blue, purple, and black. All members are dedicated to this team and have a shared responsibility for the work on the Sprint Backlog. The Product Owner selects the work based on the customer value so if that’s the number one priority, then how likely is it that the work balances out equally among the skills each team member possesses?

For most teams I've worked with, the likelihood is probably near 0%. Thus, in most teams (especially in larger organizations), there is a mismatch between the work and the skills of the team. It is this inequality that causes people to say, "Scrum needs generalists!

This conclusion is unfortunate. A mismatch between skills and requirements does not mean that everyone in the team needs to be able to do everything. That type of binary thinking leads people to think there are only two choices: specialist or generalist.

The truth, however, is that specialist-in-exactly-one-subject and generalist are the extremes on the scale of specialization, but there's a lot in between. For example, even if I'm mainly a blue-specialist, I may also do purple and black. I might not be as efficient as the uber-purple-specialist, but I'll manage.

Balancing specialization

The need for balancing specialization occurs when a team takes shared responsibility of all the work in a Sprint. As a result, team members need to learn a little bit of each other's specialization. This does not mean that all team members must be generalists, but that members move away from the other extreme -- being a specialist in exactly one area. Team members will learn multiple-specializations but probably not all of them.

Balancing specialization results in the following team dynamic:

  • Specialization is used when it's the fastest way to generate value.
  • There is an opportunity for team members to have multiple specializations.
  • There is an opportunity for team members to focus on their specialization as long as it generates value.
  • A mismatch between available and needed skills automatically creates learning in the team

Let’s look at these one at the time:

Maximize specialization when possible - If a team consists of two blue-specialists and two red-specialists and blue-work is selected, then the blue-specialists will probably do this work. Most teams realize there is value in specialization, so make it a point to use people's specialized knowledge. You’ll also find many team members will pro-actively become specialists in particular areas to increase the productivity of the team.

Opportunity for multiple specialization - Many people want to actively learn new things and will leap at the chance to take on additional work in areas. It keeps the work interesting and their knowledge fresh. Balancing specialization in a team and the opportunity to expand specializations should exist.

Opportunity to focus on one specialization - Conversely, people inside a team shouldn't be forced to learn a new specialization. As long as their knowledge creates value for the customer, they should be allowed to keep focusing on their specialization. Eventually, the team may need to deal with a situation when there is absolutely no work in a specialist's area -- usually by breaking the specialization.

Automatic learning - If the team consists of mainly blue-specialists and the next Sprint has mainly purple-requirements, the team has to break their specialization and learn purple. If the next Sprint is mainly green requirements, they will need to break the specialization again and learn green. The more the skills area in the requirements change, the more generalized the team becomes. If the skills area in the requirements don’t change much then the team becomes more specialized.

Impact on organizations 

Balancing specialization occurs in every Scrum team I work with. It often causes conflict in early Sprints where the fresh team members say, "I've been blue for years! I won't do purple! The team needs to resolve this conflict by learning how to work as a team, and a good ScrumMaster facilitates this conflict so it gets resolved quickly.

The structures and policies in many organizations make balancing specialization more difficult. For example, if I'm the blue-specialist and on a blue-career-path which reports to a blue-functional-manager, then would I want to learn purple? Probably not, since that may interfere with my status and career. Similarly, if I get a performance target to become blue-er, then the breaking of specialization area won’t happen.

Another common obstacle occurs when organizations “manage around the specialization bottleneck by partially allocating people to multiple teams. This makes the situation even worse since there is no incentive whatsoever to break the specialization bottlenecks in organizations.

ScrumMasters need to identify these organizational dynamics and try to resolve them. This is hard work as it requires change within organization. When the organizational obstacles are broken, though, the balancing of specialization happens automatically in the teams.

It’s interesting to note that the same team dynamics also exist at the organizational level. specifically that needed skills always mismatch required skills. That means organizations that optimize their specialized human resources will never deliver based on customer value.