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% dedicated 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 a scrum 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 into the business and is effectively the product owner for the Agile Release Train (ART), the team of agile teams. In SAFe the Product Management is also empowered to ensure the dedicated ART budget is being 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. In the beginning, 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 still not true business people. Regardless, the fact that these product owners reported to me as the business sponsor did give me a sense of 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 just 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 were never going to be willing to dedicate the right people to working 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 whereby our largest requirements are epics, which are broken down into features, which are broken down again into stories for delivery by the agile teams. The ARTs 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% dedicated 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 have the ability to give. Almost anyone can find 4-5 hours a week for a month or two to contribute to getting a good quality outcome on a project that 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 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 facing 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 product owner. This enables the commercial decisions regarding scope to be retained by the funding business unit while still 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 features 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 in which the ART has it's 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 tend 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. How to run an ART without a Product Manger - is beyond the scope of this blog post, but something I promise to provide guidance on in a future blog post.
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.
Together with Christopher, Judith walked us through the responsibility process and how we respond to problems; moving from blame, to justify, to shame, to obligation. This is how we have been conditioned. If you are not familiar with the responsibility process, which I must admit I wasn't, here is the link to a one hour video overview.
The main premise of Judith's presentation was that questions empower. When you ask questions you are engaging someone, asking them to be creative, and honouring their intellect. When you give advice you take choice away from your teams so they don't feel responsibility. Technical people are used to being the smartest people in the room, they can be a little socially awkward and not wanting to draw attention to themselves or ask questions. Christopher says, "We need to create the culture where we are able to be vulnerable". This of course struck a cord with me given my last blog post before Agile 2013 was about "Leading Through Vulnerability".
"The cool thing about responsibility is you can't make anyone take it, all you can do is offer it and allow it" - Christopher Avery
|Scketchnotes by +Michele Ide-Smith|
|Agile Coaching Competency Framework (http://www.agilecoachinginstitute.com/agile-coaching-resources/)|
Lyssa showed a handful of videos of coaches she had worked with talking about how they had used the Agile Coaching Competency Framework which can be found here. I have posted my favourite of these by +Erin Beierwaltes below.
|Jean Tabaka's recommended reading list for Enterprise Agility|
The first topic, Flow, was introduced by Jean Tabaka. Jean said, "I don't think agile is sufficient on its own to deliver value to the customer,... I don't think executives should be talking about story points or velocity,... Good executives pay attention to "intraprenuers". "The flow of value Agile" is the best way to learn quickly. We have to take a long view of the flow of value, start earlier than the team and look beyond effective deployment to the hands of the customer. In value stream flow we watch: customer, cadence, capacity, clogs, cost and collaboration.
Collaboration across all different parties is essential. You are not going to be enterprise level agile unless you are collaborating with upstream and downstream process. Collaboration doesn't happen on its own, you have to help it. For Enterprise Agility we need to move from a language of cross functional to cross departmental. Hendrik Esser commented that "you need to look at the whole product life cycle" and Esther Derby noted, "The way accounting works and the way people are rewarded is keeping things the way it is". Esther also mentioned that the Agile Alliance is sponsoring an initiative to look at an agile accounting approach.
Hendrik covered the second topic, Collaboration and Decision Making. Collaboration is about abandoning contract thinking between different parts of one enterprise. Esther echoed this, commenting that "We need to adjust our plans so we can satisfy our customer rather than "you missed the date you won't get your bonus". We need to visualise uncertainty if we want to embrace change for example provide a range of possibly delivery dates rather than specific milestone date. Jean gave the analogy of Neo choosing between the red pill and the blue pill in The Matrix. "People willing to embrace a sense of uncertainty are taking the red pill". Enterprise agility requires us to have a new way of measuring success and failure, different metrics other than points and velocity. In Jean's view, the only useful metric is one the team asks for to help itself understand how it's doing. Esther pointed out that this holds true not only for development teams. Hendrik added at Ericsson "We measure our performance not our people".
The third topic was Eco-system, lead by Esther. If you keep replacing the individuals and get the same results it is a clear indication there is a system problem. Trying to "idiot proof" through policy or procedure almost guarantees you will get "idiotic behaviour". "I find job descriptions often get in the way of people collaborating", said Esther. We have a legacy of thinking of organisations as machines. This is not the type of ecosystem that enables flow, adaptability and responding to change. Trust begets transparency and transparency begets trust. Without this, decision making and flow breaks down. Trust is contextual not binary, and to get trust at an ecosystem level you have to give trust. What people don't know they fill in with their own fears.
The subject of building trust, brought some of +Brene Brown's material from Daring Greatly to mind for Jean: "If you have shame and blame there is no possibility of innovation We are asking individuals to be vulnerable, to enable this the organisation needs to extend its vulnerability". Esther closed out this section with the following messages: "You need to start where you are. Trust grows incrementally. Once you start seeing systems, blame goes away. It's very powerful!"
I know you are thinking, wow, she made it to Nashville and saw some live music, sorry to disappoint but the Music City Concert Tour was the name of the conference event, held in the exhibit hall, Wednesday evening. While I didn't see or hear any country music stars, I did get a free flashing guitar pin - which made brilliant "gifts" for my leadership team when I got home.
As with all the conference social events, it was another great opportunity to meet people, such as Hendrik Esser, and catch up with people I had met in Boulder earlier this year, including +Ronica Roth, +Drew Jemilo and +Jennifer Fawcett
After grabbing some dinner at one of the hotel restaurants, I headed to a gathering hosted by the guys from Leading Agile, +Dennis Stevens and +Mike Cottmeyer, where I scored a great (free) t-shirt. Thanks guys!
Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.