To this point, we have identified that the agile Product Owner is an abstraction of many of our traditional roles in waterfall software development. The Product Owner is the Product Manager, the Project Manager, the Business Analyst, the Designer, and a whole list of other business stakeholders.
We have explored that this is a BIG job and VERY different from the role of the Product Manager. We have suggested that not many folks have the breadth of skills for this role… or the time available to do it well.
Many teams will insert a Business Analyst as proxy in an attempt to give the team the day to day direction that they desperately need. The problem with this approach is that the Business Analyst, or any other role aside from the Product Owner, is not the Single Wringable Neck… they just don’t own the product.
A proxy can give the team direction but are not responsible for making the critical decisions when things need to change. They have to go ask someone… and that someone is usually the real Product Owner. Separating the real Product Owner from the team WILL slow the team down and you WILL risk building the wrong product.
It encourages too much separation of concern. What we really need is a shared accountability model… a team of people, each of whom work together as part of the team… all accountable for delivering on the role of Product Owner.
Product Ownership by Committee
Simple Shared Product Ownership instead of the BA as Proxy
Right now, this is only a slight modification of the BA as Proxy Model. Rather than the BA acting as the Single Wringable Neck, both the Product Owner and the BA are available to the team. The Product Owner is there to articulate the vision and prioritization… the BA to work daily with the team to translate requirements. There is a partnership between the Product Owner and the BA, where both work for the team to get the team what they need and when they need it.
This is a subtle but significant difference from the BA as Proxy model. We have to have the Product Owner operate as a full time member of the team… they cannot delegate this critical function… but we need to get them some help.
Think about this for a minute… what is a Product Owner doing when not working directly with the team? They are out working with stakeholders, identifying product requirements, prioritizing the user stories, and getting the user stories ready to be consumed by the team. Most Scrum people call this grooming the backlog.
Let’s think about another one… what does the team need before they can accept a story into the sprint? They need a clear articulation of the business need, they need the acceptance criteria (the definition of done), and they need a foundational architecture on which to build the feature.
So… if getting the story ready for the team involves having a solid understanding of what it means to be done… and it assumes the existence of a baseline architecture… do we suppose that the Product Owner is getting all this worked out during the sprint planning meeting? Do we expect that user stories are some ad-hoc stream of consciousness based only on what the Product Owner learned after the last sprint review? Absolutely not.
Clearly the Product Owner is working out ahead of the team, making sure that they are building on a firm foundation of understanding… and that DONE is well understood.. and the features are in alignment with the stakeholder objectives. That is NOT the same as a big up front design… it is rolling wave… it is done at a high level of abstraction that gets more precise and more specific as we go.
If the Product Owner is allowed to think and plan ahead of the team, why not a group of folks that are part of the team… responsible for getting stories ready just ahead of the sprint? That is what I mean by a Product Owner team.
Introducing more roles into our Shared Product Ownership Model.
If we can stomach a shared role made up of Product Owner and BA, could we expand the cloud to include some design folks… or even God forbid… a Project Manager? Could we maintain a model where each person brings their specialty to bear, working with the organization in their unique way… and providing guidance to the team based on their area of expertise? I think so.
An Expanded Model in Practice
What that looks like in practice is a team of people, each with their individual responsibilities, almost like a subcommittee within the team… each representing their own particular view… all responsible for collectively grooming the backlog on an ongoing basis:
- The Product Manager has responsibility for working with stakeholders to identify requirements and set priority.
- The Project Manager maintains a view of the overall objectives and helps manage resources, capital expenditures, external dependencies, and touch points with the team.
- The Business Analyst is responsible for documenting acceptance criteria and documenting the conversations around the user story. They also become the primary point of contact for requirements clarification during the sprint.
- The Designer might prep some screen shots, wireframes, etc. to give the team an idea of the look and feel of the new features.
The Product Owner chairs the process, they remain the Single Wringable Neck, but have a support staff to help them research, document, and manage the inputs to the team. These people have responsibilities outside the team, but are razor focused on why they exist… to provide a well groomed backlog to the team… full of user stories that are ready to be pulled into the sprint. Each is available to the team during the sprint and all are collectively responsible, with the team… to deliver the sprint.
Business needs go into the process… actionable, buildable user stories come out of the process. Entire team accountable for getting to done. Pretty simple, huh?
Product Ownership by Committee with the PO, the Project Manager, the BA, and the Designers as all contributing members.
So… one more time, our Product Owner team is responsible for taking input from the broader organization, bringing their knowledge and expertise to bear on the problem, and working with the others on the team to craft a tangible message to the team to define context and provide coordination. Remember my last post? It all comes back to providing context and coordination.
More overhead? Yes. Necessary given the complexity of the task? Yes again. We can insist on a single product owner, but in many cases, I think we’ll fail.
Many of you guys might be thinking I’m making this too complicated I understand that is a risk. I am waiting for the Kanban guys to tell me about flow… there is a place for that within teams and across teams. I am waiting for someone to weigh in that this team of people cannot be held jointly accountable…. I hear you, but without shared accountability we all fail. I understand all these arguments but we need answers.
We have not even begun to talk about agile at scale. We have not introduced multiple teams, let alone multiple teams that have to operate in a coordinated fashion. We need to talk about organizations, organizational backlogs, and portfolios. This construct is probably too complicated for a single team… but we need a model that scales. This is going to get worse before it gets any better.
Next post… we’ll talk about how our shared Product Ownership approach scales to multiple independent teams and multiple interdependent teams. This is where the real fun begins. As always… thanks for listening.