Specialization and Generalization in Teams

17 January 2011

Bas Vodde
Odd-e

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Catia Oliveira, CSP,CSM,CSPO, 1/19/2011 7:41:53 AM
This great article reminds me one of the greatest (they are many I think) I read in your (and Craig's) book: "Specialization is good- it increases depth of knowledge, productivity and pride in workmanship. Single specialization is harmful - it creates constraints, silos, waste of handoff and mental communications barriers" . Great prespective, even knowing (as you say) this is a hard work.. mental models are truly hard to change. But then again...that's why we (scrum allies) exist ;). Cheers, Cátia
Dinesh Sharma, CSP,CSM,CSPO, 1/30/2011 3:32:27 PM
Bas,
I agree what you say in principle but in reality 'sometime' it's difficult to learn purple skill for a blue specialist. Especially when people have built their career on that speciality e.g. Database Modeling and DB Administration. Considering same example if a team has team members with J2EE, QA, Database Modeling skills, it's difficult for QA and/or DB team members to learn (quickly) J2EE (as it involves different technologies within J2EE itself) if they have never coded in past. Having said that it won't be that difficult for J2EE person to learn QA and DB Modeling skills (No disrespect for QA or DB) because DB Modeling and QA skills are easier to generalise in comparison to J2EE.

I am not saying it's not possible because I have been part of successful Agile teams where each team member had multiple skills but in the end it depends on Individuals if they are motivated enough to learn new skills. This model gets bit more complicated if you are working for a Software Consultancy firm to deliver a product to your external customer rather than building in-house product. But that's seperate subject to debate to implement agile for Fixed Cost/Fixed time projects


Dinesh
Guruprasad K, CSM, 2/18/2011 5:08:46 AM
Bas, good article. Ideally, it is wonderful to have cross-functional teams. But, I completely second Dinesh's thoughts. It is not just the career prospects with in the organisation that is impacted but even the market dynamics. If I am a Java Programmer for 3 years, why would I want to learn QA for 1 year. In the Market I would like to call myself as a specialist in Java for 4 years rather than saying that I have done 3 years of Java and 1 Year of QA. Certainly my market value is not going to be the same. Probably if the skills are complimentary, it may help.
I would really be interested to know your experience in building the "Cross-functional" teams, the challenges you faced and how you overcame.
James Peckham, CSP,CSM,CSPO, 6/29/2011 6:13:19 PM
I want to point out you don't need everyone to be switch hitters... you just need 1 or 2 per team. Enough to clear the roadblocks/bottlenecks.

if you have a need for a whole team of generalists that tells me your architecture, organizational structures, and or product is inadequate.

Make sure you design teams and product around appropriate specializations in the first place.

If you made your product to require tons of changes at every level with every single update, you may have an issue with the architecture that needs re-engineered.
Chee-Hong Hsia, CSM, 7/9/2012 7:17:01 AM
I agree with both Dinesh and Bas.

The term cross-functional is in my opinion a word thatΓÇÖs often misinterpret when working with Scrum. Some say that cross-functional means that every team member needs to know a little bit of each otherΓÇÖs disciplines. This is possible of course but it depends heavily on the project and company. When your project is for example a .NET project and where there is a clear line between front end and backend development, it is possible to be ΓÇ£cross-functionalΓÇ¥ and help each other out.
This scenario will be a lot difficult if your team consist of different platforms like .NET for frontend, Java for backend, Tridion as CMS, and itΓÇÖs a strict organization.
In this case itΓÇÖs difficult and unrealistic to assume that a .NET developer can pick up very specific backend work with a lot of specific Java frameworks etc. (it works both ways of course) Also in some organizations, technical writing is a discipline that not everyone can manage.

So… truly 100% cross-functional is like a fairytale…

In my opinion the true meaning behind cross-functional is ΓÇ£having enough disciplines in your team so be able to finish the projectΓÇ¥. As such, the true idea behind cross-functional is to operate as a team and optimally use the power of multiples.
So when it comes to dealing with the Product Backlog, yes the Product Owner sets the priority but it’s always the team that determine how much work they can manage AND IF THEY CAN MANAGE IT ON TIME. If the team feel that they can’t commit to a couple of User Stories because some specialists are on vacation, report that to the Product Owner so that he/she knows about it and (if want the proceed) understand the risks. This will indirectly mean that not always the highest User Story can be taken into the Sprint. So in real life you have to look at your team construction for the upcoming Sprint and micro manage the User Stories (as a team) and see which Stories are realistic to do…


You must Login or Signup to comment.