Specialization and generalization in a team

Below is a draft of an article I've been working on. Any comments are welcome!

-------------------------------------------------

Specialization in Scrum is a hot topic for already many years. It pops up at every Scrum course I do. It is an important topic and is relevant for a new team in their first Sprint.

Specialization comes up when I explain to people that by the definition of Scrum, a team must be cross-functional. I also recommend the members to be 100% dedicated to the team (they are not a member of multiple teams). Most people who are new to Scrum accept it without considering the implications. Sometimes someone will ask: "But what will the QA person do at the beginning of the Sprint?"

There are a couple of assumptions behind this question. The first assumption: test can only start after development is done. This common assumption is just not true. When adopting modern practices such as Acceptance Test-Driven Development, the test starts before the development has started. The second assumptions is that a QA specialist can only do QA. I personally found that one of the greatest skills of humans is: they can learn new things! So, I don't believe this assumption to be true either.

The question can be generalized to:"What does a person with blue-specialization do when there is no blue-work". Blue could be testing, front-end development, Java, component C, database changes, writing documentation or whatever. This happens nearly always in a team using Scrum. Why? Let's look at the scenario in the picture below.

In this team with the team members are specialized -- red, green, blue, purple and black. All members are dedicated to this team and have a shared responsibility for all the work on the Sprint Backlog. The Product Owner selects the work based on the customer value. If the number one priority for selecting work is customer value, then how likely would it be that that work balances out over the skills in the team? 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 mismatch that causes people to say:

"Scrum needs generalists!"

This conclusion is unfortunate. If there is a mismatch between skills and requirements then that does not mean that everyone in the team needs to be able to do everything. This is a typical thinking mistake which is that the world is binary -- there are only two choices: specialist or generalist.

The truth is that specialist-in-exactly-one-subject and generalist are the extremes on the scale of specialization. There is a lot in between them! For example, I can be mainly a blue-specialist, but I can also do purple and black. I might not be as efficient as the uber-purple-specialist, but I'll manage.

Balancing specialization

When a team truly takes a shared responsibility of all the work in a sprint then that causes the need for balancing specialization. People in the team have to learn a little bit of each others 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 learn multiple-specializations but probably never all.

Balancing specialization results in the following team dynamic:

• Specialization is used when that is 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 current 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 consist of two blue-specialists and two red-specialists and blue-work is selected, then the blue-specialist will probably do this work. Most teams realize there is value in specialization, so when we can use people's specialized knowledge then they do so. Also team members actively become specialist on particular areas because that increases the productivity of the team.
  
  Opportunity for multiple specialization
  
  "I've been a blue-specialist for many years. The next Sprint some blue and some red work is selected. My team members are able to take the blue work so that I can learn a new red-specialization." Many people want to actively learn new areas. It keeps the work interesting and their knowledge fresh. In a team balancing specialization the opportunity to expand my specialization should exist.
  
  Opportunity to focus on one specialization
  
  "I've been diving in blue for the last Sprints. I've always wanted to be a blue-specialist. So therefore, the next Sprints, as long as there is blue work, I would like to do that." People inside a team shouldn't be forced to learn a new specialization. As long as their knowledge creates value for the customer, they can keep focusing on their specialization. The team will need to deal with the situation when there is absolutely no work in a specialist 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 organization
  
  The balancing specialization happened in every Scrum team I've worked with. It often causes conflict in the early Sprints where the fresh team members scream "I've been blue for years! I won't do purple!" The team will need to resolve this conflict by learning how to work as a team. A good ScrumMaster facilitates this conflict in the team so they resolve it.
  
  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 and reporting to a blue-functional-manager, then would I want to learn purple? Probably not as this would be harmful for my status and my career. Similarly, if I get a performance target to become blue-er, then the breaking of specialization area won't happen.
  
  Another common obstacle is when organization "manage around the specialization bottleneck" by partially allocating people to multiple teams. This makes it even worst as there will be no incentive whatsoever to break the specialization bottlenecks in organizations.
  
  ScrumMasters need to identify these organizational dynamics and try to remove them. This is hard work as it requires to change the organization. When the organizational obstacles are broken the balancing of specialization will happen 'automatically' in the teams.
  
  An interesting closing observation is that the same team-dynamics is true on organizational level: the needed skills always mismatch the required skills. This means that organizations that optimize their specialized human resources will never deliver based on customer value.