Since a few years the community is thrilled by what is called „Agile Project Management“. The approach is being aggressively advocated as a MUST HAVE in modern times, all other approaches are “old fashioned”, “traditional” and thus obsolete. But what is really different and when does it make sense to adopt agile methods? Answering those questions we need to go back to the roots of the discipline, which can be traced back in the 1950s. The aerospace and defense sector in the USA applied Operations Research to complex engineering problems. Operations Research  is a discipline that deals with the application of advanced analytical methods to help make better decisions. Network Planning was born. The paradigms of these times were separation of planning and execution, planning was seen as key activity and through planning the future can be prescribed. As consequence, project management focused on planning techniques, e.g. drawing Gantt-Charts and analysing critical paths. Process models and tools have been developed in order to stay in control of what is going on during the execution of the project and not allowing people to act on their own.

What is the main emphasis or the paradigms of Agile Project Management? According to the Agile Manifesto (for Software Development) it is: Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan. The main idea is that there is too much change in order to prescribe the future through plans. Thus, only a short-term plan (“sprint”) spanning a few days or weeks is necessary. Interactions and communication are valued higher in such a context. Project teams are encouraged to collaborate intensively with customers and all partners in order to learn from them about the changes and adapt accordingly (the project deliverables and plans). Processes and tools are reduced to a minimum in order to allow the team to organise themselves, to be more creative and flexible, arranging with the changes and the demands of the customers. People are more important than processes, they are empowered and asked to self-organise. The deliverables are decomposed into smaller prototypes, components or work results in order to validate them at an early stage and not at the end of a (long) project lifecycle.

Does this make sense? Yes, absolutely. However, Agile Project Management is nothing new, it is a normal part of the evolution in the project management domain. Nowadays the focus is definitely on people and on change. Project managers have always been agile, project management always needs to be “fit for purpose”. Many organisations try to improve their project management practices through applying agile approaches, e.g. in software development, innovation or change projects. Some combine approaches to a hybrid mix of “traditional” with “agile” approaches and methods. For example, in Automotive Industry, the software of infotainment systems is developed using Scrum, the other parts of the system or automobile is being developed with rather traditional approaches, called “Stage Gate”-Development Processes or “Waterfall”. In a project, approaches can be even mixed, depending on the stage of the project and its requirements. Project managers need to be  virtuoso in selecting the right approach and adopting them according to the situation and its requirements. Not “one size fits it all”, project management is situation-dependent and thus in general “agile”…

Unfortunately, the hype whitewashes weak points of Agile Project Management. Empowering people and asking for self-organisation requires an organisation to be supportive. My observation is that most of the organisations are not yet ready for this kind of approach, having a strong hierarchy, a bossy culture and not giving the space to maneuver for project teams. Agile Project Management is not freestyle, there are still many processes, methods and tools in place. They often sound new fashioned, but are in fact quite often “old school”. For example, “Kanban” was developed by Toyota during the 1950s for optimizing the production. Nowadays it is being re-advocated as “new” tool for work flows and coordination. This is called “old wine in new skins”, right? More reflection is needed, why we need certain methods and tools, how we apply them and this is what we need to train the people rather than to proliferate simple “cooking recipes”. Another rather critical aspect is the decomposition of work into increments, components or small work packages. That may work in software, but in hardware (complex products or systems) it may lead into losing the big picture out of view and ending up with a misfit of the parts.

Is there something “beyond agile”? Definitely, the evolution will continue. A few years ago we asked ourselves that question during a conference in Germany and invited a musician. When comparing music and project management, agile approaches may sound like “free jazz”, but still there are (simple) processes and routines to be followed. But what about “improvisation music”? Although performers may choose to play in a certain style or key, or at a certain tempo, conventional approaches are highly uncommon in free improvisation; more emphasis is generally placed on mood, texture or more simply, on performative gesture than on preset forms of melody, harmony or rhythm. These elements are improvised at will, as the music progresses. The musician at the conference explained how difficult it is to improvise as we have mental models shaping our behaviour and also the context stipulates certain actions. However, to reach new levels of innovation and development the improvisation is key. Translated into our language, a “projector” needs to explore, resonate with the context and stakeholders, try out new solutions and shape the results of the project accordingly. In a few years the “Agile Project Management” may be labeled “old fashioned” and new trends will overtake for the good of the profession…