Agilité : quelques idées reçues à démystifier.

En lisant ces quelques lignes, vous allez découvrir la recette pour réussir votre transformation agile. Pour autant, il est de coutume de dire que connaître une recette de cuisine n’est pas la garantie d’un plat réussi, encore faut-il bien doser les ingrédients.

Idée reçue n°1 : l’agilité se limite à une méthode de gestion de projet

Quand on veut définir l’agilité, on parle souvent et directement de choses trop opérationnelles : le KANBAN⁽¹⁾, le backlog⁽²⁾, JIRA⁽³⁾… Le fait de considérer l’agilité comme une simple méthode de gestion de projet est réducteur. Ce raccourci est malheureusement trop souvent emprunté.

L’agilité est avant tout une culture qui prône des valeurs : pensée client, adaptation au changement, création de valeur, expérimentation, droit à l’échec… 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.
La déclinaison opérationnelle de l’agilité correspond à ce qu’on appelle communément la « méthode agile ». On peut la considérer comme une « boîte à outils » permettant un delivery itératif et la prise en compte régulière du feedback des utilisateurs pour éviter un « effet tunnel ». 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.

Ces pratiques sont issues de différents Framework (scrum, KANBAN, Lean, XP, ...) dont l’ensemble est appelé de manière générique, la « méthode agile ».

Idée reçue n°2 : la méthode agile est pertinente seulement pour les projets « Front »

Beaucoup considèrent que la méthode agile serait exclusivement destinée aux projets impactant les applications Front, comme les espaces client ou les sites internet. Or les refontes de back-office menées en agile, sont nombreuses sur la place. Il n’est pas rare de mener des projets de transformation dans un contexte d’agilité à l’échelle, qui impactent le Front, le back-office de gestion, et les briques comme l’éditique, la GED, la téléphonie et le décisionnel.

Mais alors, d’où vient cette idée reçue ? Cette confusion a plusieurs origines :

1. Certains font une association d’idée entre agilité et Front, à travers la notion de « client ». Les applications Front permettent de faire l’interface avec le client, au sens « consommateur ». Or un des principes du manifeste agile est de satisfaire le client, au sens « utilisateur » d’un produit, qui est une notion plus large.
2. D’autres connaissent l’agilité surtout à travers les premiers projets agiles de l’écosystème assurance, datant du début des années 2010. Ces projets correspondaient essentiellement à des refontes de sites WEB, dont le périmètre était en général abordable pour une équipe scrum de 8 personnes. Les refontes de back-office menées en en agile, ne sont arrivées que plus tard, car elles requièrent de passer par des Framework d’agilité à l’échelle, trop évolués pour la maturité du marché, voire qui n’existaient pas encore à l’époque : SAFE, scrum of scrum, NEXUS, LeSS…
3. D’autres encore, pensent que l’agilité est plus adaptée au SI Front, par opposition au SI Back, dont la complexité de maintenance est antinomique avec la méthode agile. En effet, l’agilité prône le déploiement continu en production, souvent difficile à mettre en œuvre pour les « gros » back-office. Or le déploiement en production après chaque sprint⁽⁴⁾ n’est pas une condition indispensable à l’agilité. Il est fréquent de voir des projets agiles où les mises en production surviennent à l’issue de release⁽⁵⁾ dont les jalons sont alignés sur la roadmap du SI « historique », en général limitée à quatre release annuelles. C’est de l’agilité « hybride », car on ne livre pas de la valeur fréquemment aux utilisateurs, mais c’est quand même agile, car on évite l’effet tunnel en collectant le feedback des utilisateurs, lors des démonstrations de fin de sprint réalisées en environnement de recette.

Idée reçue n°3 : la méthode agile n’est pas adaptée aux projets « techniques »

Également au rayon des croyances populaires, la méthode agile ne serait pas adaptée aux projets dits « techniques ». C’est également faux.

Prenons l’exemple de la mise à niveau d’un back-office de gestion sinistres, pour le rendre compatible avec la nouvelle version d’un navigateur WEB. Il est possible de découper le backlog en différentes « épopées » (ex : sécurité, interfaces graphiques, performances…), elles-mêmes déclinées en technical stories⁽⁶⁾, et de cadencer les livraisons par sprint. Bien qu’il n’y ait pas de démonstration de fin de sprint à l’issue de chaque itération (puisqu’il n’y a rien à montrer aux gestionnaires indemnisation !), nous sommes bel et bien en présence d’un projet mené en agile.
Autre exemple : le backlog d’un projet de migration de portefeuille de contrats d’assurance vie, peut être découpé en autant d’épopées que de typologie de données à migrer (personne, contrat, mouvement...), et en autant de user stories que de règles de migration à prévoir.

