Meeting the Challenge of Collective Code Ownership
- 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.
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.