Agile Product Owner Team
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 Agile 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 Agile 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 Agile 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 Agile 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 Agile Product Owner.
Agile 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 Agile 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 Agile 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 Agile 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 Agile 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 Agile 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 Agile 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 Agile 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 Agile 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 Agile 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 agile 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 Agile Product Ownership approach scales to multiple independent teams and multiple interdependent teams. This is where the real fun begins. As always… thanks for listening.
Comments (19)
bonniea
This sounds like a feasible extrapolation of what might happens to accommodate a large and complex project. It seems to have those assumptions built in, and I can imagine other teams dealing with scale in different ways.
The thing I don’t see here is how to ensure that the Product Owner team doesn’t become detached from the development team, that it doesn’t spend all of it’s time grooming the backlog. This team isn’t just responsible for providing input to the team, but then checking and aligning the output as well. Rolling wave is good, but they need to be there at both ends.
Stewart Rogers
Mike I like the team approach. Just a little concerned about the roles and how I have understood them to be organized, as per your post. You have described, what others have described [liked your pictures better :-)] outside the context of Agile but within the context of Product Management.
The Product Manager is responsible for talking to the market (customers, prospects, etc.) and the Product Manager is responsible for the success of the product. The other roles like Product Owners, Business Analysts, Project Managers and Designers are supporting roles to the Product Manager.
Within the context of the sprint/iteration, I agree that the Product Owner should take the lead and ensure the (Product Management) team are ready and for day 1. But the overall success of the release (many sprints) and product falls to the Product Manager.
I know titles are meaningless, but it can be confusing to others.
Mike Cottmeyer
Thanks for the comment bonniea.
Couple of thoughts. First thing that comes to mind is how do we ensure that the Product Owner does not become detached from the team? That in itself is rampant on teams trying to adopt agile. I think that you solve it with some combination of shared location, shared accountability, and shared rewareds. No one can be successful without everyone being successful. Your question can apply really to any role on the team.
That said, if you have a formal arrangement with the Product Owner team where they have very well defined roles and responsibilities… they can work the specifics out themselves and self-organize. The two non-negotiables for me are:
1. Backlog must be ready for the team prior to sprint planning
2. Product Owner team is a subset of the entire team. Everyone has shared accountability for delivery.
This is an issue again that many teams adopting agile struggle with. Incentive plans typically reward individual performance. I recommend some % as individual, some % as team, some % as organization.
Mike Cottmeyer
Stewart –
I think that the role titles here mean different things to different people.
Problem 1 – Many agilists assume that their Product Manager becomes the Product Owner. Not always true
Problem 2 – The Product Owner is much bigger than the Product Manager. As defined by Scrum, the Product Manager incorporates aspects of of Project Management, Business Analysis, and Design… as well as Product Management
Problem 3 – Product Owners or Product Managers acting as Product Owners are not available enough to the team. Agile requires near instant response time from the Product Owner
Problem 4 – If the Product Manager delegates (names a Product Owner) to a proxy (the analyst or a junior Product Manager) they are seldomly the single wringable neck. They cannot make decisions in real time.
My whole reason for going down this series of posts is that I totally get the Product Owner as defined in Agile. I also totally get the Product Manager as defined on a traditional project. We keep defining the ideal… which is great and maybe we hold that up as an end goal…
My concern is that teams are failing because we don’t have this clear yet for complex enterprises. Both sides are talking but I don’t think that anyone is listening.
We need some strategies that don’t depend on retooling our entire organization overnight… something people can get their heads around today and begin to execute.
Thanks for your comment… are you still planning on being down in Atlanta this month?
Jim Benson
“My concern is that teams are failing because we don’t have this clear yet for complex enterprises. Both sides are talking but I don’t think that anyone is listening.”
This is the gold of this thread.
There are a lot of people out there following the letter of the law in Agile without getting the context or rationale. This results in a rigid and confused agile implementation and then confusion when it doesn’t work.
Which, in turn, leads people to say “Yeah, we tried agile and it didn’t work.” And agile purists to say “You’re not doing it right.”
The problem is they’re both wrong and they’re both right.
Jeff Anderson
Your approach seems like as reasonable and approach to scaling agile as any…
I think a lot of this boils down to common sense, as projects get bigger, no one person can fill all hats.
I would also include testers/QA in your “committee”, these kinds of resources can provide discipline and structure often lacking…
Laura Brandau
Brilliant post. There is so much ground to pave in defining the agile product owner role. And until we work through models like the team-based accountability you put forward we won’t see all the benefits brought to bear by an agile development process as we won’t truly be building the right things.
I myself am part of a product owner team that very much aligns with this model. As business analyst, I’m responsible for the wireframes and acceptance criteria. I facilitate discussions with multiple business stakeholders, help drive decisions, and finally review acceptance criteria with the “single wringable neck” before our sprint planning meetings. The product owner is responsible for prioritization and final decisions. I do admit that once in awhile there is a delay…I might get a question from a developer that I can’t answer without her input. But the alternative would be a much slower process to define the stories in the first place, so we’re much better off in our current situation.
Best,
Laura
http://www.bridging-the-gap.com
Mike Cottmeyer
Awesome Laura, glad to hear others our there putting this kind of stuff into practice… it just makes sense.
Kevin Brennan
I admit I find this comparison really throwing me off. Granted, as far as I can tell there’s no one definitive source describing the responsibilities of the Product Owner, which may be part of the problem. There are a couple of things that confuse me. In part I’m trying to get this straight because after a couple of years working on the BABOK, I’d come pretty close to the conclusion that the PO is a BA with decision-making authority. Now, my expectations of a BA may be stronger than yours, but that’s why I’m asking the questions.
The definition states that “The Product Manager has responsibility for working with stakeholders to identify requirements and set priority” which implies that a Business Analyst doesn’t do those things. I’d consider those skills central to being a BA…in fact they’re explicitly or implicitly called out in the IIBA definition of the role. Now, I grant that there’s a difference between a Product Manager and a BA, but I think it’s really a difference in subject matter, not skillset (a Product Manager understands the requirements of a market, while the BA understands the requirements of a organization).
The other thing that throws me is the Project Manager part. From what I can tell Scrum assigns almost all of the traditional Project Manager responsibilities to the Scrummaster and the team. Again, a BA/Product Manager should be capable of understanding and maintaining a focus on the objectives, and the other tasks are just a small subset of the Project Manager role.
Like I said, I’m not sure whether this is because I’m missing some key understanding about the Scrum PO role or if it’s because I have a different set of expectations about the BA role. If the former, I’d like to get a better understanding of the parts I’m missing. ;-)
svilen dobrev
g’day.
very good thoughts.
last 2 years i did exactly this stuff – extremely entangled and complex (90k python?) but low-resources project, me being the leader (and also the only methodolohy-aware one in the company), things got pretty rough.
i didn’t follow exactly Scrum, instead i went by Cockburn’s Crystal Clear but all the same, Product Owner roles became a nightmare. Yes they has to be multiple! They are the frontline between pure software and the rest – application/market and organisation.
So what i ended was: Business Analyst/Expert, Expert User, Product Manager, Project Manager, Architect, GUI-designer, (And End-Testing). Shared between two people, me and a lady that i was teaching on the run, both with plenty of other duties… impossible!
One may say that this or that of the above roles actualy lives elsewhere… yes but 50%/50%. And if u split by the letter, the info has to move more frequently between many more heads, and that slows the project! Probably there has to be 3 people as there are 3 main stakeholdoing directions: development, organisation, endusers; all these has to keep in mind the now and the future.
IMO this stuff is usualy all understated, underrated, underestimated, underthought if u want.
Regardless of the methodology, these roles has to be there and u cant lump them all into single person for any big project (note: big not just in the sense of people involved, but reality to describe)… That head will explode.
have fun
svil
Mike Cottmeyer
Kevin,
I hear you on your understanding of the roles… but an empowered BA is not the same as a product owner. A ScrumMaster is not an agile project manager.
I don’t know if you read the 6 posts leading up to this one… but it is my fundamental assertion that many of our traditional roles have been abstracted behind the role of the product owner.
Organizations… and I have worked with 25 or so this past year and a half… all struggle with the product owner role because 1.) there is not enough definition and clarity about what we are REALLY asking of this person and the skills we need them to have and 2.) it is often too big a job for a single person.
As I have been writing this… here is my best analogy to a traditional role that I can equate to a product owner: I am a company with an external client… I have assigned a Project Manager to OWN delivery for the external client… The Project Managers is responsible for gathering requirements and has authoritative decision making ability to make that customer happy. They OWN the customer requirements, often serving as the BA as well, and they own delivery. They get FIRED if they project does not meet customer expectations.
Problem is… that doesn’t exist everywhere in IT in general or software development.
My $0.02. Thanks for the comment.
Mike Cottmeyer
Svil,
Thanks for your comment. I could not agree with you more.
Mike
Kevin Brennan
Mike,
I think at least part of the difference is that I have higher expectations of a BA than you do…or perhaps that I’m trying to encourage BAs to have higher expectations of themselves.
From BABOK v2:
“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.
Business analysis involves understanding how organizations function to accomplish their purposes. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the courses of action that a business has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact.
Business analysts must synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives.”
I’m not sure that that’s exactly what you think of as a product owner but it doesn’t seem wildly off.
Erik van Eekelen
Mike,
Interesting post and comments.
My company currently has 9 scrum teams of 4-8 people, and the PO role definitely is too much work for one person. So this is why we have BA´s assisting the PO in the way you describe.
However, if you leave it with that, it is not clear if a BA is actually inside or outside the team (pig or chicken), because he works on other user stories than the team.
This is why we have agreed that – as a rule of thumb- 50% of the Analysts' time is spent on work for this sprint: answering developers' questions and working on system specs (definition of done).
The other half of the time is spent on assisting the PO on backlog items that are probably going to make the next sprint.
This seems to work, but it is too early to conclude anything yet, we just finished our second sprint.
>>>
Kevin,
The main distinction between the BA role and the PO role, as I see it, is that a BA works from an objective point of view, especially when bridging between IT and business.
If the BA has the role as customer (PO) as well, calling the shots, s(he) is no longer a bridge but instead a business representative. This would result in more friction while communicating with IT, not a good idea I think.
Erik
Matthew Caruana
Interesting post and I believe delegating task and not ultimate responsibility is a possible solution to the fact that the purist PO role is too big to handle.
Apart from this internal product owner team (Internal in the sense of dealing with the inward facing duties of the PO), it could also be argued that organisations set up another committee to assist the PO in the external side of things.
I believe that the PO should be very close to the Scrum team and therefore the PO could get more assistance in dealing with the external facing duties by setting up a PO external team to deal with market research, product positioning, market trends, customer feedback, response to the sales strategy and other stakeholders management. We call this the Product Board.
This committee could be made up of members from other departments such as, the marketing, sales, senior management who are in constant contact with the external world.
By giving the PO this additional forum and bringing these different stakeholders to discuss issues through product meetings we can ensure that the PO is responsible for these areas and all aspects of the product while getting assistance in collecting information, dealing and resolving stakeholders conflicts and analysing the market situation better.
Bob Lieberman
I was happy to see a discussion of a PO team, and especially recognition that the PO role as described in the Scrum framework calls for a superhero, of which there are few willing and even fewer capable.
But I don’t want a PO team that doesn’t include a representative from the delivery team (such as a senior developer, architect, etc.).
I’ve found that conceiving of user features and stories without involving technical staff in discussions leads to: the appearance of late-breaking tech debt (on an urgency basis), stories designed for function rather than for reducing technical risk, and even poorly conceived solutions (for lack of the engineering point of view).
Your thoughts?
Also… without some team agreement, the PO team isn’t going to function very well. They need a facilitator if not a leader. It’s the rare PO that would be willing to play that role, and the scrum master is the next likely candidate. But what scrum master would want to wade that deeply into story conception?
Thoughts?