Individual code ownership in Agile

In this article, we look at the positives and negatives of individual code ownership in Agile teams.

An alternative approach, the Collective code ownership is probably more advantageous to most organizations in the long run.

Individual code ownership

In many companies, a few developers are assigned an area of code that they are responsible and accountable for, generally a subset of a bigger system. In smaller products, a single person could be responsible for the entire code base. These “specialists” are supposed to look after only the area they have been assigned to.

Why do companies encourage individual code ownership? There are many reasons behind it.

1. A belief that the product quality will improve if specialists are groomed instead of generalists.
2. It’s a way of adding more responsibilities to programmers in the hope to motivate and encourage then.
3. Old timers in a company are thought to have better knowledge and hence given this responsibility.
4. It might also be a simple case of companies carrying over practices from the traditional development team structures into the new Agile teams. This is especially true of companies that are in the early phases of adapting to Agile methodologies.

Many fancy titles such as Code Guardian, Feature Owner, feature specialist etc. are used to describe the role of the individual code owner.

An informal and broad definition of a Feature Owner : They are regular developers, but their main contribution is limited to a certain feature or module. The responsibilities of the feature owner are generally:

1. Be accountable for a particular feature or module’s code.
2. Monitor and help out when others are working on the same feature.
3. Indicate approval on various decisions related to that feature.

Benefits of individual code ownership

The positives of an individual owning the code are

1. In extremely large companies, a collection of applications are bundled as a single unified system and delivered to the customer. These applications do not share the code directly, but generally tend to share common interfaces or communication points. In such big companies, it is not practically impossible for a single team or individual to know about the entire system. It is perfectly fine and also necessary to have different teams and individuals responsible for their own applications.
2. When the team is just being formed, there is generally a mix of developers of various levels and capabilities. At least until the team settles in, it is always good to have someone with more knowledge and responsibility to lead the rest of the team.
3. When developers are assigned to a single area, it is very common to see an increase in the productivity and the amount of delivery in the early days of this adoption. The reason for this vary from the initial enthusiasm of the new person, new viewpoints etc. This will start to disappear after a certain period of time when everyone is working in their own silos and no longer aware of any repercussions outside of their product or module boundaries. This benefit is seen only short term.

Negatives of individual code ownership

There are more negatives than positives to individual code ownership.

1. Lack of knowledge sharing.
2. Poor code quality and coding style.
3. Dependency on an individual.
4. Poor and useless code reviews.
5. Not adhering to Agile/Scrum principles.

For details on each aspect listed above, read the post on collective code ownership. Each of the negatives of individual ownership are addressed in there.

An alternate version of individual code ownership

There is a second form of individual code ownership – Weak code ownership, a term coined by Martin Fowler. This falls somewhere between individual and collective ownership.

In Martin’s own words,

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. Module owners are expected to take responsibility for the modules they own and keep an eye on changes made by other people. If you want to make a substantial change to someone else’s module it’s polite to talk it over with the module owner first.

This approach definitely works better than the individual ownership mentioned earlier. But in the end, it is always more beneficial to move to collective code ownership.