Misconceptions about agile project management or agile methods are not lacking and can lead you away from the benefits you can expect. Admit it would be a shame.
Myth 1: Agility Is A Fad
If we consider agile methods as simple methods, it’s just a fad that will pass. After all, we have seen scrolling. In reality, agile methods are much more than that. On the one hand, they convey fundamental values and principles – particularly management – which make them a natural state of mind. On the other hand, they are the subject of a fundamental paradigm shift, so much so that one should not speak of project management to qualify this approach but of product management.
The conditioning of the “project mode” pushes us to focus – sometimes to the point of obsession – on success criteria relating to respect for deadlines, budget, scope… and quality when we do not sacrifice it for the benefit of the first criteria. And the product, then? And user satisfaction? In agile mode, we focus on development.
The goal of the game does not consist in covering all the needs expressed in an initial specification which will sooner or later be out of phase with the principle of reality (cf. real expectations of “real “users, regulatory changes, new ideas for features discovered along the way, technical contingencies, etc.). Instead, it consists of satisfying users and associated business issues with minimum functionality. Therefore, we cannot speak of a fad to qualify such a paradigm change.
On the other hand, the agile movement is a fundamental movement that dates back to 2001, the year of publication of the agile manifesto, or even beyond, since the publication of the most widely used agile methodological framework, Scrum, dates back to 1993. A movement that still takes more scale despite some deviations ( bogus certifications, trainers without real experience in agile project management, neglected agile development practices, etc.).
Myth 2: Agility Is Anarchy
This received idea often comes from a somewhat too hasty reading of the agile manifesto describing the four values and 12 principles common to the different agile methods. Four values consist of favoring people and their interactions over processes and tools because projects have become too complex to interact only through tools or techniques.
To favor the realization of a usable product rather than exhaustive or plethoric documentation, to select the collaboration with the customers rather than the contractual negotiation and finally, the adaptation to the change rather than the follow-up of a plan. But the manifesto does not stop there; it adds: We recognize the value of the second element but favor the first.
In other wors, on agile projects, there are, of course, processes; Scrum is one of them (very simple, but it is a process), tools (there are now a plethora of agile project management tools ), documentation (it is necessary to capitalize at least the knowledge required for the maintenance of the product and its durability), contracts (there are even agile “win/win” contracts) as well as macro plans and a lot of planning (planning at three levels: long, medium and short term to adapt to changes).
Agile project management requires much more discipline and rigor than the classic approach. For example, the team of an agile project must be able to produce new functionalities potentially deliverable to users at the end of each iteration, whose duration is concise. 2 weeks on average.
Myth 3: Agility Is Not For Big Projects
Another received idea linked to the fact that agile methods and Scrum generally recommend a team size of fewer than ten people. For reasons of optimization of coordination “costs” in particular. A limitation that does not come from theory but from empiricism.
The only natural way to achieve a pragmatic methodology adapted to the realities on the ground. Although this size recommendation applies to a team, nothing prevents working in several groups of less than ten people. There are even proven large-scale agile project management frameworks.
Myth 4: Agility Is Only For Software Development Projects
There is no doubt that agile methods come from the software development sector. However, we now see Scrum (for example) used on industrial projects, hardware or even in education. For the simple reason, it is that Scrum is only a lightweight methodological framework that can be adapted to all kinds of project contexts. It gives us complete freedom to integrate the practices and techniques specific to our context.
To the point of destabilizing us at the beginning because we are used to expecting from a method the answer to all the problems and all the scenarios. Scrum is a methodological framework, not a technique. Misconception No. 5: Agility Only Works With Vouchers, And If Everyone Plays The Game Properly implemented, agile methods can satisfy both top management and players in the field.
To benefit from the eight success levels of agile project management, it is necessary to emancipate and respect the actors in the area: trust, support, self-organization, and sustainable pace. Meanwhile, the manager (or project manager), generally overloaded, will be relieved of certain cumbersome activities such as planning and work organization to focus on resource management, leadership and coaching of his team members. to develop their potential and to make them grow.
But if everyone needs to play the game? The important thing is, above all, to have a hard core of people ready to try the adventure and an agile “knowledgeable” determined to introduce agility, mainly through the coaching of actors. The level of technical skills of team members is no more or less important than on any other project. Either way, everyone will have the opportunity to develop their skills.
Finally, the only absolute incompatibility with agility would be a culture in conflict with that of skill. In other words, with the four values and 12 agile manifesto principles. And here again, it must be said that an organization’s culture can evolve. It may be necessary to start with a first pilot project with a strong sponsor who adheres to the agile culture, has perceived the gains to be made from agility and will be able to demonstrate these gains in the event of the pilot’s success to tip the rest of the organization subsequently.