Collective Ownership

For quite some time the game development team I work with has been practicing Feature Ownership.

A Feature Owner is a central point of contact, someone who is the front person for a new feature to be developed. That means scheduling Refinement sessions, helping the team reach conclusions, answering questions about the feature, keeping the producers and game design in the loop, guaranteeing its quality and maintenance post-release, etc.

Although it is a very precise role, at the same time it tries not to be authoritative. Instead, our internal motto was “be the driver”, devaluing the “owner” word. A “Feature Driver”, if you will. Instead of doing all of the above, do it together with the team and ask for help.

But there’s no denying that having a specific role with the “Owner” word in it brings a different feeling. And even if we changed the name to “Feature Driver”, it would still be a role for a single person.

Adaptability#

As our game evolved, it eventually started being worked on by more than one team. Adaptability became important, and that meant that any team had to be able to work on the code, regardless of who the original developer was. ¹

Although Feature Ownership does not necessarily impede that, it could (does?) reduce Adaptability on other fronts. Reflect on the following questions:

• If the Feature Owner goes on Vacation during development
  • is there loss of knowledge?
  • can the team continue to refine the feature without them?
  • is the team empowered to make new decisions?
  • is the team empowered to make changes that could contradict what was already defined by the feature owner?
• Does a Dev who is not a Feature Owner share the same level of accountability for the feature?
• Is everyone equally informed of decisions?

Consider the vision from Extreme Programming:

ExtremeProgramming considers code to belong to the project, not to an individual engineer. As engineers develop required functionality, they may browse into and modify any class. They are responsible for keeping all the UnitTests running (and writing new ones for new functionality). They take on the same integrity-preserving duties as the class owner in a CodeOwnership situation.
– https://wiki.c2.com/?CollectiveCodeOwnership

Is Feature-Ownership compatible with that vision? And is it compatible with Scrum?

Who is the Feature Owner?#

Traditionally, Feature Owners were always Client developers. Why not a QA Developer? Or a Server Developer? In our team, since we usually only had one server developer, there was more or less the consensus that they act like Feature Owners for the server side; although they are not given the role formally. There was never a QA Feature Owner as well. But even if we had, does having three Feature Owners make sense? Doesn’t that defeat the purpose of having a central point of contact for the feature? Why not the entire team altogether?

And, if we consider replacing “Owner” with “Driver”, I ask, what is a driver? Is it a motivated individual? If the entire team is not motivated, can the driver still lead the team to success? Or does the driver need the team to be fully engaged as well? If the team is engaged, is the team the driver?

Trying out a new approach#

I asked our team to experiment not having a Feature Owner - that is, practicing Collective Ownership. That meant that, contrary to other features, there would be no central point of contact for the feature. There’s no person responsible for scheduling refinements or talking to producers and game design about things. There’s no unique individual to be kept in the loop about information. The entire team is responsible.

At first, it sounded weird. But like most things, we need to experiment and later reflect on the experience to learn more.

There was no initial setup set in place for this - we just tried going into it without a Feature Owner. We let the discussions around the Feature start and evolve organically.

What I personally observed#

I noticed more team members to be engaged with the discussions during Refinements. This led to more discussions and more ideas on the table. The people who were usually more quiet were more engaged and caring about the implementation.

The team didn’t had many problems when people were in vacation. This was a big plus, and something that was hurting us in the previous Feature when we had a Feature Owner. It’s also important to reflect that sometimes the unexpected happens, people get sick, people need to take their dogs to the vet, and being prepared for this.

Some roles came up organically (a specific team member was mostly the one doing the scheduling of refinements and or other meetings). It’s expected human behavior, but also one that might not be good as it takes the chance of other people to do different things. Depends on the case, but it’s usually good to ask people to rotate certain responsibilities.

What the team observed#

After the feature was done, we did a post-mortem and draw a Systems Thinking graph together to reach some conclusions.

Overall, it was a positive experience. We understood that some things led to an increased Lead Time: for instance, more people participating means more debate, which means more time is needed. However, some others things reduced Lead Time: everyone has more knowledge, therefore more capable of achieving the results; there’s no dependency on one single person, therefore no loss of productivity in absences.

With more debate and more knowledge and more diversity of ideas, the quality of the project increases, which reduces Lead Time in the long term.

Adaptability overall increases.

Not a Panacea#

This is not a one-size-fits-all solution, as almost nothing ever is. It will depend on the team and the culture (or team personality if you prefer), and the goal you’re trying to achieve (in our case, adaptability).

One of the questions that we had was: if everyone is the owner, does it mean that more people will feel responsible? Or will it be the opposite? Wouldn’t it be that if everyone is responsible then no one really is? In the post-mortem we concluded that it did work in our favor, but your mileage may vary.

Something that Feature Ownership had good feedback about is that giving the chance for a person to be someone the feature depends upon had a very strong motivating effect. It also gives the person the chance to grow in other areas, such as Leadership and Planning skills. Collective Ownership immediatly reduces this; but other solutions can be applied here to help. (For instance, having everyone to rotate roles and have equal standing in planning and refinements, increase frequency of feedback).

Additionally, I’m still skeptic this would work in larger teams. Our team has six devs, if it was around 10 or more people, this might bring some more challenges to the table.

Overall#

The team enjoyed Collective Ownership and we decided to keep practicing it 😌