Is agility necessarily synonym with success?

A blooming of post-it notes: the springtime of Agility

It goes without saying that agile methods have flourished in public and private organizations since the publication of the Agile Manifesto almost 20 years ago.

We continue to observe this massive spread among our clients at various levels. In addition to the multiplication of post-it notes and other visual management on the walls, the observation is without appeal: we want to establish an agile culture in the company (from the hundred-year-old multinational to the start-up in gestation), to set up an agile organization in the services, to manage its projects in agile, to develop in agile... Scrum, Kanban, Lean, Extrem Programming (XP), Devops, Feature Driven Development (FDD),... the agile offer is plethoric and complex. All these methods are based on a multitude of concepts and principles that overlap, in whole or in part, but with a different operational variation. Some methods have even given birth to new methods such as ScrumBan, which is the result of the Scrum and Kanban methods! So how should we position ourselves in the face of this bouquet of methodologies? Is it necessary to implement agility? At the beginning of these reflections, it is essential to (re)ask yourself the following questions:

- What are my problems?

- What is the objective to reach?

- And finally, what are the limits of my current situation?

To these questions, agile methods will provide answers on how to overcome the initial limits, but they will never provide fundamental answers. Agility is not an end in itself. Questioning and going beyond the existing limits is what made these methods successful:

• Where the customer noticed a gap between the expression of his initial need and the final deliverable (a common disappointment in V-cycle projects), regular feedback, a backlog, a task prioritization system and iterative delivery of work were put in place.
• Where it became necessary to manage interactions between resources/teams, multidisciplinary teams were formed, a project board was set up and daily meetings were organized to share progress, successes and difficulties.
• Where it was necessary to follow the progress of the project in a simple way and to impulse dynamism in the work, we redefined the division of the deliverables at a finer mesh level, we created visions, story maps, personas and user stories

It is therefore upstream of the application of Agility that we need to ask ourselves the right questions when faced with a given situation. The content or application of these methods can sometimes appear to decision-makers or operational staff as a panacea to the limitations of traditional methods of the 1980s (waterfall methodology, V-cycle, etc.). How many times do we see the words "implementation of the agile method" in response to a risk matrix in monitoring committee documents, or in the first lines of a project approach? But implementation is not everything. Once deployed, uncontrolled agility can lead the organization or projects adrift. The time factor is an essential element to take into account.

Beware of falling post-it notes: the fall of Agility...

The word "agility" is reassuring and its implementation within organizations and projects can be fruitful. However, long-term success requires two major attributes: Training and Discipline.

Although agile coaches recommend choosing the method best suited to the needs of their clients, it is rare in large projects that all stakeholders are aware of the same methods. This can lead to a rupture. On the business side, teams can find themselves at a loss when it comes to the principle of "operational software, not exhaustive documentation". Agility should not be synonymous with a lack of documentation. On the IT side, teams can feel overloaded with a growing backlog without any new prioritization of tasks. Agility must not rhyme with "erratic evolution of the need". These are risks frequently encountered when part of the organization's ecosystem chooses agility while the other project stakeholders have another way of operating.

If the implementation of agile tools can boost dynamism and participate in the resolution of problems or simply in the good launch of a project, maintaining such a dynamic is not easy. Post-it notes that don't "live" fall off... The hazards of projects mean that the temptation to sacrifice the "agile routine" on the altar of dealing with emergencies is never far away. Cancelling a daily meeting in case of absence of the Scrum Master or of meetings may seem understandable and harmless, but it can become the grain of sand that jams the machine... Agile tools are effective when there is consistency and frequency of use.

Beyond the good and the bad of such and such methodologies with regard to a project, it is up to the manager to set the course, the tempo and to ensure the support and motivation of everyone. Agility, V-cycle or hybrid methods, more than the choice of the most adapted method, it is advisable to rely on common sense, to keep in mind the objective to be reached, to compose in a pragmatic way with the existing and to take into account the time factor. Wouldn't true agility mean extracting, where appropriate, the substance of one or more methodologies with regard to the organization in place and its pace of life? In medio stat virtus would advise Aristotle.