L’agilité est un principe de management privilégiant les approches empiriques, légères et adaptatives par opposition aux approches prédictives souhaitant définir avant toute action l’intégralité des spécifications, modalités de validation, budgets, risques et moyens de s’en prémunir.
Pour comprendre sa mise en œuvre en tant que principe de management, il peut être intéressant de se pencher sur ce qui a conduit à son éclosion : la gestion de projets.
Notions de base de projets
Selon le Project Management Institute, un projet est une entreprise temporaire décidée dans le but de créer un produit, un service ou un résultat unique.
Les compétences de pilotage d’un projet sont multiples :
Livrer un contenu de qualité correspondant aux besoins du commanditaire
Estimer et maitriser les délais 4 Estimer et maîtriser les coûts
Manager les ressources humaines engagées ou impactées
Un projet se confronte à des contraintes, pour la plupart identifiables, et à la survenance d’évènements non prédictibles. La gestion du risque est donc une composante incontournable du pilotage de projets, elle s’ajoute aux gestions du contenu, du délai, du coût et des ressources humaines.
Les méthodes prédictives de gestion
Une approche naturelle de la gestion de projet est celle dite « en cascade ». Selon une approche de bon sens – « une chose après l’autre » – les étapes se succèdent dès lors que la précédente a été achevée. La maîtrise du temps unitaire de chacune des étapes permet d’organiser leur cadencement et donc de prédire l’exécution de telle ou telle tâche.
La principale limite de cette manière de travailler est dans le manque d’anticipation des étapes suivantes, dont l’exécution peut révéler des éléments amenant à modifier voire à recommencer le travail déjà réalisé.
Le cycle en V
Ce manque de visibilité et d’adaptation a un temps trouvé sa réponse dans le cycle en V. Son principe est de rédiger l’intégralité des spécifications d’une manière descendante, du général au particulier, puis de contrôler de manière ascendante, du particulier au général, le travail réalisé et sa conformité aux dites spécifications.
De la même manière, les risques et solutions de réductions de leurs impacts sont anticipés et formalisés. L’ambition de cette méthode est par un travail intellectuel préparatoire de baliser le chemin du projet afin de diminuer la probabilité et la gravité de survenance d’un élément susceptible de changer le périmètre ou la viabilité du projet.
Les limites d’un cycle en V sont :
La rigidité de l’approche.
La sur-documentation. L’organisation définit au préalable les détails de conception, toutes les procédures de contrôle et tous les risques dont on devra se prémunir, puis généralement contracte avec son commanditaire ou ses prestataires sur la base de ces définitions, rajoutant au document produit un poids juridique certain. On s’engage donc bien volontiers dans un processus de documentation fort, pour se prémunir de ce risque juridique.
L’effet tunnel. La dérive naturelle des organisations gouvernées ainsi est de se focaliser sur le bon franchissement des étapes selon le formalisme requis en omettant de s’assurer que le travail réalisé correspond toujours aux besoins du commanditaire.
Malgré la capacité d’anticipation voulue par le cycle en V, cette méthode rejoint l’approche en cascade sur un heurt majeur : repousser la confrontation aux marchés et aux risques. Ce n’est que dans la présentation au client que l’on saura si le projet est bon, et ce n’est qu’en menant des tâches opérationnelles que l’on progresse dans l’identification et le contournement des risques.
Le besoin du commanditaire
Deux suppositions peuvent être contestées :
L’organisation va réussir à traduire tous les besoins du client en spécifications. Un prérequis est que le client maitrise parfaitement et totalement son besoin. Ce qui n’est pas le cas le plus courant, même dans les organisations les plus évoluées. Si de surcroît l’organisation travaille avec une clientèle grand public, la chose devient tout simplement impossible. Il faut ensuite réussir la traduction de ce besoin en spécifications et que ces spécifications soient la parfaite image du besoin. Cela n’est tout simplement jamais le cas. Une fois la réponse traditionnelle des cycles en V évacuée (consistant à contractualiser cette étape afin de contraindre le client à accepter le produit s’il est égal à la spécification), la contradiction est simple : ça n’est pas parce que le client reconnait que le processus s’est bien déroulé qu’il en est satisfait.
Les besoins du client n’évolueront pas entre le début et la fin du projet. Cette assertion est de fait contestable par la survenance d’éléments exogènes. Et plus le projet s’étale dans le temps, plus la probabilité d’apparition d’une information contestant tout ou partie du périmètre du projet est forte, quelle qu’en soit la source : modification de l’organisation du client, évolution réglementaire, mouvement sur le marché, etc. Par ailleurs, la compréhension qu’a le client de son propre besoin progresse en en voyant la réalisation. Il en comprend alors mieux les contours et par l’usage qu’il projette de faire du livrable oralise des évolutions nécessaires à celui-ci.
A moins de choisir de ne travailler qu’avec des commanditaires dont la maturité et l’organisation sont telles qu’ils savent œuvrer avec l’intégralité des contraintes énoncées précédemment, on comprend que les méthodes prédictives ont principalement pour conséquence de rigidifier la gestion projets pour le conduire vers une livraison insatisfaisante, sur-documentée, sur-contrôlée et donc trop chère.
Quelles sont donc les solutions ?
Inclure le client au plus tôt dans le processus de production du livrable, incrémenter les livraisons en s’appuyant sur ses retours, se focaliser au plus vite sur l’exécution opérationnelle des tâches à valeur ajoutée.
Historique des méthodes agiles
La naissance des approches agiles peut se dater en 1986, bien que ce qualificatif n’apparût que plus tard. Fait qui peut surprendre tant les méthodes agiles sont dans l’esprit de chacun liées au développement logiciel, la première publication d’une méthode incrémentale survint dans l’industrie. Ce n’est pas le seul emprunt que le monde du logiciel fit à celui de l’industrie, notamment sur le sujet du management agile.
En 1991, la méthode RAD (Rapid Application Development) est formalisée. L’XP (eXtreme programming) fait ses premiers pas en 1996, ces deux approches exploitant à leur manière le concept d’agilité adapté au monde du logiciel.
En 1995, la méthode Scrum est formalisée. Elle est aujourd’hui la plus usitée et la plus documentée et nombreux sont ceux qui, dans un pur esprit d’agilité, ont adapté ses principes au fonctionnement de leur organisation.
Enfin, en 2001, le manifeste agile est publié, expression des principes fondamentaux de cette approche.
Définition d’une méthode agile
En soit l’agilité relève plus d’un esprit que d’une définition rigoureuse ; voici cependant une proposition de définition :
« Une méthode agile est une approche itérative et incrémentale. Elle est menée dans un esprit collaboratif, avec juste ce qu’il faut de formalisme. Elle génère un produit de qualité prenant en compte l’évolution des besoins des clients ».
Le manifeste agile propose quatre valeurs fondamentales de l’agilité ; elles sont clé dans le déploiement d’une telle approche.
Les individus et leurs interactions avant les processus et les outils. La force principale d’un projet ou d’une organisation réside dans les individus qui la constituent. Le principe fondamental d’une méthode agile est de favoriser au maximum les échanges en ne formalisant que le minimum nécessaire.
Des fonctionnalités opérationnelles avant la documentation. L’idée de tout projet, de toute organisation est de livrer des éléments à valeur ajoutée pour le client. Pourquoi perdre du temps à écrire ce que l’on va faire s’il est plus rapide et plus concret de commencer à le faire ?
Collaboration avec le client plutôt que la contractualisation des relations. En incluant le client dans le processus de production et en le faisant valider au fur et à mesure de l’avancée que le travail réalisé le satisfait, la contractualisation initiale telle qu’elle est entendue dans un cycle en V devient caduque.
Acceptation du changement plutôt que conformité aux plans. Le principe de l’agilité est de produire le livrable le plus satisfaisant possible. Le résultat que l’on espérait au début ou la manière dont on comptait s’y prendre sont nettement secondaires par rapport au besoin impérieux de produire la plus forte valeur ajoutée accessible.
Avec ces quatre grands principes, il est possible de construire soi-même une approche agile. Le reste n’est que commentaire.
Comment intégrer le client dans le processus de production ?
L’idée est d’arriver à produire au plus vite le produit minimal que l’on peut montrer au client afin d’avoir au plus tôt ses retours et de l’améliorer dans le sens de l’utilisation qu’il en fait ou qu’il projette d’en faire. Idéalement, ce produit est commercialisable, même sous cette forme dégradée, mais cela n’est pas nécessaire si l’organisation est confrontée à des cycles longs. Ce produit est appelé MVP, pour Minimum Viable Product.
Il est possible d’objecter qu’atteindre rapidement un MVP n’est valable que dans le monde du logiciel, et encore que pour les produits ou services légers. Auquel cas, il est capital de produire des maquettes, des mises en situation, des POC (Proof Of Concept), tout ce qui peut être souhaitable et adapté au marché convoité. Pour s’en convaincre, il suffit de regarder un univers dont les cycles de conception sont très longs : la santé, que ce soit pour la partie médicamenteuse ou technologique. Dans les deux cas, l’urgence est la même, avant toute ambition d’évocation de production en série, seul le test en laboratoire importe. Et petit à petit, on incrémente. Par des simulations, des tests sur volontaires en petit groupe, puis des tests à plus grande échelles, des publications pour mettre en compétition les idées et résultats obtenus avec ceux des autres groupes de recherche.
Dès que l’on a présenté au client, au commanditaire, à leur représentant ce MVP, ou les éléments y conduisant, un nouveau cycle commence. Il permettra de construire de nouvelles fonctionnalités et / ou de modifier les éléments produits pour tenir compte des retours du client. Puis on remontre au client, écoute ses retours et on recommence un nouveau cycle. Et ainsi de suite, jusqu’à l’obtention d’un produit satisfaisant.
La différence entre une méthode prédictive et une méthode adaptative peut se résumer avec le schéma suivant :
Comment déployer une méthode agile ? Le cas Scrum.
La méthode la plus usitée est Scrum. Sans rentrer dans les détails de sa mise en place, en voici les quelques principes généraux.
L’idée du scrum est que toute l’équipe avance au rythme de la mêlée, traduction française du nom de la méthode.
La livraison est rythmée par des périodes de 3 à 4 semaines que l’on appellera sprint. Un sprint a pour vocation de réaliser un nombre de tâches définies en début de sprint. Ces tâches sont principalement (et idéalement uniquement) orientées vers la production de valeur ajoutée pour le client. Tout ce qui n’est pas de destination opérationnelle est à proscrire (attention toutefois : un manuel d’utilisation si l’on réalise un produit grand public peut – et uniquement peut, avez-vous un manuel pour votre smartphone ? – avoir de la valeur ajoutée).
Chaque jour, une réunion rapide permet aux intervenants de faire un point sur ce qui a été fait et ce qui reste à faire. L’équipe doit rester concentrée sur la réalisation de tâches et uniquement la réalisation de tâches.
Le suivi se fait par le nombre de tâches réalisées et le nombre restant à faire. La consommation d’heures ou de budget n’est pas la priorité à ce niveau-là : seul compte la production d’éléments à valeur ajoutée.
Chaque sprint se conclue par une présentation au client et un bilan du sprint. Les retours du client sont un des éléments d’entrée de la planification des prochains sprints.
Toutes les tâches seront évaluées en valeur ajoutée pour le client et en charge relative de travail. Rien ne sert d’être précis ! L’important est de savoir combien de tâches il est possible de réaliser en un sprint. Il sera ainsi aisé de déduire le nombre de sprints nécessaires à la livraison du produit.
Idéalement, si l’organisation est en mode projet, le projet aura une salle dédiée, dans laquelle les outils de management visuel seront privilégiés.
Tout le monde partage la vision du reste à faire et des tâches validées. Elles sont, si elles existent, affichées en permanence sur les murs de la salle dédiée.
Le management visuel pourra par exemple s’appuyer sur des cartes, des papiers autocollants, que l’on déplace étape après étape (par exemple : production de maquettes graphiques, réalisation technique, validation). Ce système s’inspire du Kanban que l’on peut retrouver dans l’industrie.
Et le lean ?
Le Kanban comme support visuel du suivi de projet vient d’être évoqué. D’autres méthodes apparues dans l’industrie manufacturière sont venues enrichir les méthodes agiles. C’est le cas du lean.
Le principe du lean est d’éliminer tout surplus (les stocks par exemple), tout travail ou toute étape ne produisant pas de valeur ajoutée pour le client. Toute l’organisation doit s’amaigrir pour favoriser l’opérationnel. La littérature liste sept sources de gaspillage : surproduction, attentes, transport, étapes inutiles, stocks, mouvements inutiles, corrections/retouches.
Le lean, dans son combat contre la sur-production et le gaspillage, rejoint ici les approches agiles qui luttent contre les excès de la sur-documentation et qui se concentrent sur les tâches à valeur ajoutée pour le client.
Le lean fait maintenant partie intégrante de l’agilité dans sa compréhension moderne et ces deux approches se nourrissent.
En quoi l’agilité permet-elle de gagner du temps ?
La réponse à cette question s’est dessinée au fur et à mesure de cet article.
Le constat de la documentation inutile a été formulé, dont la suppression est une source non négligeable de réduction des délais.
La participation et l’implication du client au plus tôt dans le processus permettait de produire plus facilement une livraison correspondant à ses attentes et surtout à ses évolutions. L’organisation limite ainsi la réalisation de tâches n’apportant pas de valeur ajoutée au client, et gagne donc du temps.
Les systèmes de management visuel, concentrés sur le suivi des tâches à valeur ajoutée, permettent de raccourci les délais d’échanges et de transmission d’informations.
Ces trois facteurs clés, combinés à la pratique et la saine compréhension des quatre principes du manifeste agile permettent de transformer des organisations entières.
Mais tout ça ne serait rien sans l’enseignement fondamental : l’échec n’est qu’une variable d’entrée du processus de progrès. Au plus tôt il sera identifié, au moins il sera coûteux et au plus il sera porteur d’apprentissage. On le comprend bien : dans un projet d’un an, découvrir un point critique au bout d’un mois est contrariant, le découvrir au bout de dix peut mettre en danger le projet – voire l’entreprise dans son intégralité.
Une idée forte de l’agilité est donc de créer toutes les conditions permettant d’échouer le plus vite possible afin de déterminer avec célérité les voix fructueuses. Les américains résument cette idée en une phrase à adopter comme mantra : « Fail often, fail fast ».
Et enfin, en cohérence avec le quatrième principe, il est nécessaire de retenir cette nécessité pour prendre le virage de l’agilité : ne pas être dogmatique. Même avec les méthodes agiles. Même avec ce qui a été décrit dans cet article. C’est l’adaptation des idées à l’organisation qui en fera la souplesse, pas les méthodes préconçues, aussi puissantes soient-elles.
Votre organisation peut maintenant mener des projets agiles.
Mieux encore, votre organisation peut dans son ensemble devenir agile, en guidant son action managériale avec les mêmes principes. Lancez-vous !
Testez et éprouvez, remettez en question, concentrez-vous sur la valeur ajoutée.
Ne tenez rien pour acquis, mais profitez des expériences passées.
Echouez.
Constatez.
Apprenez.
Partagez.
Recommencez.
Réussissez.
Bienvenue dans une entreprise agile.