Dans les 2 cas cités ci-dessus, nous tirons parti des bénéfices de l’agilité : pas d’effet tunnel, planification réaliste et mise à jour de la date de fin du projet à l’issue de chaque sprint, adaptabilité et re-priorisation des développements en fonction des impondérables, refactoring⁽⁷⁾ de code au fil de l’eau…

Idée reçue n°4 : la méthode agile est à éviter pour votre projet, si l’écosystème qui l’entoure n’est pas agile

Enfin, dernière idée reçue que je souhaite nuancer : le choix de la méthode agile ne serait pas pertinent si l’écosystème entourant le projet n’est pas mature d’un point de vue agile.

La méthode agile doit effectivement être utilisée avec vigilance si l’écosystème n’est pas prêt à l’adopter. En effet, il existe divers freins à son déploiement dans de bonnes conditions : coordination, gouvernance, logistique et compétences. Ces difficultés ne sont pas bloquantes, à condition de les anticiper.

Si l’équipe projet n’est pas mature en termes d’agilité, en particulier sur les postes clés de scrum master et de product owner, alors il peut être risqué de sélectionner la méthode agile. Il y a deux approches pour appréhender cette situation :

1. Une approche prudente, qui consiste à prévoir une montée en compétences des équipes sur de petits projets, avant de déployer la méthode agile sur un projet de transformation profonde de l’entreprise.
2. Une approche plus risquée, qui consiste à mener directement en agile un grand projet de transformation même si les équipes sont novices en la matière, en considérant qu’il s’agit d’une opportunité d’embarquer un maximum de collaborateurs dans la transformation agile de l’entreprise. L’énergie consentie pour évangéliser tout l’écosystème est un investissement pour le futur. Dans ce cas, il faut prévoir un coaching agile de proximité.
3. 
   

Par ailleurs, si les projets adhérents sont menés en « cycle en V », cela implique une complexité supplémentaire de pilotage, liée notamment à un déphasage de planning. Le PI Planning⁽⁸⁾ est dans ce cas, un outil très utile pour coordonner les équipes, partager la vision, planifier les travaux, et identifier les adhérences. 

Ce qu’il faut retenir

En résumé, la méthode agile vaut la peine d’être expérimentée, quel que soit le type de projet et ce qui existe autour, car elle véhicule des valeurs essentielles à toute démarche d’innovation et de transformation.

Toutefois les freins organisationnels au déploiement de l’agilité sont nombreux, et doivent être anticipés pour que la méthode agile ait un effet d’accélérateur.

Enfin, 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 ». Le plus important est d’être agile, avant de faire agile. Lorsque l’état d’esprit manque à l’appel, on a beau mettre en pratique la méthode, cela ne fonctionne pas. J’ai d’ailleurs souvent été témoin de comportements « non agiles » dans des contextes de projets « agiles » :

• Daily meeting trop longs
• Démonstrations de fin de sprint sans collecte de feedback
• Lourdeur de la documentation associée aux user stories, pour satisfaire les développeurs
• Scrum Master en mode « chef de projet » et non « facilitateur »
• 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 pour qui le périmètre et le planning sont figés, l’investissement sur la qualité (tests unitaires, refactoring…) est une perte de temps, l’échec est à proscrire…
• Priorisation par la contrainte et non par la valeur business
• « Micro-management » en raison du manque de confiance
• Critiques gratuites et malveillantes durant les rétrospectives, sous couvert de transparence

Toute ressemblance avec des situations réelles serait purement fortuite ! Si vous souhaitez échanger avec nos experts Optimind pour approfondir ces sujets 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, Arnaud Cadon et Philippe Trémoureaux, partners de la practice Strategy & Management Consulting.

#Optimind #GestionDesRisques #MéthodeAgile #conseil #assurance #banque #scrum #kanban #safe #TransformationAgile #transformation

⁽¹⁾ KANBAN : représentation visuelle du traitement et de l’état d’avancement d’un flux de stories
⁽²⁾ Backlog : descriptif du produit avec toutes ses fonctionnalités
⁽³⁾ JIRA : outil de gestion de projet, dans lequel le backlog est administré
⁽⁴⁾ Sprint : itération de travail
⁽⁵⁾ Release : nouvelle version d’un produit, ou nouvelle livraison informatique
⁽⁶⁾ Technical Story : besoin technique
⁽⁷⁾ Refactoring : « nettoyage » de code
⁽⁸⁾ PI Planning : cérémonial agile à l’échelle permettant pour une release donnée, de planifier les travaux en identifiant le contenu de chaque sprint pour chaque équipe impactée, et les adhérences entre stories inter et intra équipes