In part-1 of this article we began to explore aspects of Project Management responsibilities within the scope of the Product Owner role. I started to share a list of project management responsibilities that largely fall to the PO. In this article, we’ll conclude the discussion.

5) End-to-End Project Release Planning

One of the central activities of SAFe is conducting a 2-day PSI (Potentially Shippable Increment or Release Train) planning session as a team. The event is focused on mapping work (Epics & Themes) or the “ask” from a business perspective to each teams’ ability to commit to User Stories that meet the ask.

The planning takes an end-to-end view, so from:

• Requirements & visualization,
• Architecture – system, UX, DevOps
• Through construction
• Testing (functional, non-functional, automation development)
• Covering operational readiness (DevOps deployment, documentation, training, customer readiness, etc.)
• Deployment to Production

In other words, it takes a “Concept-to-Cash” view to ALL of the work required to deliver on the goals, themes, and features for the release. And keep in mind that the PSI is planned in a series of sprint-level increments, so it is an iterative plan.

In SAFe, there is a role entitled Release Train Engineer or RTE. They are largely responsible for facilitating and orchestrating an effective PSI-planning event.

Even if you’re not implementing the SAFe framework, many agile organizations and teams leverage some sort of release-level planning activity—particularly in at-scale agile It just makes sense to have a view to a larger picture before letting loose multiple agile teams towards an unplanned goal.

I would argue that the individual Product Owners and the Chief Product Owner are incredibly important to effective release planning. Not only to “set the stage” with the “ask”, but to be there during the planning to answer questions and to help the teams make appropriate scope tradeoffs as they try and deliver on your goals.

I would even say that Product Owners should become “students of” release planning techniques, approaches, and models. Even with an RTE or similar role, you’ll want to partner with them to ensure you and your teams have a solid plan. Here’s a that explore various forms of release planning in much more detail.

6) Stakeholder Management

I remember distinctly in traditional projects where our C-level team would “call in” the project managers for portfolio level tracking. Often they would never see or interact with the individual teams. Instead, the project managers were the sole lenses for each project.

This placed a tremendous burden on the project managers to effectively “manage” stakeholder information sharing, expectations, and their reactions. Some were good at it and others were not. Some had more trust with stakeholders, which mattered a great deal too.

Often you could draw a direct correlation between projects that were going well versus not, by the maturity and skill of their project managers stakeholder management.

As we move to agile contexts, this sort of stakeholder management is still largely relevant, but now it falls to Product Ownership to handle expectations management. Often it focuses on reinforcing the importance of your Stakeholders and Senior Leadership to “fully engage” with your/their agile practices.

For example, getting them to regularly attend sprint demo’s, release planning, Scrum of Scrums meetings, and even circulating around daily Scrums will give them a strong sense for progress, challenges, and where they might help.

But you’ll still need to provide a “buffer” between your teams and your stakeholders, so that they effectively understand and react well to the transparency and the adjustments being made.

Note: this crosses into the Leadership Quadrant of the 4-Quadrants to some degree. This is one of those nuanced areas that really make a difference in your overall success. I often challenge the Chief Product Owner (or other Product leaders) to think about who and how they’ll be thoughtfully and actively managing their stakeholders.

7) Project Retrospective

Clearly you’re involved in each sprint retrospective that your teams conduct. And I want to encourage you to fully engage in each one of them. But that being said, I also think you need to take your feedback acquisition “up a level”.

Your Sprint Reviews are a wonderful ceremony to gather feedback from your Stakeholders and Leaders. Please don’t miss that opportunity to gather their feedback as you deliver each increment. And don’t always assume that you’re getting it either. I’ll share a story to make that point:

I was talking to the EVP of Software Development at a conference not that long ago. He was describing the interaction in a recent Sprint Review or Demo. He said:

Bob, I threw a 5 to represent my reaction to the demo, but I wanted to throw a 2. In truth, the demo was terrible and I believe the team failed to meet customer needs in their development efforts. I just felt very uncomfortable giving that sort of negative feedback in front of a large audience. I pulled aside the Director of that team later, and I gave her my feedback.

I actually challenged him to speak the truth” in future reviews. I tried to make the point that it was important to be transparent with feedback as well. Sure, craft it carefully, but if a demo sucked and you said it was great, that is setting a very bad precedent.  He responded:

You’re right Bob, but we are located in the South and have a culture of thoughtfulness and care when giving bad news. It will take me (and us) time to get over this cultural barrier. But I can’t imagine “telling truth” for quite some time.

Clearly you need to work incredibly hard to get all forms and types of feedback out from your stakeholders. Be aware of your cultural norms and figure out creative ways to get the truth on the table so you and your teams can address any deficiencies or misses.

SAFe has a release-level retrospective at the end of each PSI. It’s a cross-team, ALL stakeholder meeting where issues are discussed and improvement action-plans are formed. So there are multiple “layers” to the feedback and reflection opportunities.

I’ve written several articles that explores the power of Sprint Reviews beyond simply showing software:

Get Help!

I wanted to remind you of one of the reasons I developed the 4-Quadrants in the first place. It’s because of how hard the Product Owner role is to perform well. It’s an incredibly deep and broad role that requires tremendous effort and skill. It also requires quite a bit of time.

I often joke, and it’s not really a joke, that I’ve only met 4-5 Product Owners who could perform all aspects of the 4-Quadrants by themselves. Ever! What this implies is that it’s OK to ask for help. In fact, you’ll most probably need to get help in your role.

If you have Project Management strengths and skills, then take some of this on yourself. If you don’t, then look for someone else in the organization with these skills and strengths to help you out. For example, in SAFe environments, you might want to make the RTE a partner or best friend.

But the KEY is to find or ask for help if you need it in the quadrants where you are weakest.

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.

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

Stay agile my friends,

Bob.