How does specialization fit into Scrum?

Question

One of the rules of the Scrum states the team should self organize and be in control of the technical part of the project. It is rather easy when Product Owners are delivering tasks which every member of the team is capable of dealing with. But there are some cases when it became more complicated, for example:

1. When it comes to deciding on architecture of the project it is noticeable that one of the team members is much more experienced, so democracy in decision making in such area is maybe not the best idea. (or such team member is brought to the project especially because of previous problems with architecture)
2. Some products are designed for specialized group of people. Product Owners have the knowledge about functionalities they want to introduce and how such features should look like, but each task needs also a legal advice on it's subject. Probably legal advisors should be introduced to the team.

I could bring more examples if needed but you get the image...

So my question is: "How does specialization fit into Scrum?"

and "How to introduce work of specialists into tasks taken by Scrum team?"

My thinking is:

When I throw task at the team they should be capable of doing it. If they do not have all the knowledge, technical skills or competences needed then such task should remain out. Introducing specialist to the team only in order to handle such tasks would probably create botle necks and is rather a fake solution to the problem.

So how to fit them properly into the team?

Answer 1

The reason why Scrum introduced equal role for each member of the team, with the exception of Scrum Master and Product Owner, wasn't to make all people in the team generalists but rather to show that everyone should feel equally responsible for achieving the goal or failing at it.

With such attitude having specialists in Scrum team is perfectly OK. If there is an architect who designs architecture which everyone else would build on - that's fine. But then, we have The Team which is responsible for getting the product right, which means both: the architect and, say, a developer should feel equally responsible whenever it appears something is wrong with the architecture.

It means there shouldn't be finger pointing and blame game to show that the architect screwed and now the poor developer has to clean all the mess. On the other hand it shouldn't be a situation when the architect feels everything is perfectly fine as they did their job and these are definitely developers who just don't get the concept.

If it's working well, the only thing you need is to find some simple mechanism which allows you to deal tasks reasonably among your specialists. It can be either choosing specific tasks or stories to be covered end-to-end by a specific person or rather splitting the process into a few stages and have different people deal with different stages, e.g. developer building a story and QA engineer testing it.

A final note: don't underestimate the power of self-organization. I would assume that people would have healthy level of discussion on architecture even if there's the architect in the team. After all, no one considers they know everything, do they? You'd need to step in if, and only if, you see the team running your specialist down for non-merit reasons, e.g. "we don't like you because you haven't worked with us on the previous project."

Answer 2

Even if it is very obvious who is the best fit for the role the team should always be allowed to self-organize. If someone not performing the work decides who does what: a) it doesn't save any time; b) it sets a bad precedent.

Answer 3

First, +1 to @Ken and @Pawel, because it is the team's job to organize and make the appropriate decisions as a team. However...

Any question about specialization is should be a conversation about the relative merits of specialization vs. generalization in your particular context, and the same conversations are about both individuals within a team and about entire teams. As with many things in project management, neither extreme is all that appealing.

First, at a team level, which I feel makes for much more obvious examples:

• If your company doesn't do anything but .NET, you should probably specialize your teams around associated skill sets. It doesn't make sense to maintain teams that have a strong Java capability if you never use it.
• Ditto visual design skills. If your products are essentially serving systems and publishing API's, your teams in general don't need to maintain strong visual design skills or front-end development skills.
• Teams supporting many products in production often need a much broader set of skills to effectively handle the broad requests that come in, and as such are less able to really go deep on any one aspect.

Now, those same scenarios can help inform the type of specialization desired within the team. Examples and thoughts:

• Teams that do a lot of new development should have one or even two people that are very strong at understanding systems and their interactions and the trade offs inherent in various design approaches. Some people call them "architects."
• Teams should have enough design and testing capability to allow them to achieve their definition of done in a meaningful way.
  • Generalizing between tests and dev is far easier than people make it out to be. I've never met a dev who couldn't script tests, and I've never met a tester who couldn't learn to read code (Thanks @lunivore for the language)
  • Business analysis and testing is really the future vs. past tense of very similar skills, and is very easy to learn to do both.
• "Rare" skills, like security & penetration expertise, are often more valuable as a shared advisory and mentorship role across multiple teams, unless the team has continual and deep security ramifications.

The team composition decisions need to be made based on your context, and then management needs to be more "hands off", telling the team what capabilities they value from the team without meddling in how the team achieves those goals.

Answer 4

I'm not an expert in Scrum, but this is where I can smell a rat:

... one of the team members is much more experienced, so democracy in decision making in such area is maybe not the best idea...

Scrum assumes that the team consists of self-motivated professionals, which are honestly doing their best. Such a team shall effectively make decisions together. In other words, democracy is the best idea in Scrum. Otherwise, it's not Scrum.