Why the Scrum Product Owner IS a Project Manager, part-1

On the surface, this statement appears as if I’ve lost my mind. For one thing, a traditional view of Product Owners is as a Product Manager or a customer/business stakeholder-facing role, and the traditional Project Manager is more 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 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 4-Quadrants in this series of blog posts [part1] [part2], I introduced four areas where I thought a well-balanced Scrum Product Owner had to have skill and focus:

1. Product Management
2. Project Management
3. Leadership
4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Management 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 the mapping 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 activities such as:

• Vision & Mission
• Goals
• Functional and non-functional requirements
• Constraints
• Success criteria
• Budget and ROI
• Establishment of teams
• 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. Terminology like Sprint #0 can often be heard or used as part of these efforts.

In this blog post, 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 blog post 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 team’s planning efforts and strategies.

For example, in the Scaled Agile Framework (SAFe) there is a specific Potentially Shippable Increment (PSI) planning event and risk planning is an important and distinct part of it. 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 for other contexts.

In larger, Enterprise-level contexts, I now think a concise look at the needs for organizational communication as being incredibly important for a successful, large-scale Agile effort:

• Who
• How often (frequency)
• What to communicate
• And gaining their buy-in that they’ll be listening

This communication plan, or the responsibility for creating and reinforcing it, falls to the Product Owner and the PO Organization.

4) Project Tracking and 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 team’s 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. These options largely fall to the Product Owner to make. With the team’s 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. And the bad news is that it’s not over. I will continue the role discussion in the next post. I hope you take the time to read it as well and connect-the-dots between the two.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve begun to show you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.