The Impact Expected from Agile Alliance® Joining PMI

On 3 January 2025 the Project Management Institute (PMI) and the Agile Alliance® published an announcement that they signed an agreement on 31 December 2024 through which Agile Alliance® joined PMI, to be known as “PMI Agile Alliance” from that day on. I have no idea where the ® went but it certainly caused a lot of fuzz and noise on so-called social media. As I don’t really care and I don’t expect it to cause that much fuzz or noise on the workfloor, I wasn’t planning on joining any of the debates.

But, Frank Ray asked me on LinkedIn if I had any ‘take’ on this. Despite my initial thought “Not really”, his question was seemingly still enough to trigger me and to get me thinking anyhow (which is something to think about in itself). So, I decided I might as well jot down my thoughts quickly:

I am not involved in or associated with either organization, or their offerings. I never was. What strikes me most are the large, corporate structures that they both have in place. Too large, too corporate for me to feel comfortable with anyhow. So large, so corporate that I am not too sure about the extent to which they actually represent their practitioners and members. I obviously do know a lot of these practitioners and members.

I did find it interesting that Mike Cohn, one of the original co-founders of the Agile Alliance, shared on LinkedIn how the reason for this merger/absorption is the decline in revenues from events since the Corona crisis. Isn’t it fascinating how in general it is said that organizations need to become more ‘Agile’ in order to adapt to changing markets and business conditions? And that of all organizations, the home of Agile has been unable to do so unless giving up on its independence?

At the time of the creation of the Agile Manifesto (2001) and the subsequent establishment of the Agile Alliance (I know Ken Schwaber was also a co-founder but I have never been able to have a clear confirmation on who else was), the world of software development was “dominated by plan-driven, industrial views“^[1], “in times when failing heavy-weight, waterfall approaches were replaced by heavy-weight, waterfall-like RUP implementations“^[1]. At that time, the PMI certainly was part of the problem, and not of the way out.

The major problem was/is not the idea or concept of ‘project’ in general, but the fact that in a context of software development it typically meant a fixed-price project in which the three elements of the infamous iron triangle of software development (budget+time+scope) were fixed through upfront analysis and design phases. They were considered non-negotiable during the little time that was left for the actual development unless via change request procedures and meetings with the primary intent to rule out such changes anyhow. Such projects and all aspects of them (progress, quality, tasks, estimates, stakeholders, users, requirements, plans, deadlines, budget, alignment, integration, …) were then to be ‘managed’ by the one person with the title of “Project Manager” through “obedience to a methodology”^[1].

To be clear, again, there is nothing wrong with the idea or concept of ‘methodology’ in general, except that “in the world of software development […] ‘methodologies’ are by design composed of stringent and mandatory sequences of steps, processes and procedures, implementing predefined algorithms and executors for each step, process or procedure.“^[1] This approach was, at least implicitly, based on the idea “[…] that ‘workers’ can’t be trusted to intelligently, autonomously and creatively perform their work. Such ‘workers’ are expected to do no more than carry out pre-defined executable tasks.“^[1]

The authors of the “Manifesto for Agile Software Development” offered us a radically different world view based upon the given that software development is NOT an industrial, manufacturing or production line activity and does not even bare any resemblance to it. “A new paradigm was born, in the realm of the software industry. It is a paradigm that thrives upon heuristics and creativity, upon (restoring) the respect for the creative nature of the work and the intelligence of the ‘workers’.“^[1]

I don’t know what the PMI officially or in practice stands for these days. Like I said, I only do know a lot of their practitioners. I also know that since Agile crossed the chasm (around 2007), the institute has desperately tried to regain market share. When bashing didn’t work, they tried changing names and terms. Then they tried adding something proprietary ‘Agile’ to their offering. Then they acquired DAD (“Disciplined Agile Delivery”). But the problem in the end is that “[…] the fundamental thinking and behaviors remain the same. Essential flaws remain untouched; especially the disrespect for people and the continued treatment of creative, intelligent people as mindless ‘workers’, as ‘resources’ “^[1] that need to operate under the control and supervision of a “Project Manager”. Maybe this merger is just the next attempt showing that all previous attempts were not successful to regain dominance?

I’m not sure it will really impact the world of work that much, the work happening on the workfloor. That lack of relevance for the workfloor applies to many LinkedIn discussions as well by the way. Like I said, I’m not sure these corporate-like organizations actually represent what their practitioners practice. Agile Alliance® joining the PMI certainly doesn’t change what I have seen, have experienced, believe and will do. It does not impact a vast majority of the people, teams and organizations that I work with either.

And even if they wanted to, too much has happened and changed for the better for even the PMI to turn back the clock.

Challenging the status quo of the industrial paradigm has already induced many advancements and has helped many organizations make the shift from predictive to empirical management. In many organizations the understanding has been restored that their work is actually a creative and complex activity performed by people, not robots. Many organizations now focus on products and services rather than temporary project constructs.^[1]

Rather than “obedience to a methodology“^[1] with to the promise to deliver “exact, in the sense of precisely predicted, output or scope against time and budget“^[1], “[…] ‘Value’ is the answer to user, market and business demands and the overall measure of progress and success.“^[1] And besides offering a stable basis in our ever-changing, turbulent enterprise, business and market circumstances, ‘product’ also is “the vehicle to deliver value.“^[1] “Remember that ‘product’ defines the scope of your Scrum and that ‘product’ can be a tangible or intangible product, service, device or experience.“^[1]

Organizing work in projects might still be fine, given what I define as a ‘project’. Going back to fixed-price projects is not the viable, future-proof way of working. The organizations that still have them will undoubtedly sooner or later move away from them.

In the complex, creative and highly unpredictable worlds that Scrum helps us to navigate, a promise to deliver exact, in the sense of precisely predicted, output or scope against time and budget is simply not possible, not even for a Sprint (because if that was the case we wouldn’t need a Daily Scrum). Too many of the variables that influence the work are unknown or behave in unpredictable ways, even within a Sprint.^[1]

If we thought “Project Manager” was an important role that cannot be skipped, it would have been part of the Scrum framework.

In my classes and workshops I offer students a list of all the activities that Project Managers were responsible for and I ask them to match these against the accountabilities as defined in Scrum.

Guess what? There is a general agreement that these tasks can and are better managed by and within the self-organizing Scrum collective.

If teams are only instructed to carry out executable tasks and their capacity in hours is pre-filled with such tasks, team members suffer from a narrowed mind. They are restricted from looking and thinking beyond the instructions, even if reality or experience shows that the prescribed solution is difficult to achieve or is suboptimal. They lose openness for better solutions, solutions that are not dictated but are a better answer to the actual demand and objectives given changes, proven findings and current circumstances. Their only focus is to produce what was instructed without considering conflicting ideas and options, without dealing with this natural instability typical of product development and technological discovery. The industrial mode to direct people as if they are robots impedes capitalizing on the collective intelligence of a team, thereby limiting upfront their work results to mediocre levels.^[1]

[1] All quotes are from my book “Scrum – A Pocket Guide”, 2013-2024.