Les méthodes agiles se sont répandues dans de très nombreuses organisations. Mais, dans les faits, elles ne sont pas toujours mises en pratique correctement. Des critiques virulentes s’élèvent même contre elles, sous forme notamment d’un manifeste anti-Agile. Nos recommandations en cinq points pour ne pas s’égarer.
Dans le cadre de nos missions au sein des grands groupes, nous constatons que seule une infime partie des projets met réellement en œuvre les méthodes agiles. D’autres, sans oser le dire ouvertement, de peur d’être taxées de conservatisme, portent un jugement très négatif sur ces méthodes.
Les raisons ? Elles sont multiples ! Mais d’abord parce que le mode "Agile" remet en cause l’organisation même des entreprises et leurs traditionnels organigrammes. Où placer un scrum master ou un product owner dans une organisation 100% verticale ? Quelle place, quel espace laisser à des "squads", des "tribus" qui opèrent de manière autonome pour mener à bien leurs projets ?
Et pourtant, les méthodes agiles ont colonisé le vocabulaire employé dans de très nombreuses DSI et directions métier. On parle de "stories", de "sprints". Nombreux sont ceux qui s’improvisent "scrum master" ou "product owner" le temps d’un projet. Bref, on en parle beaucoup mais dans les faits, cela ressemble tout bonnement à de l’ "Agile washing".
Agile : des bénéfices indéniables
Les bénéfices des méthodes Agile ne sont pourtant plus à démontrer. Selon un rapport du Standish Group datant de 2015 et couvrant 50 000 projets à travers le monde, les projets menés en Agile sont davantage couronnés de succès que les projets menés en mode "cascade" (gestion de projet traditionnelle). La différence est significative : 28 points de taux de succès en plus pour les projets réalisés en agile (39% versus 11%), quelle que soit la taille du projet.
Jeff Sutherland, un des inventeurs de la méthode Scrum, rappelle que 50% des entreprises utilisant les méthodes Agile dans leurs projets les utilisent mal. En cinq étapes, notre propos est ici de mentionner plusieurs points de vigilance qu’il faut avoir dans la "check-list qualité" de son projet. Nous mettons en exergue par la même occasion les bonnes pratiques qu’il nous semble essentiel d’appliquer.
1) Définir clairement son besoin
Le manifeste Agile date de 2001. Les termes spécifiques liés aux méthodes Agile sont rentrés dans le langage professionnel courant. Les mots "stories", "sprints", "scrum master", "product owner" sont dans presque toutes les bouches des gestionnaires de projet… Mais ce n’est pas parce qu’on jargonne "Agile" qu’on utilise véritablement ces méthodes.
Ce constat s’applique aussi quand on parle de la définition du besoin. Ce n’est pas parce qu’un des grands principes de l’Agile est de fournir "juste ce qu’il faut de documentation" qu’il ne faut produire aucun document ou qu’il faut s’en tenir à une série de post-it collés sur un mur.
Si, pour être parfaitement compris de ses interlocuteurs métiers ou IT, il est nécessaire de produire des schémas UML poussés, ces schémas doivent voir le jour. Si, dans un projet e-commerce, le cycle de traitement des commandes doit être décrit de manière très fine, il ne faut surtout pas faire l’économie de cette étape, bien au contraire. Même raisonnement dans un projet CRM pour décrire les conditions d’envoi de certains messages.
Une citation d’Albert Einstein illustre à merveille ce point : "Everything should be made as simple as possible, but not simpler".
Lors de cette production "raisonnée" de documentation, le focus doit être prioritairement mis sur l’intérêt business, la vue d’ensemble. Chiffrer la création de valeur attendue pour les différentes stories est plus stratégique que de se perdre dans des détails que personne ne lira jamais.
Formuler clairement son besoin passe aussi par une description précise du résultat final que l’on attend. Par exemple : "Permettre à un abonné de recommander l’utilisation du service à un proche. L’abonné et son ami bénéficient tous les deux de 10 euros de remise."
Chez Google, la définition des spécifications se fait lors d’un sprint de design qui dure cinq jours. Les différentes étapes, d’une journée chacune, sont les suivantes : Unpack, Sketch, Decide, Prototype, Test.
En synthèse :
2) Organisation Agile : protéger le leadership des personnes clés
Tout comme l’utilisation à tort et à travers de mots ou de concepts Agile, la mise en œuvre d’une organisation inspirée des méthodes Agile au sein d’une entreprise "traditionnelle" mène souvent à l’échec. Il ne sert en effet à rien de plaquer une organisation Agile, qui implique notamment de désigner des scrum masters et des product owners, sur un organigramme traditionnel.
Pour peu que ces personnes ne soient pas géographiquement au même endroit ou que leur périmètre respectif se chevauche, leur leadership a de fortes chances d’être mis à mal. Il arrive également trop souvent de désigner des personnes en charge d’assumer ces rôles en plus des rôles traditionnels (directeur de projet, chef de projet, business analyst) qui reviennent à d’autres personnes.
Se pose alors la question du périmètre de responsabilité des acteurs et de leur leadership, qui est un point crucial, quel que soit le mode de gestion de projet retenu. Si le leadership est dilué entre trop de personnes, au sein d’une structure où les périmètres s’entrechoquent, le projet en sera fragilisé.
Rappelons-nous ce que disait Keynes en 1936 dans "The General Theory of Employment, Interest and Money" : "Les arbitrages des agents économiques s’appuient davantage sur le Spiritus Animalis (mimétisme, confiance en un tiers) que sur une évaluation quantitative (coûts / bénéfices)".
Les différentes parties prenantes doivent identifier facilement qui prend quelle décision, sans quoi des discussions interminables par e-mails ou en comités peuvent ralentir ou faire échouer un projet.
Fonctionner en "squads" pour éviter les effets tunnel
Plus globalement, nous recommandons de créer des groupes projets travaillant sur des fonctionnalités clairement identifiées ou sur des sous-projets différents les uns des autres. Cela permet de découper les gros projets en sous-ensembles plus maniables et d’éviter les taux d’échec très élevés associés aux grands projets (cf l’étude du Standish Group citée plus haut).
Spotify, un des principaux acteurs mondiaux du streaming musical, est passé maître dans ce type d’organisation Agile. Des équipes de taille réduite, les "squads", sont constituées pour travailler sur des périmètres réduits.
En synthèse :
3) Définir et suivre un planning sur la durée
Les projets réalisés en entreprise doivent être coordonnés entre eux, pour articuler leurs dépendances et s’intégrer dans des programmes budgétaires annuels. Or, les méthodes Agile reposent sur des "sprints" qui durent le plus souvent entre une et quatre semaines. Ainsi, les projets agiles pâtissent souvent du manque de visibilité induit par ce mode de gestion, lorsqu’il est appliqué de manière trop abrupte.
Les "sprints" reposent eux-mêmes sur un système de points permettant d’évaluer la complexité d’un élément à développer. Difficile, a priori, avec ce système, de donner à un directeur de business unit ou à un comité de direction une date de livraison estimée en nombre de sprints ("Nous livrerons le nouveau site dans 15 sprints").
Pour pallier cela, nous préconisons de maintenir constamment à jour un outil de gestion de projet "traditionnel" permettant de construire une vue d’ensemble. En effet, il est primordial de définir dès le début du projet une vue d’ensemble en termes d’échéances à respecter et de ne pas se limiter aux premières semaines, aux premiers sprints. Cela permet de calculer en permanence la vélocité du projet et d’ajuster sa durée en fonction de l’apprentissage réalisé.
Un élément clé de cet outil est la matrice de gestion des risques détaillant les risques encourus, leur probabilité de réalisation et les actions de contournement possibles. Didier Hallépée, auteur français de livres techniques, déclare que "Le pire des risques est celui dont vous ignorez l'existence." La matrice de gestion des risques est là pour empêcher ce risque ignoré de se produire.
Enfin, les méthodes Agile, comparativement aux méthodes en cascade, permettent de réaliser des arbitrages fins (coûts / bénéfices) à tout moment. Ces arbitrages évitent de rester bloqué sur un périmètre négocié en début de projet sans pouvoir le faire évoluer.
En synthèse :
4) Réussir ses estimations
Une bonne estimation du temps de réalisation est la pierre angulaire de la réussite d’une méthode de gestion de projet, quel que soit le domaine. Douglas Hofstadter, universitaire et écrivain américain, déclare dans son livre "Gödel, Escher, Bach : Les Brins d'une Guirlande Éternelle" (1979) que les ingénieurs ont toujours tendance à minimiser les temps de développement (loi d’Hofstadter). "Cela prend toujours plus de temps que prévu, même quand vous prenez en compte cette loi", explique-t-il dans son ouvrage"
Il est donc nécessaire de mettre en place des garde-fous. Les revues collectives en sont un qui est efficace. Faire réaliser des estimations par le scrum master ou un ingénieur expérimenté, sans revue collective ou intervention des équipes de réalisation, est une erreur qui survient trop souvent.
Il faut également éviter de négliger le temps nécessaire à la production des estimations dans le planning : produire une évaluation fiable est un travail d’analyse, qui nécessite souvent de réaliser une partie de la conception.
La qualité des estimations doit être un sujet central dans les réflexions liées à l’optimisation des méthodes, tout au long de la vie des projets. On pourra ainsi identifier les causes des problèmes d’estimations pour éviter que les problèmes ne se reproduisent : spécifications incomplètes et / ou imprécises, mauvaise méthode d’estimation (…).
Au-delà des méthodes d’évaluation par comparaison avec des tâches similaires, ou par décomposition analytique, créer un prototype est un bon moyen d’estimer.
En synthèse :
5) Technologie : conserver du temps pour les tâches techniques
Réaliser un projet en mode agile ne signifie pas forcément qu’il faille commencer à développer dès le premier jour. Les projets ont souvent besoin d’une phase de cadrage ou d’initialisation pour se mettre d’accord sur les objectifs, les méthodes, choisir les outils… Ainsi, on démarre souvent un projet agile par un Sprint "zéro", qui ne prévoit pas forcément de développement et durant lequel on réalise les choix d’outils s’ils n’ont pas été faits avant.
Ensuite, durant la vie d’un projet, en pleine réunion de planification des sprints, on peut être confronté à des choix cornéliens. Par exemple, choisir entre développer la brique "panier" (haute valeur business) et mettre en place des tests automatisés. Si l'on mesure l’avancement du projet uniquement en s’appuyant sur la valeur Business créée, on aura tendance à privilégier la brique "panier".
Et pourtant, en Agile, les tests automatisés revêtent une importance particulière. Sans eux, le risque est grand d’accumuler des régressions et, par voie de conséquence, de ne pas pouvoir développer autant de fonctionnalités que prévu en raison d’une dette technique croissante.
Une pratique efficace consiste à conserver un stock de points à chaque sprint pour les tâches liées à la qualité plutôt que de les intégrer à la brique fonctionnelle correspondante. En effet, trop souvent, si l’on intègre la documentation et les tests à l’estimation d’une tâche à développer, ces activités deviennent les variables d’ajustements qu’on ne réalise pas pour "tenir le planning".
En synthèse :
Conclusion
Bien mises en œuvre, les méthodes agiles permettent d’obtenir des résultats bien supérieurs aux méthodes en cascade. Mal mises en œuvres et servant d’alibi à une gestion prétendument débarrassée de toute lourdeur (comités de décision, documentation, fiches de suivi…), elles aboutissent bien évidemment à des résultats décevants, voir catastrophiques.
En effet, les méthodes agiles ne sont pas magiques ! Elles ne permettent pas de modifier les "grandes lois de la physique" de tout projet : le célèbre triangle qualité / coût / délai, qui nous rappelle que ces dimensions sont liées (quelle que soit la méthode choisie).
