In industry forums and academia there is a notion of agile project management. I think this is harmful to the Agile movement. Our argument is based on theoretical, operational, people and culture, and capacity management objections. For the purpose of this article our scope is the development of software products and not other types of projects. Also we will use Scrum as an example of an Agile methodology and our Project Management framework will be based on the Project Management Body of Knowledge (PMI).

Theoretical Objection

Project Management implies a start and end date, while Scrum in contrast focuses on sustaining a product.

The Project Management Institute (PMI) defines a project as “temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

The Scrum guide defines Scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” The guide defines the purpose of Scrum as: “a framework for developing and sustaining complex products”.

Operational Objection

In practice I have seldom seen a software product being developed with no ongoing maintenance after the project has finished. The modern trend as espoused by the DevOps movement is that the team that builds the software also runs the software. In the past we normally developed a software project using a project management methodology and then an operations team took over the maintenance and operation of it. Traditional IT models divide implementation and support into separate teams, sometimes referred to as “build” and “run” or “development” and “support”.

The results of this divide is to isolate the people building from any problems they create. It leaves the people who run the system with little ability to make meaningful improvements as they discover problems. Because the most valuable learning opportunities come from how a system is used in production, this dev/ops divide limits continuous improvement. This topic has been discussed in more detail here.

From a pure project management perspective, it would be very hard to do resource allocation using the same team to do the “project” work as well as the production as the project schedule is rather rigid on start and end dates. The Scrum approach would be to use the same backlog for features as well as system enhancement and production issues. Resource allocation is then far more dynamic.

People and Culture

Project Management implies a project manager. This is not the case in terms of Scrum which only recognize three roles: scrum master, developer and product owner. The resourcing assumptions in project management are very different to that of a Scrum team. They key question is: what is the role of a Project Manager in Scrum? It does not exist.

Maybe a more contentious issue is that of culture. The PMI states the role of a Project Manager as: “change agents: they make project goals their own and use their skills and expertise to inspire a sense of shared purpose within the project team.” Implied here is that purpose comes from the Project Manager. My reading here gives me a sense of top down control or in an weaker sense top down inspiration.

Scrum in contrast is more focused on self-organisation. As the Scrum Guide states: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team”. This gives me a different cultural feel to that documented by the PMI.

Capacity

More and more organisations are moving towards a fixed capacity model. As an example from a portfolio or investment perspective the organisation might decide they are only allocating a certain budget to a department or team. The product owner then needs to decide how to prioritise the work to fit the agreed capacity budget. This is a useful approach as it forces prioritisation. It doesn’t exclude more money being made available in exceptional business cases.

Even though fixed capacity resourcing is not inherent in Agile or general Project Management it affects the two methodologies. From my perspective it is easier to prioritise small incremental developments using the daily Scrum and Product Scrum processes than the Project Management process that is predicated on more formal business cases and longer development cycles.

It is from a practical perspective easier to manage to fixed capacity using Scrum than traditional project management.

A possible critique

A concern can be raised that I am comparing Scrum with Project Management rather than Agile with Project Management. This is a valid but not a practical concern. The Agile Manifesto is too conceptual to allow comparison. What I see in practice is mostly Scrum as the lens to look at Agile. The Agile at scale methodologies like SAFe and LeSS are also build on variations on the Scrum construct.

Conclusion

Based on the argument above, and it is probably not exhaustive, I think that that there could be harm done to the Agile movement by forcing it into a project management framework. The Agile movement can be strengthened by using project management techniques but Agile should not be adapted into the Project Management discipline.