by Shama Bole, Sr. Agile Consultant and Client Service Director
What grew as a creeping sort of dissonance over the past few years, in my role as project manager using Agile methodologies, has now coalesced into full blown discomfort around the question of whether the Project Management Institute (PMI) can relate to Agile. Recent readings, events and classes have featured the PMI attempting to play a central role in herding Agile into the fold of PMI-sanctioned methodologies. This article is based on my understanding of the PMI’s stance as viewed through these classes and readings. The PMI’s pitch is that Agile does not address ‘macro-level’ challenges for project management, and that this gap is covered by the PMI. The PMI claims that every Agile framework is missing two critical elements: sophisticated scheduling tools and account cost management. My take on this is that the PMI is struggling with a methodology that is outside of its paradigm and understanding.
PMI v Agile
Micro v Macro: As regards macro – or enterprise – level solutioning I’m not convinced that there are gaps that Agile methodology fails to tackle. Rather, it is a failure on the part of organisations like the PMO and Finance and HR that fail to support a changing milieu, whether in the realm of budgeting and financing of Agile projects or performance management by rewarding individual efforts rather than teams. The PMI takes the same approach as that of micro-level execution and escalates it up to the executive level, substituting – at random – ‘executive management’ for ‘delivery team’. I do not see any clear vision or pathway in the PMI’s approach to Agile strategic planning, portfolio management and product/program management. In fact, my various readings on Agile have provided lucid options for implementing Agile at various levels. The following sentence from a PMI training handbook may explain my bafflement (and the gist of what inspired this article): “The hardest part for technical professionals being Executives is to make decisions with incomplete data.” The emphases are not mine; they are the author’s. Is the PMI serving a niche for executives who also tend to be technical professionals? What then is their role on the management team? Decision making is frequently made with incomplete data; that is where Agile can help – to construct more realistic estimates for decision makers.
I was recently chatting with an Agilist who is a PMP (among other certifications) – and a very seasoned project manager – and also has a through understanding of Agile; he works primarily with Kanban and SAFe (Scaled Agile Framework). SAFe in fact does provide a framework for micro-to-macro scaling of Agile for project-portfolio-program management. But the PMI has deemed that SAFe inadequately meets this enterprise level need. I asked him what he thought of this claim and he laughed and said “It’s sour grapes; the PMI wishes it had gotten there first.”
Lean v Bloated: Agile is about business value and – in line with Lean – about eliminating waste. The PMI is bloated with self-referencing jargon that features outdated constructs and is, I believe, incapable of seeing past that paradigm. Case in point – I recently read literature where the iron triangle, no longer relevant in an Agile world, transmuted into some sort of ‘iron hexagon’ with quality, risk and resources thrown in along with the traditional areas of scope, cost and schedule. Not only does that idea lack elegance but it is a poor attempt to theorise – and reactively – in the face of new facts. As someone who has engaged in reading both sets of doctrines, I see Agile as self-deprecatory and aiming for simplicity, even when dealing with complex software projects.
Art v Science: Agile is simple to understand but can be problematic to implement because it is more of an art than science. I believe the same is true of project management; PMs who are skeptical of this are usually the ones who find solace in espousing the “hard math” and prescriptive methodology espoused by the PMI. Something like Estimation, which is a useful tool in Scrum, is something that throws many traditional PMs for a loop, especially the hard-core PMI advocates. For instance, the PMI sees Estimation as an exercise conducted with executives, not the delivery team. How would those estimates be meaningful, let alone something management could trust? The same holds for perceived percentile increases in productivity or ROI by using one methodology versus another. Every project, project team, approach and execution is different, which renders comparison and quantification a dubious exercise. The PMI touts statements like “Precision <> Accuracy”, harbouring the delusion that one can actually aspire to either metric in terms of project management methodologies. Agile understands the fallacy of attempting to be precise about something that is inherently inaccurate; the PMI believes that one can overcome the inexactitude of the estimation process with sufficient investment in precision.
I recently attended a one-day class on “Advanced Agile – Enterprise Practices” and it cemented my belief that you can either be Agile, or you can believe project management is a science.
Executive Management v Team Delivery: Typically, in Agile, the Product Owner provides a vision and the delivery team takes that vision and deconstructs that into themes and then user stories. The PMI has the executive team doing this deconstructing, taking into account the value of Minimum Marketable Features (MMF), which would be rather ludicrous unless they were all SMEs, since only technical experts would be able to speak at a detailed level as to the effort involved in creating MMFs. This is purportedly done under the aegis of Strategic Planning to create a Product Roadmap. Agile estimation is not a planning process for AOP (Annual Operating Plan); this would be a misapplication of a development tool. The PMI further talks about “spec’ing” out these themes, which is not the language or methodology of Agile and proves it is missing the point. This confusion or propensity to interchange executive teams with delivery teams is another hallmark of the PMI’s obtuseness when it comes Agile execution.
‘Command & Control’ v Self-Directed: Traditional PM methodologies focus on controlling their projects to the nth level of detail. For example, they place great importance on a scheduling tool that can “scientifically” measure expected duration for a given set of tasks. This is predicated on a sort of ‘build it and they will come’ principle in that if we follow all the rules of traditional project management for scheduling and measuring earned value and so on, the project will be a success. This may in fact be true of certain types of projects – large engineering and defence projects, for example, where up-front planning helps map out complicated processes and dependencies. The PMI regards control as the Holy Grail of project management. But, control is often illusory. Working Agile gives more timely and accurate insight into project progress because the process embodies transparency. It is also predicated on the team “pulling” work rather than the project manager imposing scope, which makes it more sustainable and a more honest as well as dynamic reflection of the team’s capabilities.
Formalised v Spontaneous: Communication and planning in Agile projects are tailored to meet existing situational needs. Just in Time, Last Responsible Moment, Face-to-Face instead of document handoffs… all these are alien to the prescriptive nature of PMI philosophy. As I mentioned earlier, the PMI claims that every Agile framework is missing two critical elements: sophisticated scheduling tools and account cost management. I disagree on the need for the first and the lack of the second. In Scrum, for example, product backlog prioritisation is performed iteratively, and that is but one of the reasons that Agile makes monetary project investment more valuable and trackable.
Agile empowers the team; PMI methodology reassures executive management that the project is regulated to within an inch of its life. Control – or the illusion thereof – is critical.
People v Process: Agile invests in developing individuals. Agile coaches are trained to maximize potential in team members; the PMI has no articulated interest in fostering personal development in any of the project team. The main goal is achieving what the project set out to do, within time and budget. Becoming a servant leader and allowing the team to take front and centre is a major shift from the PMI viewpoint.
Fanciful though it sounds, Agile seems to play the role of David to PMI’s Goliath. Given that Agile approaches are becoming ubiquitous, this may not hold true for long. But it feels like the PMI is fighting a rearguard offensive, to stay relevant.
In Conclusion
Is a meeting of the minds possible?Symbiosis, not hierarchy: I believe a meeting of the minds is possible, that Agile and PMI can have a symbiotic relationship without the presumption of a hierarchy. Some types of projects do lend themselves to a high degree of control and planning, and what the PMI offers provides a useful arsenal to a project manager in dealings with skittish management. In the end, the main goal is still to deliver value to business – does being a servant-leader render us any less useful? I don’t believe so. The PMI needs to acknowledge that Agile methodologies do a superior job at projects where requirements are changing; there is not much, if anything, that the PMI can contribute to the Agile body of knowledge. Rather than try to claim a stake in an area that has already been well-mined, the PMI would be better served – and better serve its adherents – by standing by the principles that work so well for specific kinds of endeavours.
