Why 'Agile project management' does not exist

Alright, let's dive in!

I know... you may think it's fundamentally incorrect to state that Agile project management doesn't exist, right?

You may say...

'Agile project management is found in so many places!' ... or ... 'Even Atlassian themselves have a definition page on it!'.

Sure.

And 'Even Product Plan says':

"Scrum is a byproduct of Lean and eXtreme Programming. It is one particular project management approach but is by no means a set requirement of adopting Agile."

So, the confusion is widespread, isn't it? There are even books on this thing, whatsoever. I think they are all wrong, pretty much. Or am I? Let's explore this in more detail.

Realities of Agile and Project Management

In the evolving landscape of software and technology, Agile and Scrum had some traction and a good run - but let's be honest. Most organisations (people in tech especially) failed to take advantage of the core ideas, and thinking they can somehow marry Agile and Projects, led to some mass disillusion, now which no one is even questioning any more.

There are many reasons and root causes for this, which I will touch upon quickly:

• 99.8% of people (according to my empirical data) holding a Scrum Master certificate cannot recall anything from the scrum framework, neither ever read the Agile Manifesto, or understood it. They have no practical knowledge of what either means, or how to use it. I always recommend everyone to re-read these lovely guides every 6-12 months, so you could go back and test your experiences and think about practical implementation of the guide. Without working knowledge, the blind is leading the blind, literally.
• Vast majority of people in leadership and middle-management roles have no time, and more worrying, no desire to read and learn. This starts the moment someone lands in their first managerial or leadership role. Rest of their career they focus on perfecting their skills to manage relationships, stakeholder demand, their line manager, doing self-PR, and satisfying everyone around them. Only when they reach the top do they maybe pick up their first book on leadership, management, and effective ways to lead or experiment with leading people - which really should have been the first thing, not the last, right?
• Most schools teach nothing about the practical nature of management. The current schooling system is mostly a brain training exercise, with over 90% of what was once learned being forgotten. If you go through a Scrum Master certification and 'training', you subject yourself to the same method of learning. When you re-enter the corporate's day-to-day, you are immediately consumed by the processes put in place by those who either have never had any training or knowledge of Agile philosophies and what they mean in practice, or already forgot what these were. This results in you very quickly forgetting the basics, unable to implement the ideas, descending some practices into meaningless ceremonies while one day realising all you do is using buzzwords. Project management terms effectively being made sound cool, and relabeled as 'Agile'.
• Tech organisations are heavy in engineering, thus, engineers. I love engineers and working with them, and I like to do as much engineering in my free time or workplace as I can as well. So no offence to any of my friends, but engineers do follow different thought-processes than what is required by management. Often what I notice is some terms are picked up from the 'outside world' (yes, for engineering teams often the corporate as a whole is simply a different planet), and try to work with these concepts. I think engineers involvement in Agile methods are necessary, but often they would be the ones misquoting and misusing what agile is and means, and have no interest in learning about methods and ideas surrounding management, which is natural - they get excited about new tech, not effectiveness of teams.

So there are these root causes, but what are the outcomes? Where this general vagueness of ideas and knowledge, and honestly widespread confusion of methods takes us?

So one place we arrive at, is the idea that agile frameworks are universal methodologies suitable for all types of work.

I think this perception is rife with misconceptions. If we clarify the distinct roles of Agile/Scrum versus traditional project management, and highlight the inherent challenges of applying Agile/Scrum to project management, we can understand how that view and its byproducts are fundamentally wrong and plague the everyday of people keen to make a difference in tech businesses.

There is no such thing as 'Agile project management'

I did manage a lot of projects throughout my life, and I can tell you it is a great and satisfying experience for everyone, if done following a methodology like defined by PMI or something similar. I have an expired PMP certification which I didn't feel renewing as I now embrace the Agile methods and less keen on practicing project management, but similar to ITIL, I think there are some great fundamentals there you can utilize also in other disciplines.

According to the PMBOK Guide, "Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements" (PMBOK Guide, PMI). This involves structured processes, with detailed planning, which clearly guides you to reach a pretty much fixed end state. An important element of project management, is its robust impact analysis, formal change requests, and the requirement to have a Change Control Board (CCB).

