There’s no “PM” in Scrum. There are POs (Product Owners), SMs (Scrum Masters), and Devs, but no PMs (Project Managers) in Agile methodologies like Scrum. But if there’s no project manager, who manages constraints like budget, timeline, and scope? Who develops and keeps their eye on the release plan? Who’s accountable?
Product Owners
If you listen to the sages at Construx (advisable), you’d understand that the Product Owner has “The Single Wring-able Neck.” Though the scrum guide is a tad more subtle, it points in the same direction:
- “The Product Owner is accountable for maximizing the value of the product…”
- They are accountable for “effective Product Backlog management, which includes
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;”
Of all the Scrum team roles described in the Scrum Guide, the Product Owner is the most accountable to the “many stakeholders” of the product.
Projects Without Project Managers
Could it be, then, that projects and products without project managers are just fine? I think not because project constraints in the context of Scrum, beyond the boundaries of the sprint, are ill-defined and perhaps have no clear place within the model.
A PO must “maximize the value” and if we take this literally, maximizing means everything and the kitchen sink. Experience often confirms this tendency in Product Owners. This is totally expected if you agree that Business Analysts (BAs) generally make great POs. BAs are awesome at their job because they don’t think too readily about constraints. They dig and ask and wonder and poke.
This means that in the real world, we are left with a delivery framework void of explicit constraint management as well as a paradox of Nature in which the psychology of the people most suited to jump into the PO role usually does not suit them to constraint vigilance.
Even in the context of Scrum, there’s a need for project managers, certainly in any environment of high constraints, whether they be budget or scope-related. It’s also easy to imagine less cut-and-dried constraints that have no clear owner in Scrum. For example, consider the domain of best practices, such as the inherent benefits of smaller releases and speedy delivery over larger, more feature-deep product releases (another principle from Scrum Bootcamp).
Project Managers in the Post-Waterfall World
This podcast, Project Managers 2023, explores the role of project managers in the post-waterfall world. It’s a thoughtful discussion that generally affirms some need for project managers within agile development. Some key ideas, most of which I agree with and some I question, are summarized below:
Maybe, maybe not:
- Scrum master may indeed be the natural role for the traditional PM in agile, but as measured against Scrum orthodoxy, it would be Scrum Master “plus.” Plus, risk vigilance, attention to the constraints that naturally occupy a space outside any one sprint, and the moxie and unlegislated authority to keep the PO truly accountable for what resides in the gaps.
- “Without a PM who manages the long-term schedule and releases, it is usually the Product Owner who manages them in Scrum.” True, schedule and releases are key constraints that live outside the typical Scrum box and need to be managed. But managed by a PO? I doubt it. Not if this PO is of the typical BA ilk. In fact, I’m not sure how you dissect schedule and release management from risks and general constraint management. It’s a job and mindset in its own right.
- PMs not a factor in small organizations and projects? Objection! Even small organizations and projects, though generally less risky than larger projects and complex teams, can have high-stakes delivery goals with tight constraints and deep technical or requirement complexity.
Right on:
- Risk management is a big reason PMs are still needed, and though, yes, agile done to prescription should naturally reduce risks, risks are by nature unpredictable, varied, and dynamic. Surveying the landscape with risk vigilance is an essential responsibility and natural to the PM mindset.
- PMs can make great Scrum Masters, as long as they aren’t the command-and-control kind more typical of yesteryear.
- Certainly, as the complexity and size of projects increase, organizations tend to add in those project management and release management functions that look more like the traditional PM. That said, I’m skeptical that Fred Brooks ever had today’s PM in mind when he said that the entire system needs to reside in one person’s brain, perhaps in the day when PMs were engineering managers first and foremost. Today, I don’t think that could be assumed.
- Yes, there’s a lot happening in Scrum by the scrum master and the team in general that might generally be called project management, and the fact that many of these activities are diffused in a way that makes them organic and shared is a beautiful aspect of Scrum. Project management is internalized; there are fewer explicit items to check off or “own.”
- Yes, businesses still like to have one person accountable for the project outcome, not just a team or set of teams. I’d posit that whomever you choose, as soon as you designate one person as accountable for the outcome, even if it were the custodian on that office floor, if it were a wise custodian he or she would start thinking and acting in many ways like a traditional PMI-certified project manager.
- “Funding is the last thing to become more fluid.” True! Follow the money trail, and you’re likely to run into a project manager or two along the way. “If your organization cares about budget, someone needs to be able to answer that question.” Bingo. (And by the way, I’d love to get more acquainted with organizations that don’t care about budget.)
- And here’s my favorite:
- “Human beings are messy. We need someone to help messy human beings with process.”
Absolutely. Messiness includes all the things that don’t fit within the predictable scrum box. Intuition and that “spidey sense,” the threat, the unseen opportunity, the special situation, the “this time, it’s a little different.”
If you remain unconvinced that project managers bring value to Scrum, you might be one of those who believe project managers don’t add value anywhere:
“93%, maybe 95.2%, of project managers, could disappear tomorrow to either no effect or a net gain in efficiency. (This estimate is up from 4 years ago.)”
How a PM affects efficiency is a fascinating question, certainly one that deserves some empirical testing. However, it’s not the most important question. The important question is:
Do project managers increase effectiveness?
Effectiveness is about doing the right work. Efficiency is one aspect of doing the work right. Which is more important? Well, think of it this way: If the team is super-efficient in building their widget, but it’s not the widget anyone wants, then the team has been really good at wasting resources.
The best arguments for the continued relevance and necessity of PMs hinge on the idea of effectiveness. If you work in an environment where there’s limited capacity for wasting resources, in other words, if your employer generally operates within constraints, then don’t be too quick to jettison PMs.
Project Managers at Soliant
At Soliant, we assign a project manager to every project to help our teams be more effective in delivering impactful technology solutions for our clients. They are an integral part of our project teams and ensure we build strategic applications on time, on budget, and within the planned product scope.
