A Self-Contradicting Job Title
Though a free-lancer these days, I keep a few job alerts running just in case something fitting my exacting requirements pops up. Plus, it is a way to monitor what is happening in the real world of Agile versus the theoretical one of blogs and books. One of the biggest indicators that the doers lag the thinkers is the continuing appearance of the job title “Agile project manager.” This is an oxymoron, a phrase that contradicts itself. In a truly Agile organization, all of the tasks of a project manager:
- Are handled by the process or tools
- Fall to one of the Agile roles like Product Owner
- Are left to the team’s self-organization, or
- Simply disappear.
Before you accuse me of being an Agile ideologue, be aware that I maintain my PMP and would recommend waterfall for certain types of projects. Project management is absolutely crucial; if you aren’t Agile, you need PMs. My argument is that Agile methods—or more specifically Scrum, almost always mentioned in these ads—provide all that is needed.
Start with the fact that much of the PM role, as practiced, centers on trying to make and meet scope, budget, and schedule estimates. I’ve already detailed why this is overemphasized even in waterfall for R&D and NPD[1] projects, and irrelevant in Agile (see “Melt Down the Agile Triangle”). When the job description says a candidate needs a track record of meeting those estimates, the job is not Agile.
Managing the PM Tasks
Let us repair to the latest Project Management Body of Knowledge (PMBOK)[2] for further evidence. I’ll compare the categories of tasks a project manager does, quoted from it, to my approach to scaled Scrum.
“Project Scope Management. Includes the processes required to ensure the project includes all the work required, and only the work required, to complete the project successfully.” In Scrum the scope is the Product Backlog, a listing of the currently known requirements in rank order. The Product Owner (PO) creates this, either with, or as the representative of, the customer(s). Other requirements, like technical work that has to be done to meet the business requirements, the team itself creates as part of self-organization. The customer ensures “only the work required” is done, by approving the top of the backlog through the PO before every Planning Ceremony. There is no “scope creep,” because we welcome changes.
“Project Schedule Management. Includes the processes required to manage the timely completion of the project.” A customer as involved as called for in the Agile Manifesto is effectively in charge of “timely completion.” The team works as efficiently as possible to deliver as much finished work as it can in the course of each sprint without overwork. Eventually this creates a velocity figure of how many stories or story points the team usually delivers. If the project team(s) deliver 11 stories per sprint, and the must-have stories number 54, nobody needs a PM to tell them those will likely be delivered in five sprints. If the customer adds scope, they can do the math themselves to determine the impact, thus automatically approving a schedule and cost change.
“Project Cost Management. Includes the processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so the project can be completed within the approved budget.” This, too, becomes simple math. Say the team costs $12,000 per week and is using three-week sprints. Continuing the prior example, five sprints equals 15 weeks and costs $180,000. If that’s more than the customer wants to spend, they know they must remove 11 stories for each $36,000 they want to remove.
Since in Agile late changes are embraced, and plans and documentation are de-emphasized, we don’t waste time on long-term schedule and cost planning. Customer contracts are based on periodic costs instead (see “Agile Contracts”). Regarding “financing” and “funding,” in every firm I’ve served, the project sponsor handled these, not the PM.
“Project Quality Management. Includes the processes for incorporating the organization’s quality policy regarding planning, managing, and controlling project and product quality requirements, in order to meet stakeholders’ expectations.” One of the Manifesto principles states, “The best architectures, requirements, and designs emerge from self-organizing teams,” while another calls for, “Continuous attention to technical excellence and good design…” The responsibility for quality thus is delegated to the team. The customer and PO will include specific quality requirements in related epics or stories just as a PM would in work packages. The team needs to be aware of corporate or certification quality standards, but a PM is rarely the technical subject-matter expert on those.
“Project Resource Management. Includes the processes to identify, acquire, and manage the resources needed for the successful completion of the project.” Truly self-organizing teams by definition assign themselves to work. These should have stable membership, as recommended by most Agile sources I’ve read (and teamwork research). When a new project comes up, the project sponsor and PO create its initial epics with the customer, and in larger organizations they negotiate the project priority with their peers and stakeholders. When a team finishes a project, it goes to the list and takes epics from the top-ranked project for which it has the skills, perhaps negotiating with another team to fill in skill gaps. If more gaps exist, a self-organizing team would be allowed to set aside time for training and/or do its own hiring using the same organizational processes a PM would.
“Project Communications Management. Includes the processes required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and ultimate disposition of project information.” Pay for a full-featured Agile work management package like Agile Central or Version One and, if needed, a document-sharing tool. The Scrum ceremonies take care of almost everything else in this category, including specific communications that can become tasks under a user story. As for “planning,” a “Communications Plan” can be created by the team (use link for instructions and template).
“Project Risk Management. Includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project.” Evidence suggests high-uncertainty projects fitting Agile benefit little from this.[3] I train teams to identify risks only during epic and story grooming. They get into the habit of asking themselves two questions for each: What could prevent this story (or epic) from getting completed within one sprint (release)? And what could we blow up if we do this story successfully? Any answers are managed easily by the team using PM practices (see “Projects are a Risky Business“).
Because we don’t care about meeting scope, schedule, and cost estimates, risks related to those disappear.
“Project Procurement Management. Includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team.” In almost every project I dealt with, these processes were managed by a procurement person and/or standard corporate procedures, and senior team members had deep experience using them. I teach teams needing to go through the procurement or vendor system to add those actions, such as creating a Purchase Order, to sprints as stories or tasks.
“Project Stakeholder Management. Includes the processes required to identify the people, groups, or organizations that could impact or be impacted by the project, to analyze stakeholder expectations and their impact on the project, and to develop appropriate management strategies for effectively engaging stakeholders in project decisions and execution.” My Agile transformation process identifies all potentially affected stakeholders and incorporates them into the change process. Existing Agile teams can also do so by creating a Communications Plan. Stakeholders are invited to Demonstration Ceremonies at least, and in my Full Scale agile™ (FuSca™), can observe anything except Retrospectives. They can be given access to the Agile tracker to get their own status updates, and in FuSca can become “Agile Liaisons,” treated as additional customers. The teams get into the habit of interacting with them proactively for a very simple reason: If a Liaison disapproves a story/epic relevant to their area, it cannot be accepted.
“Project Integration Management. Includes the processes and activities to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups” (this is listed first in the PMBOK). Since all of those are covered by the same tools, roles, and processes, they are automatically integrated.
Creating the PM Outputs
Taking an alternate tack, we can look at the most-common project artifacts to compare who does them or the covered work. In practice, waterfall PMs are not always responsible for some of these, and many are omitted, but we’ll assume a high level of PM documentation:
| Artifact | Traditional PM | Agile |
| Project Charter | PM or sponsor | PO or sponsor |
| Project Scope | Product manager, business analyst, PM | PO, team |
| Cost Estimate Schedule Estimate |
PM | None (per-sprint costs are provided to customers) |
| Scope Management Plan Cost Management Plan Schedule Management Plan |
PM | None (scope, cost, and schedule can be updated each sprint) |
| Resource Plan | PM | Team self-assignment and hiring |
| Risk Register Risk Management Plan |
PM | None (team manages on epic/story basis) |
| Procurement Management Plan | PM (based on organizational procedures) | None (team uses organizational procedures) |
| Quality Management Plan | PM (with relevant stakeholders) | Team (with relevant stakeholders) |
| Communications Plan Stakeholder Management Plan |
PM | Team, process (grooming and ceremonies), tracking and documentation tools |
Getting Honest about the Job
What’s left for a PM to do? Nothing, in a truly Agile organization. Diehards will propose details and edge cases left out of this post to keep it short, but I have taught self-directed teams to cover everything. Where executives are stuck in waterfall project governance, they will require all kinds of unnecessary data, so maybe you need a project administrator to translate the Agile information. But that person isn’t being Agile or a project manager.
So, hiring managers, get real: If you are “being Agile,” you don’t need a PM. Otherwise, stop fooling yourselves and drop “Agile” from the title, because you aren’t.
Please share this post at the bottom of the page.
[1] “Research and development” and “new product development.”
[2] Project Management Institute (2017), A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Sixth Edition. Project Management Institute: Newton Square, PA.
[3] Sommer, Svenja C., Christoph H. Loch, and Jing Dong. “Managing Complexity and Unforeseeable Uncertainty in Startup Companies: An Empirical Study.” Organization Science 20, no. 1 (February 2009): 118–33. https://doi.org/10.1287/orsc.1080.0369.