There is no such thing as a Feature Owner... Or is there?

When an organisation introduces agile, it is not uncommon for there to be a mass rollout of Agile Fundamentals training, where the role of the Product Owner is positioned as being an empowered business person who is colocated with and 100?dicated to work with the agile team. This sounds wonderful in theory, but when we start to scale, this begins to get tricky.

 

I once worked for an organisation that had a policy whereby you were only allowed to run your project agile if the business made a product owner 80% available to the project. Of course, the business wasn’t silly; they knew how to get around this constraint - either find someone in their department who isn’t adding a whole lot of value and allocate them to support the agile team or hire a contractor off the street and have them fill the role of Agile Product Owner. Problem solved!

 

As we begin to scale agile, the pressure on the business to provide more and more product owners exacerbates the situation. As much as we might want it to be the case, most businesses don’t have a small army of people just waiting for an agile team to come and adopt them. The Scaled Agile Framework (SAFe) has historically attempted to address this capacity constraint by allocating members of the development organisation to the product owner role and adding the role of the Product Manager, who reports to the business and is effectively the product owner of the Agile Release Train (ART), the team of agile teams. In SAFe, Product Management is also empowered to ensure the dedicated ART budget is invested in the right features.

 

As someone who has been the business sponsor of a large agile program, I am very familiar with how challenging it can be to source enough business product owners to support multiple agile teams. Initially, I opted for the “contractor off the street” solution. Well, that is a slight exaggeration - most of the contractors were not exactly off the street and were at least somewhat familiar with the solution context, but they were still not true business people. Regardless, the fact that these product owners reported to me as the business sponsor gave me comfort.

 

As ingenious as I felt my approach was, it was not the right solution. These proxy product owners caused all sorts of challenges for the delivery teams. They didn’t have the in-depth business knowledge required to support the agile teams on a day-to-day basis.  So when I first came across SAFe’s product owner model in Dean Leffingwell's Agile Software Requirements, Product Owners reporting into development felt like an even bigger compromise than the approach I already had in place.

 

I knew what we needed was real business people. I also knew the business units would never be willing to dedicate the right people to work with the agile teams. So why not ask the business for something they can give…a Feature Owner. Yes, yes, I know there is no such thing as a Feature Owner, so bear with me a moment while I explain...

 

You see, SAFe has a requirements hierarchy where the largest requirements are epics. Epcis are broken down into features, which are broken down into stories by the agile teams during PI Planning. Agile Release Trains deliver features, and features have business benefits. So rather than attaching the content authority to the ART in the form of a Product Manager or the team in the form of the Product Owner, why not have a content authority for each feature in the form of a Feature Owner?

 

Unlike a product owner, we didn’t expect Feature Owners to be 80-100?dicated to a single agile team. Instead, we expected them to be available to the team(s) 4-5 hours a week, every week, that their feature is being worked on. The idea was to ask the business for something that they can give. Almost anyone can find 4-5 hours a week for a month or two to contribute to a good quality outcome on a project they care about. As a rule, I have found that once the Feature Owner and the Agile Team have established a relationship, a human connection, then the arrangement changes from a number of hours a week to all parties collaborating to contribute whatever time is necessary for the successful delivery of the feature. From the teams’ perspective, the Feature Owner is the ultimate authority and single voice of the customer on the scope and acceptance of the feature.

 

Over the years since I first used this model, I have found many other ARTs have faced similar challenges with respect to the availability of business product owners and the allocation of dedicated ART budgets. The feature owner model has often come in handy in these situations. Sometimes the Feature Owner is more like a Product Owner for a specific feature, collocated with the team and able to provide a large proportion of their time to the team while their feature is being developed. In other scenarios, the Feature Owner is supported by a product owner who is a member of the agile team. When working with ARTs in the Digital domain, the role of Feature Owner has often been played by someone from the business unit funding the feature, while someone from the channel team plays the product owner. This enables the commercial decisions regarding scope to be retained by the funding business unit while enabling those responsible for the channel’s customer experience to ensure consistency. In some cases, I have used this model to augment the technical product owner as advocated in SAFe.

 

One of the most common concerns people raise about this model is the impact of multiple feature owners on the agile team. When applying the Feature Owner model within SAFe, we need to ensure that we have also provided the teams on the train with a force-ranked, WSJF-prioritised backlog, so there is never any doubt about the priorities of the features being delivered by each team. Limiting feature WIP can also help minimise any confusion or competing priorities caused by multiple feature owners working with a single agile team.

 

You may have noticed that the introduction of the Feature Owner role does not address the role of the Product Manager. In a world where the ART has its own budget, the function of Product Management probably wouldn't change much.  However, if your ART is project-funded, this gets a little more complicated. One of two models tends to apply in this situation. Either the Product Manager is the business owner of the ART (common in the digital domain where the business may have a nominated channel owner), or perhaps there is no Product Manager at all. (In these instances, we often use a Pipeline Manager.)

 

So, while technically, there is no such thing as a Feature Owner, perhaps there is a place for such a role in some circumstances. In my experience appointing a Feature Owner provides a pragmatic solution to some of the challenges we face when Scaling Agile. In most cases, it does not replace the need for each team to have a product owner; instead, the addition of the Feature Owner augments the Product Owner and strengthens the connection between the business and the agile teams. I like to think of the Feature Owner model as prioritising access to the right people over more access to the wrong people.