How the Agile Project Manager and Product Owner Roles Intersect, Part 3

In What Agile Project Managers Do, Part 1, I described what facilitative agile project managers do. In What Agile Project Managers Do Not Do, Part 2, I described a number of roles a more traditional project manager might think is their job still, even if they are supposed to be/use agile.

Sometimes, people get confused with what they should facilitate and what not to do. That's because their role has changed. The agile project manager facilitates work that the team decides how to do. The product owner (a new role in agile) decides what to do and the ranking of the work for the team to deliver.

These changes lead to problems in expectations and in how the team works.

I've seen expectation problems in these ways:

  • The PO thinks the team doesn't need the stories broken down into something the team can complete each day (or more often).
  • The PO thinks the team cannot help write stories.
  • The PO thinks the team doesn't need to address the legacy problems the team may have. Instead, the PO has feature-itis.

When the POs don't understand their roles, the agile project manager can help the PO understand what to do and how to treat the team. See my PO series. The summary post is Product Owners and Learning, Part 5.

I've also seen team problems, such as experts taking a story (or, even estimating “their” stories and taking “their” stories).

In teams that don't (yet) understand flow efficiency and still use the ideas of resource efficiency, the PO might even encourage individual experts to take their own “stories.” (These things are often tasks, not stories.) The PO wants the feature done, in the most productive and efficient manner. The PO might encourage team members to take their own stories. Or, the PO might demand that.

Here's the thing: everyone wants to produce features and finish work in the most effective manner. If the agile project manager understands the ideas behind flow efficiency, the agile project manager might say or do any of these things:

  • Say nothing and start a cumulative flow chart to see the WIP for the team.
  • Ask, “In our team norms, we said we didn't want to take stories alone. Are we revising our norms?” Then, wait to see what people answer.
  • Say, “I see a risk when people reinforce their expertise, instead of sharing their expertise. Is it time to consider other options?”

If you are an agile project manager, you might say or do totally different things. I have tried all of these, with different teams. I have had varying results. If people are open to hearing about flow efficiency, we can make progress. Sometimes, people feel such stress, they cannot imagine another way to work. That means I have had to work at a different level to understand why people felt that stress.

What about when someone wants the team to deliver some feature(s) by a certain date? That's all in the PO's purview. All of it. What happens if the PO is not strong enough to stand up to the pressure. That's where the agile project manager can help the PO by:

  • Showing burnup charts of project-based finished work. (See the product backlog burnup in Velocity is Not Acceleration, for example).
  • Offering to work with the PO to develop ways to see what is most important by when and what is not.
  • Offering to work with the PO on the short-term roadmap (and maybe the long-term roadmap). (See Product Owners and Learning, Part 1 for images.)

An agile project manager performs different work than a command-and-control project manager. The agile project manager focuses on systemic obstacles for the team and the flow of work. It's not easy!

5 Replies to “How the Agile Project Manager and Product Owner Roles Intersect, Part 3”

  1. “When the POs don’t understand their roles”

    I feel like this is actually a misrepresentation on the role of the Product Owner. The team is responsible for the technical strategy and the delivery of features that are architecturally sound, and for the removal of technical debt as they continue to deliver features. The feature definition and vision for their delivery is what the PO is there for. If a team is pushing a PO for stories to fix their technical debt then the problem is in the delivery and the Agile PM should be encouraging the team to include refactoring and changes to architecture as they require them, in their estimates and as part of the tasks for them to deliver the work.

    If the team is unable to deliver a good framework, and rearchitect as they go, perhaps the problem is too much pressure on them, or that they feel they can’t afford to spend the time to do it. They need to be empowered more, and take the time to consider their decisions.

    1. Rob, I might frame it a little differently: that the team needs to deliver finished features without debt. Sometimes, the team delivers a framework (or frameworks) as they learn from implementing features. I am probably picking nits.

      And, to your other point, what about technical debt and insufficiencies the team has from their previous work? I agree with you, that the code the team delivers needs to be clean now. I see many teams where the PO does not think the PO needs to address broken-ness of the product, and expects the team to deliver, without fixing anything.

      Now, the team could estimate the work so that they include it in the features, to create ease and speed for release. I prefer the PO know what the PO is getting.

      1. I would say that broken-ness can be said to be in the eye of the beholder. I see teams seeking to want to fix technical debt in code thats working absolutely perfectly from a customers and clients point of view (and without an onerous support overhead), and that isn’t failing on a day to day basis, simply because it’s not up to the standards they seek to achieve now.

        If the application is not behaving, to the extent that users are affected, then the PO would likely be prioritising stories to improve it in any case. And when the team comes to it they are responsible for implementing it the next time in the way they now think is more suitable.

        So I see it as less the PO not recognising legacy problems the team has, and more that the way to address those problems will be dealt with more effectively, if its structural and behaviour-driven within the team. Pushing the emphasis to the PO, and encouraging technical stories over features, moves the goalposts to what should be a feature-driven process, and doesn’t strike me as suitable to what the PO should be doing.

        1. Rob, given your examples, I totally agree with you. I am seeing very long build times and insufficient test automation (for any number of reasons) that continually slow the team down. I am not talking about goldplating or addressing code that does not exhibit problems. I am talking about how the team’s throughput is slow and the PO does not want to address that.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.