Collective code ownership in Agile teams

There are two types of software development teams, ones that follow Individual code ownership and ones that follow Collective code ownership.

It is never a straight forward decision to choose between the two as there are positives and shortcomings in both approaches. In this post, we discuss the strengths and weakness of Collective code ownership.

Collective code ownership

In collective code ownership, the entire team is responsible for the code. Everyone works together to produce a product of quality. No one individual is greater than the rest of the team members. This is what the true Agile teams are supposed to be.

Which one is better? Should you go with collective ownership or individual ownership of the code? We have experienced that collective code ownership is better in the long run.

Lets take a peek into the various factors that helped us come to this conclusion.

Benefits of Collective code ownership

1. Knowledge sharing

When only an individual is responsible for certain modules or features, a knowledge-silo is built up. This leads to critical knowledge being confined to a smaller group of people or even worse, an individual.

When the team is collectively responsible for the code, everybody learns. With more people having the knowledge to make a difference, the product quality is bound to improve.

2. Code quality and better coding style

With many people contributing to the code, it will result in better overall quality of the code. Of course, this is assuming that they care about improving the code. With only one person coding in a module, there will not be any constructive criticism of the work carried out.

Let us not ignore the coding style – each person has a different style, some more understandable than others, some better and efficient than others. When the team contributes to the code, it will evolve without leaning to an individual’s coding style and hence more comprehensible to a wider set of people.

3. No dependency on one individual

On a lighter note, this is sometimes referred to as the “bus effect” or the “lottery effect” or things on those lines. What if the individual responsible for your code wins the lottery and quits the company? Will the team struggle? If yes, that’s one reason to start giving responsibilities to the the team collectively.

4. Efficient and useful code reviews

When no one else other than one person knows about the code within a feature or a module, the code reviews become a farce. Aside from being able to make abstract comments at a high level, real improvements cannot be suggested.

In the other case when everyone in the code review is more familiar with the code, the reviews are highly beneficial with everyone contributing to the code review, different ideas and improvements come to the discussion and optimal solutions can be chosen.

5. Great Learning scope

Most people stagnate in terms of their skills development if doing the same work over again. One way this happens is when companies create specialized roles and responsibilities with in the development team.

It is continuous learning that keep the developer’s skills sharp and the mind active. With constant interactions and discussions with better developers, one can learn a lot in a short period of time.

6. Agile/Scrum Principles

Collective responsibilities and interaction are what Agile is all about. The teams with collective responsibilities tend to be more adept at sticking to the Agile principles than ones that don’t for the following reasons.

1. Collective code ownership automatically results in a Self organizing team.
2. As per Scrum, it is the individual team members that should pick the work of their choice. It should never be assigned before hand to a particular person or a role.
3. Estimation of efforts should happen from everyone’s input. No one person should have a majority say in the estimation process.

Negatives of collective ownership

With all the positives of collective code ownership, one might conclude that it is no brainier to go with that approach. Whilst that is true in most cases, it is worthwhile considering the following aspects.

1. Who is responsible?

Unless the team consists of individuals that are responsible by nature, collective ownership will result in no ownership. A quote comes to my mind.

When everyone is responsible, no one is responsible.

2. Responsibilities & Motivation

If there is one thing that differentiates successful people from mediocre ones, it is that successful ones always want more responsibilities. They are never the ones to just do their job and go home. They want to improve things further, their passion makes them go the extra mile.

If the better developers are not given more responsibilities or challenges, it will demotivate them. It is a knife’s edge that separates democracy vs individual brilliance.

3. Team’s technical capability

The team’s technical capability will play a huge role in whether collective ownership will sustain for the length of the project, or whether the project will be successful at all. A group of mediocre or poor programmers will not achieve good results. It is instead better for more skilled person to be making the important decisions on behalf of the team, to govern and monitor the work done by others.

4. Specialization vs Generalization

In extremely complex products, specialized people are hired to carry out specific functions. For example, consider a team consisting of business intelligence specialist, big data expert, security expert and a mobile application developer. There is no possibility that each person here could do the other person’s job. In such teams, collective ownership would be impossible and should not be enforced as well.