Thoughts On Collective Code Ownership

Agile (at least in part) is about forming small, cohesive, well-motivated teams where each team possesses all the skills they need in order to get the job done. During a sprint, some developers' timescales may slip, while others' will get ahead. To ensure that the sprint is delivered on time, you need a team that contains multiple generalists, i.e people who can work on multiple areas of the code so the team as a whole stand a reasonable chance of delivering even when problems are hit. To anyone familiar with Agile practices, this is not news.

For me, enabling this involves a few things, including:

• Eliminating single points of failure within the team, i.e. avoiding the situation where the skills required to complete a particular task lie with a single team member.
• Making the code as easy to work with as possible, i.e. so anyone can pick it up and make changes. 

So how do you achieve this? I've found that the following works well:

• Get non-experts working on features. Estimate for any team member doing the work (not just the expert) and allow time for non-experts to pair program alongside experts as required. This will help eliminate single points of failure and increase the number of generalists on your team.
• Enforce coding guidelines / standards, so that code is formatted in the same way across the codebase. This makes it easier to read and work with. Code will be familiar to each team member, and they're more likely to feel a sense of ownership. 
• Run team building exercises that encourage collective code ownership such as Coding Dojos. This will help improve the efficiency of pair-programming on your commercial products and will also improve team cohesiveness. 

Collective code ownership isn't necessarily without it's problems though... 

• You could argue that a generalist is more likely to break code in any one particular area. You can't know everything in-depth across the entire code base, so aren't you just likely to introduce additional risk? This is where Test Driven Development comes in. If you have a comprehensive suite of unit tests, a non-specialist can make a change and have confidence they haven't broken anything else.
• If more people are changing any one area of the code base, direct coding conflicts (conflicting change sets) are more likely to occur. This is where Continuous Integration can help. If conflicts are raised as soon as code is checked in, the overhead / impact of resolving them is much smaller.
• It requires developers set their egos aside. People who were responsible for the initial creation of a particular module are often reluctant to let it go and be modified by other developers. Good documentation (formal or code commenting), knowledge sharing and developer briefings can ensure that future code changes are made in line with the original design.

As a final note, I'm not saying that a team shouldn't contain specialists and that you, as a Team Lead, shouldn't take advantage of their skills in a particular area. But just bear in mind that having knowledge reside with a single person is a dangerous business and as the Team Lead it's your responsibility to mitigate that risk.