On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view to Product Owners is as a Product Manager or customer/business stakeholder-facing role. And the traditional Project Manager is more so a planning and execution focused role. The two are quite far apart and seem to have little synergy.
The other factor is traditional versus agile contexts.
There are no “traditional” Product Owners. Usually a Product Manager is in essentially the role but it’s very outwardly and upwardly facing. Once the requirements are “signed off”, they’re not that interested in collaborating with the team until the end of the project.
And traditional versus agile project managers can be quite different. For one, the acts of estimating, planning, and tracking are the prime directive. For the other, these are important, but team collaboration, exploration, customer feedback, quality, and value-based delivery are even more important.
The 4 Quadrants of Product Ownership
When I introduced the , I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:
- Product Management
- Project Management
- Leadership
- Business Analysis
The one that seemed to get the most pushback from folks was the Project Manager area. I think because many had a view to traditional project managers they’d worked with in the past and they were having trouble mapping these skills into the role of Product Owner.
I actually struggle with that aspect myself – so I get the need for the activity. I just worry about more traditional project managers (or the tactics) having a negative effect on their agile teams performance. Nonetheless, let’s explore it.
A Deep Dive into the Product Ownership – Project Management Quadrant
Next I want to explore seven specific project management-oriented activities that should help you visualize the responsibilities of this quadrant. The list isn’t exhaustive. For example, I could have added some sort of budget level and ROI responsibilities to the list. And there are probably others. But it should give you sufficient flavor to help you understand the quadrant more and to effectively describe Product Owner responsibilities within it.
1) Project Chartering
It often starts with a project vision or base need on the part of the business. This then drives a project chartering activity where things like:
- Vision & Mission
- Goals
- Functional and Non-functional requirements
- Constraints
- Success criteria
- Budget and ROI
- Teams themselves are established
- High-level plans
- All leading towards some sort of “Commitment”
Within an agile context, teams need to be pulled together, jump-started, and product backlogs (high level to low level) need to be constructed with the teams. Terminology like Sprint #0 can often be heard or used as part of these efforts.
In , I explore some of the dynamics of creating a “proper beginning” for agile projects. Agile project chartering is this activity and I believe the Product Owner should be in the middle of helping craft an effective launching pad for their agile projects.
2) Project Risk Management
A few years ago I shared a about agile risk management. Essentially I implied that it wasn’t done the same as in traditional projects; that there was very little specific “risk planning” in agile projects. Instead, the entire team was responsible for surfacing risks as early as possible and for mitigating and reacting to those risks.
Now I still largely hold to that advice, but I think it changes a bit in many projects. I do think that having the team “sit down” for a bit and brainstorm their project risk landscape as a good idea. As is factoring these discussions into the teams planning efforts and strategies.
For example, in the SAFe framework there is a specific Potentially Shippable Increment (PSI) planning event and risk planning is an important and distinct part of it. And these plans either surface in a succinct risk plan, or better yet, in the PSI plans and strategies to deliver the committed features.
3) Project Communication
When I was studying for my PMP, one of the key areas that they discussed as part of “good project management” was pulling together a Communications Plan. I used to think that it wasn’t needed for agile contexts. I thought that the principles of software demonstration, transparency, information radiators, and cross-team communication naturally took care of “all” the necessary information sharing.
And that’s true in smaller contexts. But I’ve changed my mind elsewhere.
In larger, Enterprise-level contexts, I now think a concise look at the needs for organizational communication:
- Who;
- How often (frequency);
- What to communicate;
- And gaining their “buy-in” that they’ll be “listening”.
as being incredibly important for a successful, larger-scale agile effort. And this communication plan, or the responsibility for creating and reinforcing it, falls to the Product Owner and the PO Organization.
4) Project “Tracking” & Adjustments
I’m using the term tracking lightly here, but someone needs to be aware of the “big picture” commitments that the project has made and then map the teams’ progress back to those plans and commitments.
In traditional environments, that’s either the project managers and/or functional managers. In agile contexts, I contend it’s the role of the Product Owner.
Now the job isn’t too difficult because of the level of real-time transparency that should be occurring within and across your agile teams. Often there is a cross-team authority, for example a Scrum of Scrums meeting, that consolidates this information into a single meeting and set of tracking artifacts.
The real value of the tracking is what you DO with the information – i.e., the adjustments you make within your plans. This is distinctly different from the traditional responses, where projects were either on or off track. And, if they were ��off track”; often overtime and quality compromises were the only way to get them back “on track”.
In agile contexts, we want to “flex on SCOPE” as our leverage for adjustment. And these options largely fall to the Product Owner to make. With the teams input and help of course, but scope tradeoffs are how you adjust towards your goals.
Wrapping Up
I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. But whether you like the 4-Quadrants model or not, this work is there for you regardless. The key is to be aware of it, get someone covering it, and to do it very well.
We’ll continue this discussion in Part-2 of this article.
Stay agile my friends,
Bob.