If you have none or just a little bit of these, you are essentially not doing project management. I often see people thinking they do 'project management' without formal structure and change management processes like its defined in the PMI guide, which in real life looks very much like a person basically sending stakeholders RAG statuses of a sinking ship. By a 'sinking ship', I mean a continuous stream of 'things are happening and everything is late'. It's kind of hilarious.

So in essence, project management requires thorough processes and formal change management: but how does Scrum and Agile methodologies in contrast handle change?

Agile principles emphasise individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan (Agile Manifesto). These principles inherently conflict with the structured, plan-driven approach of traditional project management.

Following these principles in the Scrum guide, we can see how it intends to manage change:

• "No changes are made that would endanger the Sprint Goal
• Those wanting to change the Product Backlog can do so by trying to convince the Product Owner
• Scrum events are designed to provoke change."

As per the last point, Scrum was designed for creating change not avoiding it, neither it requires heavily managing risks that could lead to change. Which then fundamentally makes Scrum a project management anti-pattern. The generally fluid requirements based on learning, is also opposite of what the definition of project is.

Matter of fact, if you read the Scrum Guide, it has only one mention of the word 'project':

"Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project."

And, that's it! No other mention of the word project.

So Scrum emphasises iterative development, flexibility, and continuous improvement. This fundamental difference means that as traditionally defined by PMI, Scrum and Agile does not adhere to the rigid structures and change management required and inherent in project management.

This means that the two methods do differ, and an interesting conclusion arises:

If you apply an 'Agile method' to managing a project, you are effectively not managing the project, by definition. Therefore, there is no such thing as 'Agile project management'.

If this sounds too technical and definition based, or you get confused by the logical gap in 'Agile project management', here is an analogy, and a practical example to wrap your head around this.

Think of project management as a detailed plan to navigate the entire course of a long-distance race that has a clear start and finish line. Scrum, on the other hand, is more like a series of short sprints where in the race the route can change based on immediate feedback, and there is general descriptions of places you need to end up throughout the race, but there is no mention of 'finish line'. In the first approach, to complete the race, it requires a pretty much fixed plan, while in the second approach, you change direction based on real-time (user) input, and simply keep racing.

# On the general absence of 'user' in the Scrum guide, I'll come to in another article.

Illustrating this with an example. Let's say there is a construction project for a new skyscraper, and investors (the stakeholders) want the 'tallest building in the world'. It would host businesses and is built for younger, high-gross individuals. This project to deliver as-is, requires a fixed scope, detailed blueprints, and precise scheduling from start to finish. If you were to apply agile to building it, with its iterative and flexible approach, you would pretty much end up with a building, which may have towers, an innovative hexagon structure, a brand new cooling system, and all tenants would be very impressed by it.

There would only be a couple of issues though:

• it likely wouldn't be a skyscraper, and also wouldn't be the tallest building in the world,
• the ventilation system implemented wouldn't be the one that was in the pre-agreed contract with a supplier,
• the outcome would satisfy the tenants, but pretty much upset and conflict the team delivering it with the stakeholders.

So, with using 'Agile' and upsetting the stakeholders, there are two things that could happen:

• the team would either jeopardise the Agile approach, and act as they are doing 'Agile', but really execute what was put down on paper and they are told exactly, or
• the team sticking to delivering in an Agile fashion would get fired by the investors.

Sounds familiar?

So then what

As much as we think labelling things don’t matter, they do. Naming something, carries meaning. I am pretty sure companies like Atlassian even built some of their product strategy around the misconception of 'Agile project management'.

Down the line, these misconceptions can create misguided internal products, and it hurts the people seeking to work with high velocity and those who want to make progress. Getting from A to B in large corporate environments, and navigating its complex dependencies is already difficult. Implementing project vehicles like Value Streams and Release Trains and other nonsensical concepts, and thinking projects will be able to quickly deliver meaningful change within any of your technology-based products or services, is delusional and often makes work more pain than join.

So then what? I tell you. Stop thinking that sprinkling the word 'Agile' will:

• fix your rigid structures,
• change your people who are unwilling to embrace change and innovation while hiding behind change management,
• improve your very high inefficiencies and dependency hell,
• or help you better meet your users' needs.

And, stop using the term Agile project management - it is a misconception.

# the end