Classic and agile project management are methods that try to solve the same problem and rely on entirely different narratives. 

“Hooray, I’ve got the hip word “narrative” in right away.” 

This is because both have “grown” in entirely different environments, i.e. they are used precisely when certain conditions are met. I don’t want to say that classical project management (often represented by the waterfall model) is old, and agile project management (mostly Scrum) is new and modern. Classical project management as a methodology has not become obsolete because there is something new, but because the environment in which it can be very successful is no longer often available. 

This article is not about making classic project management or the waterfall model wrong and praising agile project management or Scrum to the skies, but about clarifying that both concepts are fundamentally different and thus cannot be combined well. 

Unfortunately, this is a widespread practice strategy that is rarely successful. My point here is to explain why they are not compatible and what dangers lurk when you still try to bring elements from classical project management into an agile environment. 

At the risk of saying that pictures are always a bit risky, I would like to use the image “Roundabout with traffic lights” to explain why mixing the two concepts will almost certainly produce a loser: you. 

Traffic lights have a tremendous normative effect; roundabouts rely more on self-regulation of traffic through specific self-organisation of the road users involved. Self-organisation does not mean the absence of rules. A roundabout also follows clear, unambiguous and non-negotiable rules. But the normative character of the overall concept is not as pronounced as that of traffic lights. It gives the road user more freedom and more responsibility in equal measure. He may drive when the roundabout is accessible. What “free” means is at his discretion, i.e. as long as he does not obstruct or endanger any other road user, he may drive. Exactly how much space this means is not precisely defined. The situation is different with traffic lights. 

It not only tells the driver when he is not allowed to drive but also when he is allowed to drive. And this is independent of the situation, i.e. the traffic light control system creates the problem itself. 

Thus, it intervenes more strongly in traffic and therefore has a higher normative effect by eliminating all room for interpretation. It follows that even if the intersection is clear, but the signal is still red, no traffic is allowed. This is micro-management. 

One can also express it differently. A traffic light system is a proactive system, whereas a roundabout is a reactive system. Proactive means that a traffic light control system still regulates traffic even when there is no need. Every road user is explicitly told, 

“Now you can drive, now you can’t”. 

Anyone who, like me, once stood at a deserted intersection on a wintry Sunday at 4:30 a.m. and waited for what felt like 5 minutes (it was probably only 45 seconds in reality) for the light to turn green understands what is meant. On the other hand, the roundabout rules only intervene when there is a need due to several vehicles entering the roundabout and new cars entering. Otherwise, the traffic is always free. 

If both were to be mixed, the normative system always wins, i.e. the traffic light system beats the roundabout principle. This is because the traffic lights’ normative effect completely overrides the roundabout’s self-organisation. So upper beats lower, you could say. 

The principle of self-organisation will no longer be able to unfold, and all the associated advantages will no longer come into play. Of course, there may be situations where traffic lights have advantages over roundabouts and vice versa, but a mixture is incompatible in most cases. I have observed this at a roundabout with traffic lights – the only one I know of. 

Even during rush hour, when traffic is essentially one-way, the traffic lights tend to hold up traffic, of course, to the benefit of road users coming from another direction who would otherwise have to wait a very long time to enter the roundabout. A kind of minority protection is thus guaranteed. But one accepts that the overall flow of traffic is slowed down. It is hard to imagine that there is no alternative to this procedure. 

A slight diversion of the threatened minority from the inconvenient direction would probably be a better way out than paralysing rush hour traffic every day; even an upstream traffic light, as is now often used before tunnels, would probably be more effective. 

To get back from the picture to our problem, it would be conceivable to outsource specific tasks from the agile project and place them in a classic scheme. For agile projects, collaboration with other projects in external organisations, where they do not influence their methodology, is quite the normal state and, therefore, not a problem. However, it becomes a problem when the agile project in question is itself manipulated by classical methods. It is then often three things that are first added to the agile project from classic project management. 

Additional status meetings 

Status meetings are a standard tool of classical project management, assuming that everything has already been planned (and was therefore plannable). In contrast, agile project management uses the instrument of planning meetings. Therefore, many are surprised when they hear that in the agile world, we plan permanently. 

Planning tends to be seen as a characteristic of classical project management, but this is a misconception. Every agile meeting contains a planning component, not only for the apparent PI (SAFe) or sprint planning meetings but also for less obvious meetings such as daily stand-ups (we plan today), sprint reviews (inspect & adapt session) and retrospectives (how can we improve the team’s work in the future), etc. 

Status meetings, on the other hand, i.e. usually reporting to an authority higher up in the hierarchy about what has happened so far, are not very conducive to the self-organisation of teams and are often a consequence of the re-delegation of responsibility or paving the way for it. 

Additional roles

Additional roles are supposed to relieve the teams, bundle communication and regulate clear responsibilities. But unfortunately, they have precisely the opposite effect in agile teams. They take responsibility away from the teams, inhibit the self-organisation of teams and create bottlenecks. 

Introducing release managers, test managers, lead architects, technology evangelists, or support and ops managers often destroys the tender seed of a DevOps culture even before the organisation has understood what is intended in the best sense. All these roles take on responsibilities previously the responsibility of both teams. With each new position, the number of dependencies between feature teams and the role and between themselves increases. 

If a role is not there or does not react quickly enough, a decision backlog immediately arises. Moreover, the teams quickly lose the motivation to make decisions or take on any responsibility. But since the groups and only the teams are the sources of value creation, it is easy to imagine what happens now. Every time there is a problem, the team raises its hands and points to some role as responsible. Do you want it to come to that? 

Additional KPI or classic project KPI

There are not many things in agile project management that look like numbers and are, therefore, suitable for KPIs. This has always been a thorn of traditional project managers because KPIs create transparency and enable control. Without KPIs, there is no control. But KPIs require a stable basis and, of course, benchmarks against which we can measure them. For example, project progress compared to the planned budget and time, plus the ever-popular Gantt chart. Such KPIs are easy to collect and measure precisely. 

But what about agile KPIs like velocity, sprint accuracy, product burnup, customer satisfaction, business value, etc.? 

They are more challenging to collect, require more interpretation and are usually more complex. Additional KPIs from the classic project toolbox often need the creation of a stable and no longer agile environment. Increasingly, the illusion is fostered that one would know the scope entirely and be able to determine the effort required for it through an expert estimate. Disappointment is usually never coming, but the damage to the agile culture is challenging to repair. 

In combination, they result in what is perceived by the actors of the overall project as micromanagement. And these compromise (not to use even more drastic terms) the agile character of a project sooner or later – usually very quickly, unfortunately. Why?

Because they have a much higher normative impact and thus overlay the holy of holies of agile project management: the self-organisation forces of agile teams and the awareness of accountability and ownership of the actors. 

However, if these measures haven’t helped yet and won’t, then a few more actions usually follow, often stripping away the last remnants of agile methodology and mindset. 

Task forces, sometimes also called platform teams, cross-cutting teams or technology teams

Task forces are often a helpless attempt to solve problems that agile teams, already weakened by the measures described above, can no longer solve. Most of the time, they make the situation even worse because now, to make matters worse, the best people from the feature teams are taken away and put together in a task force team. Such groups are usually not agile; sometimes, they still have a Kanban board, often not even that. 

This further restricts the agile feature teams’ ability to act. The fact that the teams are also degraded to second-class does not precisely increase motivation. Platform, cross-sectional or technology teams initially create dependencies on the feature teams, similar to the additional roles described above. 

Things worsen if these “horizontal” teams are also “agile”, i.e. develop their plan. The teams find themselves in a web of interdependencies that further reduce the velocity of all groups. We should not forget that only the feature teams generate business value, i.e. added value. 

Adding more resources to teams (both often in combination)

In Hamburg, we say you shouldn’t throw good money after bad. But that is precisely what is happening now. The last attempt to save the project in such a situation is often to find more resources and give them to the teams. But unfortunately, these teams’ velocity has been weakened by too many players, a confusion of responsibilities and interdependencies. To make matters worse, the teams are now inflated, have to onboard new people and now have to deal with themselves. It doesn’t take much imagination to picture the money burning that is currently taking place. 

And finally, the gradual dissolution of agile structures

Timeboxing is often sacrificed at an early stage with the remark that it is better to concentrate on the deadline and introduce a Kanban process (which at least still has an elegant touch). This means that all agile planning principles are lost. You are now flying completely blind. The principle of hope now begins to rule. Organisations can’t get fresh money as fast as the costs fly around their ears. Of course, the picture is somewhat exaggerated. But is it far removed from reality? I have seen at least a few organisations precisely in this situation, but they are still talking themselves into the corner. The standard excuse: 

“The costs are commensurate with the increased complexity. After all, we are an agile project”.

Yes, to make matters worse, after all this, the culprit is also located in the chosen agile methodology, which sounds almost like mockery, but is unfortunately often reality. 

But it demonstrates how a few wrong decisions can quickly burn a lot of money in agile projects. If you don’t want to fall into this trap, get into the habit of fighting problems in agile projects with agile methodology. Because at some point, the elegant setup is not yet ideally deployed or cannot unfold properly. We need to look for these places and work on them more consistently. Often, all that is required is more trust in the agile methodology and a lot of experience and knowledge.