The Project Management Institute is a 50-year-old organization dedicated to the practice of project, program, and portfolio management. Their mission as stated on their website is to “… work on your behalf to advance the project management profession worldwide.”
The group has also authored the PMBOK (Project Management Body of Knowledge). It’s the bible for project management. Seriously, that sucker is 756 pages long!
As the authority on project management, the PMI offers 8 different certifications. One of these credentials is the PMI-ACP (Agile Certified Practitioner).
Full Disclosure: I have the fancy credentials. Along with being a CSM, CSPO, and CSP, I am also a PMP and PMI-ACP certified.
I have nothing against the PMI as an authority and promoter of project management best practices. The group provides invaluable information to and for project/program/portfolio managers. The certification programs are very well done in terms of preparation materials, testing relevant skills, and experience requirements. The PMI is very, very good at project management.
PMI Entered the Agile Space for the Wrong Reasons
The PMI-ACP is a money play. Pure and simple. The PMI saw the ever-increasing adoption of agile frameworks, particularly Scrum, and wanted to get in on the action. More certifications, more training, more members equal more money. Yes, even non-profits need to make money.
The absence of a project manager role in Scrum also causes concern for the PMI. As Scrum continues to be adapted over traditional waterfall methods, what are all the PMP’s going to do as project manager roles are replaced with Scrum roles? The risk to the PMP revenue stream is huge.
According to the 2018 PMI Annual Report, $239 million USD were collected worldwide for membership fees, certifications, and book sales. The report also boasts more than 6 million copies of the PMBOK in circulation. With the PMP being their flagship product, the PMI should be worried.
PMI-ACP — A Unicorn is Born
Just to make sure we’re all on the same page, there is no project manager role in Scrum. The “agile project manager” role that emerged from the PMI-ACP certification is a unicorn.
In an organization practicing Scrum, the functions of a traditional PM are spread between the Scrum Master, the Product Owner, and the Development Team. And some traditional PM functions are simply no longer necessary.
An agile project manager role causes confusion and conflict within organizations trying to transition to a Scrum framework. No one is quite clear on who is responsible for what.
Really. I’m mean seriously. One exam and the newly certified person is supposed to have a solid understanding of five different agile frameworks? Enough said.
If that doesn’t make you cry agile tears, take a look at the requirements to sit for the PMP vs the PMI-ACP:
I have three Scrum certifications, been in formal classroom training, attended multi-day Scrum or Agile conferences, and have spent countless hours studying Scrum. I was part of the leadership team responsible for a successful transition from waterfall to Scrum. I have 20 years’ experience in software product development, 10 years in real-world Scrum environments. And I have so much more to learn. After all that, I’m a Scrum neophyte.
Scrum requires experienced professionals. The Scrum Master and Product Owner roles are not entry-level roles to be filled by high school graduates with little experience.
The qualifications to become PMI-ACP certified show that even the PMI isn’t taking the certification seriously. The PMI-ACP was an ill-conceived reaction to a sudden shift in market demand.
Foundational Conflicts Between the PMI and Scrum
The conflicts between project management principles and Scrum go far beyond process, roles, and semantics. The principles taught and evangelized by the PMI explicitly undermine the very principles that make Scrum effective. Straddling the fence between the two worlds causes much of the failure of Scrum implementations in organizations today.
Let’s look at the first two stages of PMI project management and see where we find clashing principles.
1Conception & Initiation
Step one in PMI-style project management is to create a project charter. Often, the executive sponsor of the project physically or digitally signs this document. This is an executed contract intended to lock in the objectives on day one of the project.
Conflict: This violates two of the four values in the Agile Manifesto:
Customer collaboration over contract negotiation.
Just the psychology of signing the project charter immediately creates a division between stakeholders and the project execution team. It’s us against them.
Responding to change over following a plan.
Keep in mind, many projects span months and years. To think the project objectives would not evolve during this time is naïve and/or irresponsible. Particularly in the field of software products, responding to competitors and new technologies in a timely manner is critical.
2Definition & Planning
Or, as I call it “How to Set Your Team Up for Failure from the Beginning.” Please note the vocabulary in the name of the field “software development.” Development is the creation of new things; it’s inherently exploratory.
Conflict: Requiring full project definition up front violates the Scrum principle of empirical process control. It defies the value of responding to change, which will also likely lead to a breach of the principle of establishing a sustainable development pace. The team will inevitably fall behind schedule and be asked to donate their nights and weekends for the last month of the project to “catch up.”
Asking a development team to estimate the effort in something they’ve never done just doesn’t make sense. Add to that the timing of this effort — not one line of code has been written but developers are expected to understand every nuance of the project and accurately estimate it. The benefits of iterative development will never be recognized.
I could continue going through stages 3, 4, and 5, but you get the point. The very beginning of a traditional project management approach obliterates the basic foundation on which Scrum teams are built. How can you possibly continue on from that and expect to be successful?
Where Does a PMO Fit in an Agile Organization?
I really wish I had a great answer. I don’t. I’ve often wondered if an SMO (Scrum Management Organization) wouldn’t be a better fit. While I hate that name (it’s also taken: Service Management Organization), I do like the idea of a single organization within a company evangelizing Scrum and the values and principles outlined in the Agile Manifesto, ensuring proper training is made available and helping perfect the execution of Scrum practices.
Ideally, the PMI and a Scrum authority organization would come together and figure out how these two bodies can align in a spirit of support rather than conflict. I think there’s room for both.
Regardless, the current proliferation of PMI-ACP certifications and “agile project managers” put us on a terrible path for future Scrum teams. The best we can do right now is to educate company leaders on the critical differences between the PMBOK, Scrum practices, and the Agile Manifesto. And, to those hiring for or applying to “agile project manager” positions — buyer beware.