Agile – versus classic project management or more planning, less status
Time and again, I come across organisations that are in the midst of an agile transformation. Usually, the topic of “agile” has been “sold” to the teams and employees with amicable terms – but actually “prescribed”. We have to become faster, be more flexible, remain able to deliver, become leaner and more lightweight, and so on. Then all the roles, tools and a few core processes are quickly introduced, and the method will do the trick.
A few weeks or months later, the desired success has often not materialised, and the first disappointment sets in. Usually, methodical adjustments are made, which turn the wheel back a bit without the people involved noticing. But unfortunately, this does not make it any better.
According to my observations, we often did not adequately explain the essential difference between classic and agile project management to the actors at the beginning. This leads to the fact that traditional project management elements often come back when adjusting the agile method. The differences between classic and elegant project management are so fundamental that “customising” the process with elements from both forms tends to create new problems or raise false (because unrealisable) expectations.
I am not talking about differences in doing, i.e. roles, meetings, the use of tools, etc., but about the fundamental differences in the perspective on a project, from which the doing is then derived.
In this article, I would like to briefly discuss a few of these essential differences in perspective and use a practical example to show how we can tell if we are still agile or already backsliding.
Agile introduces a new era
Time is relative, and I guess you could say that agile project management virtually turns the time concept of classic project management on its head. This fact is so fundamental that I am astonished why it is hardly addressed in many organisations. It is essential because it has a whole series of consequences for applying the method. Unfortunately, these things often become the subject of the first (false) compromises. You soon reach a point where the whole structure becomes unbalanced.
Classic project management also knows iterations, which are, in turn, divided into individual phases. For example, the iterations can be individual releases, a proof of concept, or the creation of an MVP (minimum viable product). And, of course, there is a whole series of milestones that should not be missing from any reporting. But in classic project management, the phases of an iteration are always determined by content, never by time.
The specification phase is complete when the specification is ready, the implementation phase is done when the product or sub-product is prepared, the testing phase is complete when all the intended tests have been carried out, and so on.
The fact that these phases are planned, which we can always see so beautifully in the Gantt charts, does not change this. By the way – and because it fits so nicely – whenever you see a Gantt chart appear in reporting, you are already back in classic project management.
In agile project management, a different time concept is used. And I think it is clear why you should not mix the two forms of project management. Because dealing with two other time concepts simultaneously would probably be a bit too much even for Einstein of relativity. Agile project management works strictly “timeboxed”, which means that the iterations are completed when the alarm clock rings and the timebox have expired.
Whether you are already asleep or would rather stay in bed is of no interest to the agile project manager, it’s time to get up. The little metaphor only says that we are pretty familiar with this concept in our daily lives. Of course, we use different concepts for different things in our everyday lives, but we don’t mix them.
In agile project management, the content is based on the timebox, not the other way round, as in classic project management. Stories must be cut so small that they fit into a sprint, and so on. The reason for this change of perspective is relatively apparent. Agile project management comes into play when we find it difficult to fully grasp the things to be implemented, either because we lack the time (time-to-market) or because they are too complex or could change quickly.
The consequences of agile project management are far-reaching, and they explain so many things about agile methodology. First, they explain why the iterations have to be short, of course. A one- to two-week timebox (sprint) can still be planned reasonably well, but a three-month timebox can no longer be planned.
The whole thing only makes sense if the sprints are completed successfully, i.e. sprint commitments are not a nice to have in agile project management, as one might, unfortunately, assume if one looks at the sprinting accuracy of most teams, but they are essential. The whole timebox principle is completely undermined if sprints are repeatedly not completed. The organisation then goes into precisely the blind flight it wanted to escape. If this is not adhered to, one might as well go back to classic project management.
This is the most crucial difference between the two forms, which should be worked out very clearly and precisely within the framework of an agile transformation. Because once you have done that and always keep it in mind, there is not much that can go wrong.
Let’s move on to another difference before we get to the title topic.
SCRUM knows only three roles
While organisations in classic project management tend to invent a new process and a few new roles for every new problem, agile project management takes a different approach and does precisely the opposite. SCRUM only knows three roles. This does not include all agile project management but illustrates the principle. SAFe, for example, naturally knows a few more functions at the organisational level, but they remain few, and the principle of static roles is not deviated from. Let’s stay briefly with SCRUM as the basis of SAFe and others.
There are only three roles, no matter the project, what is to be implemented, what technology, complexity, team setup, etc. There are only three roles. That makes it crucial for the organisation to be clear about the roles and how they work together. Often I see that it is not so clearly defined which competencies Scrum Masters have compared to Product Owners. I have described the roles in detail here. At this point, it is only a matter of working out the difference between classic project management.
Because this inevitably leads to the next difference, which is also of great importance.
Processes versus people
The human factor plays a central role in agile project management. Now, this is not to say that classical project management does not also take care of human resources development, nor is it to say that agile project management – as Karl Marx would probably put it – has taken the exploitation of human labour to the extreme. Although I admit that there is perhaps some truth to the criticism, at least the rising burnout rate in our industry suggests it in some respects. But that is another topic.
While classic project management is more concerned with processes, architectures and organisational structures, agile project management focuses almost entirely on the actors. This change in perspective is also not altogether coincidental and can be explained in the same way as above, with the prerequisites that lead to agile project management. Simply put, the preconditions are so poor (little time, little manageable because of high complexity, high volatility) that apart from the actors who are supposed to fix it, there is hardly anything on which we could plan processes, structures or even reliable architectures.
So we need to empower people to deal with these situations instead of just putting them in the right place like chess pieces with the right skill and task. Programmers become developers. The creative potential and social integration have to be promoted much more. I’m not saying this hasn’t played a role in classic project management, but it definitely reaches a new level here.
Here, too, the consequences are far-reaching. Agile project management is consistently teamwork. Maximum transparency, short, direct and creative communication in self-organised teams, the development of a DevOps culture all play a central role in this context and characterise agile project management.
But what does all this have to do with the title topic? Everything.
Let’s return to the beginning of the article. Many projects have forgotten to explain the essential differences between the two forms mentioned above and have somehow and somewhat mechanically slipped into agile transformation. After a while, this doesn’t work so well and one of the most common reactions to this emerging dissatisfaction and disappointment is a natural reversion to micro-management.
The first step in this direction is the dwindling trust in the methodology and the actors. The second step – and this is what micro-management means in practice – is the introduction of countless status meetings, jour fixes and even more status reports. Even many daily stand-ups degenerate into status meetings in which people are asked these three questions (what have you done, what do you plan to do today, what impediments, blah blah blah). The formerly agile meetings often remain in name – we suddenly do a stand-up status meeting – but are completely reinterpreted. The same happens with the reports, which always report more towards 100% (this is also only possible in classic project management, where the 100% has been defined once.
Agile project management does not live from status meetings and reports, but from permanent planning
Strange, because planning is actually a term attributed to classic project management. But the exact opposite is the case. In classical project management – and this is of course a great exaggeration – there is only one major planning phase at the beginning. From then on, only the status of progress against planning is determined. In agile project management, on the other hand, planning is permanent, not just before each iteration, but really permanent, i.e. daily.
Even a daily stand-up is actually a planning meeting. The only question that really plays a role, or at least the main role, is “how are we going to finish this and that story together today and who is going to do what and when? And this is not a question that can be answered by everyone individually – as in the status meeting – but should be a very lively team discussion.
Even in agile boards, the dilemma continues in countless statuses. I have described what this is all about here. We only need three statuses (open, in progress, done) and everything else (in testing, in review, in deployment, etc.) are activities that should be the subject of planning. I cannot plan a status, but I can plan an activity (subtask).
The result of our permanent planning can then be read very quickly in very few KPIs or viewed directly in the review in the form of the inspection of the work results through the use of very short iterations (e.g. one-week sprints). One could also say that it is the result that counts. We don’t really need to constantly check how the self-organised team in which we have placed our trust has managed to do this.
Unfortunately, the status meetings rather document the lack of trust of the project management and their discomfort with the perceived loss of control. The tragic thing is that the reintroduction of status meetings and the reporting level almost automatically means that permanent planning is neglected. This is like a reflex, triggered by the fact that planning naturally requires more effort, communication and creativity than maintaining a status report and hoping that things will work out.
In any case, the existence or increase of status meetings and jour fixes is always an indication that an organisation has either not yet moved away from classical project management or is in the process of bringing it back. Don’t get me wrong. Keeping members of an organisation in sync and up-to-date is absolutely essential in agile project management, both in vertical feature teams and in horizontal guilds, communities of practices, etc.
But that is something different and can also work much better and more purposefully in the context of planning or reviews (or Inspect & Adapt sessions) and retrospectives. All these meetings always include a planning level: Retrospectives: what can we do better in the future; Inspect & Adapt, as the name suggests; Daily Standup: as mentioned above; Review: what is the result and what is still missing.
It is worth working on the abolition of status meetings. It creates more trust and thus also has a much more motivating effect on the actors. It takes some courage at first to fight against one’s own loss of control, but it moves organisations forward faster than sticking to – to stay in context – outdated practices.
