Meeting the Challenge of Collective Code Ownership

Martin Fowler has suggested that code ownership schemes fall into three broad groups, summarized here:

• Strong code ownership breaks a code base into modules each, of which is assigned to one developer. Developers are only allowed to make changes to modules they own.
  
• Weak code ownership is similar in that modules are assigned to owners, but different in that developers are allowed to change modules owned by other people.
  
• Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. 

Collective code ownership is the model promoted in Extreme Programming, and many other Agile practitioners also have adopted it.  One reason is that it increases "truck factor", to the customer's advantage. In the past, the untimely loss of one developer could cripple a team's ability to deliver.  Ideally, with collective ownership, a rogue truck would (sadly) have to wipe out the whole team before development would stop. Individual expertise is respected in this model, but directed toward mentoring and knowledge-sharing rather than ownership.

This model requires high adherence to discipline on the part of the team, which may be new for some.  An undisciplined team will find collective ownership problematic, perhaps onerous.

Ken Schwaber, co-creator of the Scrum methodology, has long insisted that Agile processes must be adapted to their context - within reason, the approach must be ajusted over time to maximise value produced. The average team needs to search out the appropriate balance between pure practice and compromises for local issues and constraints.  Martin Fowler has brought us one such story: a team in trouble took a step back to improve their discipline, with the goal of once again returning to full collective ownership over time.  Using their more expert members as code reviewers, the team brushed up on the basic practices that support collective ownership.  In addition to the short-term gains of increased velocity and improved morale, their weaker developers improved their skills, which will benefit the whole team in the long run.

To quote Schwaber:

So, I'd say agility isn't a silver bullet, only a process that requires a lot of hard work, attention, caring, and teamwork.  But is agile a bitter pill?  Not if you consider it like fitness training - you try your hardest, day-by-day, and you get better and better at what you are doing.

Fowler's article recounts a colleague's story, in which one team had the courage to temporarily step back into "training", in order to move forward all the better.