L’agilité : un état d’esprit avant d’être une méthode.

Tout le monde parle d’agilité comme une méthode de gestion de projet. C’est certes vrai, mais un peu réducteur. L’agilité c’est avant tout un état d’esprit. Je vous propose d’y voir plus clair à travers cet article.

Qu’est-ce que l’agilité en entreprise ?

On définit souvent l’agilité comme une méthode de gestion de projet. Or, l’agilité est avant tout une culture qui prône des valeurs : pensée orientée client, adaptation au changement, création de valeur, expérimentation et droit à l’erreur… Cet état d’esprit est indispensable pour suivre le rythme d’un monde où tout s’accélère : évolutions des attentes des clients, innovations technologiques, et pressions réglementaires.
Une entreprise agile est capable :

• d’optimiser le time to market : l’utilisation de méthodes de gestion de projet agiles permet de diviser par 6 le délai de mise en marché de produits (qu’ils soient des contrats d’assurance ou autre) ;
• de s’adapter aux changements à moindre coût et d’innover selon des cycles rapides ;
• de booster la motivation et la productivité des équipes : l’agilité permet d’augmenter de 40 % la productivité, et 80 % des collaborateurs se déclarent « satisfaits » de cette méthode de travail ;
• d’améliorer la gestion des projets de transformation.

Qu’est-ce que « la méthode agile » sur les projets de transformation ?

Après vous avoir proposé une définition générale de l’agilité, faisons un focus sur l’agilité appliquée aux projets.
La déclinaison opérationnelle de l’agilité correspond à ce qu’on appelle communément les « méthodes agiles ». On peut les considérer comme une « boîte à outils » ou un système d’exploitation permettant de livrer à une fréquence élevée des morceaux d’un produit tout en prenant en compte l’avis des utilisateurs de manière itérative afin de s’assurer que les développements correspondent bien à ce qui est attendu. Le produit est décrit dans un backlog structuré en « épopées », ou macro-fonctionnalités, elles-mêmes déclinées en user stories, ou besoins fonctionnels.
Il y a plusieurs méthodes agiles qui se déclinent en différents Framework, ou cadres opérationnels : Scrum est la méthode la plus commune. Elle est simple, facile à mettre en place, plutôt légère dans ses artefacts et comitologie. On retrouve également le KANBAN (soit seul, soit en complément du Scrum) ou d’autres méthodes, ou encore le Lean, XP, Spotify....
Les méthodes agiles permettent d’optimiser la gestion des projets de transformation sur plusieurs axes :

• atteinte des objectifs : 76 % de réussite pour les projets agiles vs 56 % pour les projets « cycle en V » ;
• qualité des livraisons : près de 50 % de défauts en moins lors des mises en production, grâce aux bonnes pratiques prônées par l’agilité (refactoring de code, tests unitaires…) ;
• délais : par exemple, les délais de conception sont divisés par 2 en agile, grâce notamment aux circuits courts d’échange entre le Product Owner et l’équipe de delivery.

Quelques illustrations de la dichotomie « culture vs méthode » en matière d’agilité

Pour exploiter pleinement le potentiel offert par l’agilité, il faut l’appréhender plus comme un état d’esprit qu’une simple « méthode ». Lorsque l’état d’esprit manque à l’appel, on a beau mettre en pratique la méthode, finalement cela ne marche pas.
J’ai effectivement souvent été témoin de comportements « non agiles » dans un contexte projet « agile », qui illustrent la distinction « méthode vs culture ». En voici quelques exemples :

• Scrum Master en mode « chef de projet » et non « facilitateur » ;
• démonstrations de fin de sprint vécues comme une « case à cocher », sans collecte de feedback ;
• lourdeur de la documentation associée aux user stories, pour satisfaire l’équipe de développement ;
• organisation projet imposée à l’équipe cœur, en mode top down ;
• développements quick and dirty en raison de la pression sur les délais ;
• sponsors non acculturés, qui ont des exigences sur un périmètre et un planning figés ;
• non investissement sur la qualité (tests unitaires, refactoring…) car « on a des deadlines à respecter » ;
• priorisation par la contrainte et non par la valeur business ;
• multiplication des points d’avancement et des reporting demandés par la Direction, et « micro-management » en raison du manque de confiance ;
• obligation pour le Product Owner de valider toutes les user stories auprès du métier, avant d’engager les développements, sans aucune délégation de pouvoir ;
• critiques gratuites et malveillantes durant les rétrospectives, sous couvert de « transparence ».

Toute ressemblance avec des situations réelles serait purement fortuite !
A contrario, il est tout à fait possible d’évoluer dans un environnement culturel agile, dans le cadre d’un projet mené en « cycle en V ». C’est l’état d’esprit qui est agile dans ce cas.
S’il y a donc une chose à retenir, le plus important est d’être agile, avant de faire agile. C’est la raison pour laquelle il est très fréquent de voir des équipes accompagnées par des coach. Appliquer une méthode et ses artefacts est à la portée de tous, mais acquérir des réflexes agiles nécessite de changer radicalement d’approche, ce qui est beaucoup plus complexe à réaliser par soi-même.
Si vous souhaitez échanger avec nos experts Optimind pour approfondir le sujet et bénéficier de retours d’expériences, n’hésitez pas à les solliciter !

Article rédigé par Sofiane Sahraoui, Principal de la practice Strategy & Management Consulting.

Pour plus d'information, vous pouvez contacter Caroline Albanet et Arnaud Cadon, partners de la practice Strategy & Management Consulting.