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

Tout le monde parle de la méthode agile, et on entend tout et n’importe quoi à son propos. Dans cet article, nous allons démystifier quelques idées reçues sur l’agilité, qui persistent malgré la démocratisation du sujet.

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

Il m’est arrivé récemment une histoire qui m’a donné envie d’écrire cet article. Un nouveau membre d’une communauté agile que je fréquente a posé la question « qu’est-ce que l’agilité » ? Un des coachs a répondu en dessinant un tableau KANBAN(1) sur le mur et en affichant un backlog(2) dans JIRA(3)… C’est le genre de réponses qui me hérissent le poil ! Le fait de considérer l’agilité comme une simple méthode de gestion de projet est trop réducteur. Et ce raccourci est malheureusement trop souvent emprunté.

L’agilité est avant tout une culture qui prône des valeurs : création de valeur, pensée orientée client, adaptation au changement, expérimentation et 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 », ou un ensemble de pratiques, 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 2 : la méthode agile est pertinente seulement pour les projets « Front ».

Autre idée reçue que j’ai souvent entendue : la méthode agile serait destinée exclusivement 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. D’ailleurs, R&B Partners accompagne actuellement un programme stratégique dans un contexte d’agilité à l’échelle, qui impacte le Front, le back-office de gestion des contrats et sinistres, et les briques périphériques comme l’éditique, la GED, la téléphonie et le décisionnel. Ce programme en est à sa quatrième release(4) livrée, ce qui prouve que la méthode agile ne fonctionne pas uniquement sur les projets Front.

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

  • 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.

  • 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 est 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…

  • 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(5) 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 (un ensemble de sprint) 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é « dégradée », 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 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(6), 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 deux 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(7) de code au fil de l’eau…

Idée reçue 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, qui n’est pas totalement fausse, mais 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 et de prendre les mesures nécessaires pour les maîtriser.

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 :

  • Une approche très raisonnable, qui consiste à prévoir d’abord une montée en compétences des équipes sur des petits projets à plus faibles enjeux, avant de déployer la méthode agile sur un projet de transformation profonde de l’entreprise.

  • Une approche un peu plus risquée, qui consiste à mener directement en agile un grand projet de transformation quand bien même 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. Pour maîtriser le risque lié au manque de maîtrise de la méthode, il faut prévoir un coaching agile de proximité.

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 Quarterly meeting (ou PI Planning(8) dans le jargon SAFE) s’avère être dans ce cas, un outil très utile pour coordonner les équipes, partager la vision, planifier les travaux, et identifier les adhérences.

Enfin, si des freins à la colocalisation existent, en particulier dans un contexte d’équipe multisites, il est indispensable d’utiliser des outils collaboratifs (ex : JIRA, confluence, Skype…), même s’ils ne remplaceront jamais la communication non verbale et la relation en « face à face ». Dans ce cas je préconise d’investir dans les déplacements en début de projets, afin de créer le liant qui permettra de travailler à distance par la suite.

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 : création de valeur, pensée orientée client, adaptation au changement, culture de l’expérimentation et droit à l’échec…

Toutefois les freins organisationnels au déploiement de l’agilité sont nombreux et de plusieurs natures : coordination, gouvernance, logistique et compétences. Ces difficultés doivent être anticipées pour que la méthode agile ait bien un effet d’accélérateur, et ne devienne pas un facteur d’inertie.

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 ». Autrement dit, 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, finalement cela ne marche pas. J’ai effectivement souvent été témoin de comportements « non agiles » dans un contexte projet dit « agile », qui illustrent la distinction « méthode vs état d’esprit » :

  • Daily meeting vécus comme une corvée
  • 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 contenter l’équipe de développement
  • 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 non acculturés, 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
  • Multiplication des points d’avancement et des reporting demandés par la Direction, et « 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 certaines de ces situations vous parlent, ou si vous souhaitez tout simplement échanger sur ce sujet passionnant, n’hésitez pas à me contacter.

Sofiane Sahraoui

Sofiane Sahraoui

E-mail : ssahraoui@rbpartners.com

Tél : 06 82 18 33 12

Cliquer ici pour découvrir notre offre

Lexique
(1) KANBAN : représentation visuelle du traitement et de l’état d’avancement d’un flux de stories
(2) Backlog : descriptif du produit avec toutes ses fonctionnalités
(3) JIRA : outil de gestion de projet, dans lequel le backlog est administré
(4) Release : nouvelle version d’un produit, ou nouvelle livraison informatique
(5) Sprint : itération de travail
(6) Technical Story : besoin technique
(7) Refactoring : « nettoyage » de code
(8) 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