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!
| Reference: | How the Agile Project Manager and Product Owner Roles Intersect, Part 3 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
