Ever since the term ‘Agile project management’ has come into use, there has been an ongoing discussion about the relationship of established project management methods (PMM) – such as PRINCE 2 or PMI – to Scrum, being representative of the Agile project management method.

This article is about project management methodology, so it is a small contribution to the teachings of project management methods (PMM).

Scrum is not a project management method

I do not ask myself how the relationship between Scrum and e.g. PRINCE 2 & Co is structured ( i. e., what is the relationship between Scrum and traditional PMM), but rather how Scrum is supposed to be a PMM at all (because of “Agile project management”). Why is this important?

Companies often feel compelled to choose a specific method when handling projects. Frequently this is also a result of corporate compliance guidelines. Companies who would like to use Scrum have to make a choice and throw their PRINCE 2 or HERMES (if you are in Switzerland) over board – or change their compliance guidelines.

For large corporations, such an undertaking is anything but a walk in the park; it is more like a pilgrimage to Santiago de Compostela. But what if this pilgrimage does not have to be done at all? What if Scrum is not a PMM and therefore cannot contradict other PMMs?

The point here, however, is not to use a trick to show companies a way out of the PMM dilemma, but to uncover a fundamental misunderstanding when evaluating Scrum as an Agile PMM.

The well intentioned replacement of a PMM by Scrum in the project usually results in both being damaged: the project, in which important things are not managed and which is not successful, and Scrum, which as PMM of the many failed projects falls into disrepute.

Scrum in the Project, not as Project

I see Scrum as a software implementation method (SIM), although Scrum can possibly be transferred to other industries. Basically, I would say that Scrum can be applied to all processes that are basically capable of commitment and completion.

As a software implementation method (SIM), Scrum operates within a project, not instead of the project. In simplified terms, there are many tasks in a project apart from the processing of a product backlog that contribute significantly to the success of the project, but are not covered by Scrum.

Some of them start when the project is already initialized, but the decision which SIM (Scrum or Waterfall) is to be used has not yet been made. This is a project management task.

The composition of the teams, the initial budgeting, the monitoring of compliance guidelines, the project marketing, large parts of the project controlling, which go beyond the analysis of burndown charts, also fall within the scope of the PMM and not the SIM. This is not to be seen as a reduction of the team’ s self-organization, which is required in Scrum, but merely determines the scope or the reach of this self-organization.

What a project has to do for Scrum

Scrum only knows the roles Product Owner, Scrum Master and Dev Team and is therefore highly specialized in the creation and processing of a Product Backlog.

This specialization is very effectively designed for exactly this task and fails when things have to be done that do not fit into this scheme.

In general, things such as disputes with works councils about the admissibility of time tracking or the assignment of tasks to people, software licenses that have suddenly expired and their replacement, are perceived by Scrum as impediments that disrupt the core process and that have to be solved externally.

This is what the project or organization is for.

The project protects the implementation as its “holy of holies”, as the true element of value creation.

And this project uses a PMM and forms the framework in which Scrum operates.

The challenge of the PMM is to adapt to the conditions of the SIM. You will have to, no matter if you implement with Waterfall or Scrum. Each SIM has its own special features.

Nobody would ever think of considering Waterfall as a PMM. We should not make this mistake with Scrum.

Of project managers and team leaders

To all project managers who already saw themselves downgraded to Scrum Master or who thought they were redundant, I guess I just saved your job with this view. I accept donations for this gladly and thankfully ;).

With team leaders, however, the situation is quite different if you are not currently working in a matrix organization.

Scrum deliberately reduces bureaucracy and hierarchies in the implementation process, eliminates micro-management and replaces it with a very effective self-organization of cross-functional teams that can function according to different rules than the project structure that has been organized around it. It can even produce other cultural values that grow out of this responsible self-organization.

The project protects the implementation as its “holy of holies”, as the true element of value creation.

Here, project organizations are well advised to promote this cultural change and to communicate it within the corporate organization. This challenge is often very difficult for large corporations and reason enough for them to have an unjustified suspicion of Scrum. This is exactly what the project management must keep in mind before deciding on Scrum as its SIM.

The company or the project must be made capable to use Scrum.

Scaled agile organizations

When organizations enter an Agile transformation after some (hopefully) successful Scrum pilots, i.e. when they intend to scale Scrum within the organization, of course new questions will arise.

In a classical matrix organization, however, Scrum is not in paradise and there are always points of friction. These result from the circumstance of Scrum’ demand for self-organizing teams.

In essence, this means that, strictly speaking, Scrum introduces a non-hierarchical model. The problem here is that we as humans are usually not socialized that way. Most societies as well as companies are structured hierarchically.

This conflict must be solved in an organisation. Therefore, organizations will sooner or later have to update their PMM as part of an Agile transformation. The currently most successful representative of a PMM that allows Scrum to scale into the organization is SAFe. Such Agile PMMs ( including LeSS or Nexus) assume a more decentralized and vertical organization.

The timing of this transition from classic PMM to Agile PMM – such as SAFe – is probably one of the greatest challenges facing organizations today and must be carefully considered and prepared.