More often than not, teams do specialize by skills like: frontend, backend, testing, etc. A cursory look at a job board makes it clear that the range of specialized skills is even broader: data scientists, Cloud maintenance engineers, DevOps, manual testers, and more. Developers are often hired based on these specialized skills - no surprise they may end up thinking they are there just to do one special kind of job. The risk that we are running here is the deterioration towards groups of uncooperative, though skilled, professionals.
This specialization, in today's world, is inevitable, but it does not have to be bad. It is extremely important to understand that specialization is a factor that influences the way the developers interact with each other and we can hopefully make it more transparent and use it to team's advantage.
Take me as an example - I have had much more development practice in backend than in frontend. Most of frontend designs I created were terrible. But if I were to re-use existing stylesheets and create a design of a sub-page that will be based on the current look and feel of an existing web service, I would be able to do that. Let me try to categorize my development skills a bit further:
- I'm skilled in backend - I'm really good at it, I'm able to develop elegant solutions quickly and I'm also able to mentor others.
- I'm comfortable with testing - I like finding ways to break things, I do not mind going through dozens of repetitive test scenarios. Testing doesn't give me as much fun as backend development, but I feel quite comfortable doing it.
- I'm weak in frontend - you know that already. But I am able to execute the simpler tasks, especially those that are based on existing styles and controls. If I were to work on a completely new wireframe, I would need some support from another developer and even with that it would probably take me some extra time.
- I'm lame when it comes to concurrency - I have rather academic knowledge of the topic, so even if I took much extra time to work on that kind of task and had the help from another developer available, I'm afraid I would let too many bugs through.
- Listen, this is not what I like most and I may not feel comfortable working hand in hand with other frontend developers, finishing their tasks quicker than me. But I am willing to work on this, because we need to be flexible as a team in order to reach our goals. I will need some help from our frontend experts. And please do blame me too much on how long it takes me to complete or if I stumble.
Traditional approach to skillset problem would be for a resource manager to draw up a skillset matrix, have everyone in a team tick off their skills and then assign goals so that people learn things. I'm not saying this method is completely wrong, it can be useful to identify situations we need to address, but look - even without goals for learning new skills most developers are able to do a range of things wide enough to produce a list of categories, like mine above.
The drawing on the left serves just to depict the categories and the range of things beyond one's capacity (can't do), so do not pay attention to how much percent each category spans.
With categories suited for your team, you can ask all your team members to consider their skills for themselves and then act fairly upon it, or you can go further and, upon unanimous agreement, arrange a session to talk about each other's skills openly.
The goal is to develop an attitude, within all team members, to be willing to take up most work based on what the team needs to achieve, rather than on "what gives me most fun" or "what increases my self-esteem".
The Product Owner defines the backlog based on what the customers need. It is not their job to define the backlog so that different skillsets in the team are fully utilized. This is why the development team must be able to create a substantial level of flexibility of skill. The way towards it is not that much through analysis and goals as it is through the change of culture and habits.