Although getting team agreement on coding style may feel like the hardest part of adopting collective code ownership, it’s actually much harder to get developers on the team to stop specialising by picking bits of the codebase that they consider as their own. It is quicker for someone who has worked on a module before to fix any bugs in it and be the per- son to add more related features, but doing this can create scheduling bottlenecks.
Specialising also makes it less necessary for the team to talk to each other about design and ask for help when they’re stuck. You’ll notice the developers don’t talk to each other much if they’re specialising in this way. Pair programming can help prevent this. Some teams we work with follow a simple rule that one person from each pair must swap out every day. This encourages everyone on the team to move between the user stories rather than sticking with the same story.
Don’t specialise rule applies to the TEAM in SCRUM and a sprint’s workload. Although the TEAM is self managed, every member of the team should be actively encouraged to work on any story. The success of the TEAM and the company depends of full stack developers who are empowered with a deployment system that allows them to release early and often. Every TEAM member should be a developer who is able to work on any story and does so to the standards agreed to as the “definition of done”.