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.

shared responsibility.jpg

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.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai