Differences between the classic and the agile world

There are many texts dealing with the difference between agile and classical project management. Now, another text about this topic. I try to demonstrate the differences on two levels: on the mindset level and on the theory level.

Mindset level

The agile approaches not only deal with project management, but also with personal self-organisation (see Getting Things Done), with the idea of almost trouble-free work (see Kanban) and with increasing the quality of the work process (see eXtreme Programming). Furthermore, agility is fed by the teachings of:

• minimisation of waste (Lean Management)
• maximisation of the customer benefit (Minimum Viable Product + Pareto principle and meticulous prioritisation with customers)
• self-organisation of the teams (by the pull principle and the old ideas and concepts from the “master-slave dialectic” by Georg W. F. Hegel)
• frequent and regular delivery of increments (product parts)
• shared values and principles based on trust and cooperation.

According to IPMA (classical project management), we find the code of ethics whose values of course also flow into the methodology. However, the codex remains an important foundation for projects that are realised according to IPMA, but we do not find the values indirectly in the elements of project management, but they remain diffuse in the background and as recommendations.

In the agile approaches (e.g. Scrum as the best known representative), the entire process is based on these values in order to achieve transparency, inspection and adaptation.

Theory level

The most famous feature (element) on which many people want to determine whether work is done in the classical or agile method is the process model: waterfall (classical) versus iterative (agile).

A phase plan with a waterfall-like structure is by no means a classic project. Here, we have to take a close look at which elements still make the difference. In the following text, I refer to the IPMA elements “goals” and “work breakdown structure”.

Goals

We all know the magic triangle with its corners “performance – costs – time”. In classical project management, we always assume that the goals have already been worked out in detail as well as in full before the implementation phase and that they are formulated in a SMART way. As a result, the corner “performance” is fixed (product requirements document and scope statement) and the corners “costs” and “time” are estimated by the contractor.

In agile project management, please turn around the triangle completely. Now, the corners “costs – time” are at the top and fixed by the contractor. And the “performance” is estimated by the contractor. Of course this only makes sense if we want to start with the project (e.g. to be ahead of the competition) but only already know a part of the goals. This may be due to the fact that we are perhaps in the innovative field and neither really master the technology (the HOW TO) nor know exactly the customer requirements (the WHAT), but only iteratively better recognise these factors in the course of the project (the Stacy Matrix is to be pointed out here).

As a consequence, we also have a clear indication of when agile and when classical project management would be appropriate, regarding the view to goals.

Work breakdown structure (WBS)

Of course, this element has a very close relationship with the goals. The above-mentioned properties of the two “magic triangles” have a direct effect on the Work Breakdown Structure (WBS).

In classical project management, a complete WBS is first worked out, right down to the individual work packages and their descriptions. Only when the WBS is (almost) complete, a flowchart and a schedule are created, which form the basis of the resource and cost plan. In this case, the work approach is clearly plan-driven.

The approach to agile project management is different. In principle, there is also a WBS, which of course is not called WBS. But it looks like one. In most cases we speak of a backlog. While in classical project management the project is split into subprojects, subtasks and work packages, the “agile WBS” (the backlog) is divided into epics, user stories and tasks.

But the biggest difference between the two types of project management is that in the agile way the project is already started when the “agile WBS” (the backlog) is not even nearly completely worked out, but it already contains the most important “goals” (epics and user stories) in the opinion of the customer. In other words, the “agile WBS” (the backlog) only fills up during the course of the project. But it is constant, regular and always with a view to the most important goals of the project. As a consequence, the approach is not plan-driven, but value-driven.

It should also be mentioned here what is meant by “important”. The most important goals are those that receive the highest priorities from the customer. Which means, those goals having the highest added value for the project result (e.g. the product).

Now the circle closes to the mindset level. Because in order to always be able to represent the highest added value, I have to be focused on maximising the customer benefit, reducing waste (e.g. by regular risk management) and by frequent and regular deliveries to receive feedback from the customer as quickly as possible.

According to IPMA (ICB 4.0) we are talking about approximately 30 project management elements. On theory level, all 30 elements could now be weighed and differentiated between the classical and the agile approach. To keep within the scope of this article, the author does not go into further detail. Thank you for your attention.