Depuis leur première apparition à la fin des années 90, les méthodes agiles (Scrum, Extreme Programming…) ont progressivement pris le pas sur les méthodes dites traditionnelles (cycle en V, Waterfall,…). Le processus itératif de l’approche Agile, propice à la réactivité, favorisant la communication et l’échange des intervenants au projet, semble gommer les inconvénients de la gestion de projet de type classique, et son fameux et fumeux « effet tunnel ». Représente-t-il pour autant systématiquement la meilleure des démarches ?
Au travers des aspects organisationnels, matériels et humains, quel serait le résultat d’un combat des méthodes de la gestion de projet ? Un combat perdu d’avance ou une lutte acharnée ? Let’s get ready to rumble !
Réactivité face au changement : l’approche Agile par KO
C’est incontestablement la grande force et l’intérêt principal de ces procédés. Même si l’essentiel des « user stories » (US) s’élaborent au lancement du projet, celles-ci sont revues, complétées, modifiées et hiérarchisées régulièrement au cours des divers sprints. L’Agile respire le changement, vit par et pour le changement. Une incompréhension entre business analyst et développeur ? Une nouvelle demande du client ou une modification de ses besoins ? No problemo, on s’adapte au prochain sprint ! Attention néanmoins à ne pas en abuser, être flexible ne signifie pas pour autant ne pas être responsable et conscient des impacts coûts / délais / qualité.
A l’inverse, on observe généralement une résistance, voire une opposition, face au changement dans les processus du cycle en V, toutes modifications des besoins, de l’environnement ou du contexte entraînant un retour aux phases précédentes, aux conséquences lourdes et immédiates. A cela s’ajoute également une détection des changements plus lente qu’avec l’Agile où les périodes successives d’élaboration / tests / mise en production permettent une mise en lumière plus rapide des bugs et correctifs à apporter. C’est bien connu, il fait sombre dans le tunnel…
Cycle de vie et suivi de projet : victoire Agile aux points
L’intérêt majeur de l’Agile, et non des moindres, est le time to market très réduit. Au lieu d’avoir la voiture de mes rêves dans 9 mois, je veux bien commencer par une trottinette pour faciliter mes déplacements (dans les 15 jours hein, je n’aime pas trop marcher!). Puis dans un mois, j’aimerais bien disposer du châssis et des quatre roues, et pouvoir par la suite, pourquoi pas, installer des sièges en cuir à la place du tissu comme prévu au départ… Le processus itératif de l’Agile, pierre angulaire de la méthode, semble balayer tout sur son passage.
Sauf que… sauf que… tous les projets ne s’y prêtent pas ! Imaginons un outil (dans le cadre d’un projet de type réglementaire, de contrôle par exemple) qui doive exécuter successivement cinq étapes pour obtenir un résultat pertinent. Si l’on considère que le besoin ne sera pas modifié (avant la prochaine loi ou directive par exemple), le client ne pourra retirer aucune utilité ou aucune satisfaction d’un outil qui ne couvrirait que deux de ces étapes, et ce, même dans un délai très rapide. Autrement dit, il n’est pas toujours possible, ni même souhaitable, de dégager une succession de Minimum Viable Product. Il existe ainsi des situations où ce MVP est le produit fini. Hormis le fait de respecter un standard de l’entreprise, la mise en place d’un projet autre qu’en cycle en V n’aurait pas grand intérêt.
En revanche le suivi de projet apparaît facilité avec une mise en place Agile, notamment à travers le prisme du management visuel que ces approches peuvent amener. Si le projet met en place les méthodes Scrum avec stand up meetings et tableaux synthétiques d’avancement, le product owner (PO) peut se rendre compte à tout moment de l’état d’avancement du projet. Sa participation à ces meetings, régulière ou occasionnelle, est une opportunité de prise rapide d’information. En complément, les démos organisées régulièrement donnent une bonne indication de ce qui a été fait, ce qui ne fonctionne pas encore ou ce qui nécessite d’être revu. A l’inverse, la non implication du PO au sein de projet, pour en définir les priorités ou clarifier les besoins, est finalement un obstacle majeur pour la bonne marche du projet. C’est un rôle clé dont la réussite du projet dépend en grande partie. La meilleure équipe du monde au sein de la plus efficace organisation ne pourra rendre rien de très viable si le PO ne participe pas.
Mise en place et organisation : victoire cycle en V aux points
C’est sans doute sur ces points que la gestion dite traditionnelle de projet peut encore être compétitive. Le cycle en V est assez simple finalement à mettre en place : des meetings réguliers entre les divers stakeholders pour le pilotage et suivi, des outils de suivi budgétaire, des templates de documentation (expressions de besoins, spécifications…) ou d’une revue d’Architecture. Il convient pour de petits projets, dans des firmes brick and mortar au sens large, peu familières ou pas intéressées par les technologies plus avancées. Aucune formation particulière n’est exigée.
Bien que proposant de nombreux avantages, l’Agile n’est pas facilement et rapidement adaptable from scratch. Un accompagnement par un coach est indispensable pour se familiariser avec ses pratiques ainsi que sa mise en œuvre, même après l’implémentation initiale. Parallèlement, la phase initiale d’élaboration des US, de la roadmap et des MVP, de la constitution du backlog sur l’outil dédié (e.g. JIRA), du tableau d’avancement des tâches, est finalement très lourde et indigeste. Les heures passées à la préparation des prochains sprints, aux démos et aux rétros / feedbacks de fin de sprint, constituent autant de temps prélevé à la bonne marche du projet, même si ces étapes sont nécessaires pour bénéficier des avantages détaillés auparavant.
Ce qui fait pencher la balance vers la méthode traditionnelle qui, de mon point de vue, s’articule en deux points. Le premier est la difficulté d’organiser au quotidien certains aspects de l’Agile (le Stand Up par exemple) dans un contexte de multi-site, ce qui est le cas de bon nombre de grandes firmes. L’échange et le partage de l’Agile, bénéfices mais également prérequis de la méthode, s’en trouvent forcément affectés dans le cas où les ressources ne se trouvent pas au même endroit, à fortiori pas dans le même pays. Ce qui est bien sûr aussi le cas pour le cycle V mais dans une moindre mesure. Le second point est la nécessité d’avoir une équipe de production ou une capacité de livraison en haute disponibilité. Dernier obstacle avant la production et l’aboutissement de son projet / du sprint, la relation avec l’infrastructure et l’équipe de production, parfois sensible. Si cette fonction est intégrée au sein de l’équipe projet, qui dispose de tous les outils pour effectuer la livraison elle-même et à tout instant, alors c’est le Graal : l’optimum de l’Agile et de la gestion de projet en général peut être atteinte avec le continuous delivery. A l’opposé, un projet devant passer toutes les étapes d’un processus lent de mise en production peut ruiner les efforts produits jusqu’alors. Planifier les livraisons bien à l’avance, vérifier les disponibilités des ressources, livrer sur le back up suivi de tests pour enfin aboutir à la livraison définitive peut vite tourner à la longue agonie. L’intérêt des méthodes Agiles, et l’amélioration de l’efficacité et de la productivité que celles-ci apportent, peut être fortement atténué par la rigidité et l’inertie des équipes en aval.
Et l’humain dans tout ça ? Victoire Agile aux points
La forte collaboration des équipes d’un projet Agile est essentielle à son bon fonctionnement. Ceci participe à l’émancipation des individus au sein de l’équipe en augmentant les échanges et le partage d’information, qui facilite en outre l’intégration de nouveaux arrivants. Les livraisons régulières de fonctionnalités maintiennent aussi la motivation de l’équipe, à l’inverse des projets en V où il faut attendre de longs moments avant la réalisation finale, la mise en production.
Côté documentation, l’Agile la réduit au minimum. Finies les spécifications soporifiques. Notons cependant que son usage peut freiner la transmission d’information à un nouvel arrivant qui devra souvent parcourir le code pour appréhender règles de gestions et fonctionnement général de l’outil. Cela devient plus complexe pour les personnes plus fonctionnelles non familiarisées aux langages de programmation.
Enfin, nous l’avons vu, si le management visible du tableau du stand up meeting peut représenter un certain avantage, il souffre de quelques points négatifs. Pour les plus récalcitrants à la démarche, il est parfois l’occasion de démontrer une surveillance, une intrusion trop forte du manager aux tâches de l’individu. Le processus de déplacement de tickets, de post-its peut aussi être perçu comme infantilisant.
And the winner is
L’Agile remporte le combat, sans grande surprise. Pour autant, le rapport de forces n’est pas aussi déséquilibré qu’il y paraît, à priori. Il existe des situations où les méthodes traditionnelles semblent être plus efficaces. Dans un monde où la part du digital et du numérique est en forte expansion, où la réactivité et la flexibilité sont les maîtres mots de nos économies, tout porte à croire que ces approches, dites classiques, s’effaceront totalement. Les quelques défauts des méthodes Agiles ne feront-ils pas l’objet d’ajustements et de correctifs pour aboutir à une méthode totalement en phase avec ce monde mouvant ? N’est-ce pas là tout l’intérêt de l’approche ?
Vos commentaires
bonjour,
j’y suis en plein dedans.
dans le cadre de la mise en place d’un ERP, j’ai 1500 jours hommes de dev sur les gap analysis.
je suis en train de déterminer avec mon éditeur quelle méthode utiliser pour chaque gap.
et j’ai vraiment du mal à définir quelles critères utiliser pour faire mon choix.
cordialement.
Bonjour,
Merci pour votre commentaire.
Il s’agit donc d’un programme découpé en n sous-projets? Difficile dans ce cas d’opter pour une partie en V et une autre en Agile je pense (même si je ne connais pas le contexte), pourquoi pas couper la poire en deux et intégrer un peu des deux?
Cdt
Bonjour,
Le mélange des deux ne se rapprocherait-t-il pas d’un cycle en spirale ?
Bien cordialement,
Olivier HENRY.
Bonjour,
L’analyse faite ici est un peu manichéenne et simpliste, elle tombe des les grands préjugés habituels waterfall vs agile. Les grand oubliés sont le cadre contractuel et l’équipe avant la méthodologie. Une équipe qui sait gérer ses priorités, sa relation client, son cadre contractuel, son savoir faire technique, l automatisation des tâches arrive au but avec succès que ce soit en cycle en V ou en agile. Les concepts souvent décrits comme étant propres à l agile sont tout à fait applicables au cycle en V (priorisation, lotissement, adaptabilité, ttm, automatisation, écoute des différents acteurs, …). Plus que la méthodologie c’est le fait que tous les acteurs avancent dans le même sens qui garanti ou non le succès final. Ce que l’on oubli souvent dans les effets secondaires des méthodologies agile comme Scrum : créativité plus restreinte (ce qui est logique vu que l’on veut maitriser la productivité et les égarements des développeurs), rythme en moyenne plus soutenu et fatigue plus forte des équipes (plus de temps mort), plus grande facilité d’oublier la vision, le cap, interruptibilité plus forte des acteurs. Que ce soit cycle en V ou méthodes agiles, l’agilité d’un projet (ce qui n’est pas incompatible avec un cycle en V) repose de manière général sur les aspects contractuels et les engagements pris. La forfaitisation rend souvent la gestion du projet plus rigide, ce qui normal car des pénalités peuvent être en jeu. Les méthodes agiles permettent de réouvrir le débat sur les engagements pris, leur fermeté et le résultat attendu. Le point essentiel devient comment être sur d’avancer sans savoir ou l on va vraiment sans signer un chèque en blanc. Cela repose sur différentes valeurs : bienveillance, écoute, capacité à créer de la valeur, droit à l’erreur et avant tout la confiance . La méthodologie de travail n’est alors qu’un vecteur comme un autre et n’est finalement pas une méthode miracle.
Je suis entièrement d’accord avec vous.
De mon point de vue la méthode de conduite d’un Projet se situe environ à mi-chemin entre plusieurs méthodes, juste à côté du panneau « bon sens ».
L’essentiel dans un Projet est d’en définir la cible: où allons-nous ensemble?
En travaillant sérieusement sur cette cible, le cap général est donné, et on peut commencer la traversée.
Pour atteindre cette cible, il y a la trajectoire entre le point A de départ et le point B d’arrivée.
Nous rêvons tous d’une trajectoire rectiligne, sans heurts, remises en question, changement de direction MAIS elle n’existe pas.
L’important est de savoir que la cible reste le point B.
Ce point B devient généralement un point U plus lointain jalonnée de toutes les étapes pour l’atteindre…
Cette cible est floue, pas encore bien dessiné mais l’idée générale, la philosophie du Projet, qu’elle soit technique et/ou humaine, existe bien
Certes les méthodes Agile permettent beaucoup plus facilement de mieux contrôler cette trajectoire, de mieux gérer les changements de direction, de pouvoir définir plus précisément les contours de la cible quitte à gommer certains traits mais surtout d’impliquer chaque acteur dans la réussite globale du Projet.
Le client, l’analyste, les développeurs, le chef de projet sont tous sur ce même bateau où chacun met en avant son expertise en toute confiance.
Mais pour que cette confiance perdure il faut savoir où l’on va…
… on revient donc au début: « où allons-nous ensemble? »
Imaginez-vous un bateau où le capitaine donne le cap et où chaque matelot fait ce qu’îl veut s’octroyant de fait LA bonne décision:
« Moi je vais plutôt à tribord »
« Maaaais non, moi je vais à bâbord »
Et bim, on s’est pris l’iceberg, Jack meurt encore, et la chanson de Céline Dion nous arrache encore des larmes!!!!
Si dés le départ chacun sait quelle est la cible, que les décisions sont prises en « demandant » comment faire (TELL) plutôt que d’imposer (ASK) pour que tout le monde aille dans le même sens, la méthode d’action par la suite n’est plus si importante.
Autrement dit, la conduite du changement est tout aussi importante à l’intérieur de l’équipe Projet que pour les parties prenantes…
Et là on est sur de la gestion humaine des craintes de chacun.
Certaines craintes sont visibles, d’autres non mais chacune doit être connue et prise en compte mais sans confiance ça ne marche pas.
Et pour avoir confiance il faut savoir où l’on va…
« On va où ensemble déjà? »
Très bon article. Merci pour le partage !
Je ne rejoins pas vraiment cette analyse qui ne parle que d’organisationnel.
En effet un projet c’est plus que cela, on met une organisation en place pour réaliser un produit sous forme de service. C’est le seul objectif. Il y a confusion entre les moyens et l’objectif principal.
Les sprints et scrums ne peuvent pas s’inscrire dans des projets de produits physiques tels que les avions, les trains ou l’automobile (du fait des vies humaines en jeu) excepté sur les parties logicielles non sécuritaire de type télématique ou connectivité.
En effet, un serveur peut se planter, cela entraînera un mécontentement des utilisateurs / clients mais il n’y a pas « mort d’hommes ».
Si le vol Rio / Paris s’est crashé, cela est dû à une sonde d’altitude qui a été mal qualifiée puis à une erreur humaine des pilote et copilote qui ont fait confiance à cet instrument aveuglément au lieu de regarder les autres instruments de bord à disposition pour vérifier l’altitude.
Or pour concevoir, réaliser, vérifier, valider, qualifier une système ou sous-système aéronautique on utilise une norme qui s’appelle la DO 160 et qui ne laisse pas de place aux côtés funs et sympas des systèmes IT.
Ce ne sont pas les sprints et scrum qui vont supplanter ces méthodes de conception, réalisation / implémentation / vérification / validation / qualification / recette.
D’ailleurs qu’un spécialiste de la méthode Agile explique la différence entre vérification et validation… Il ne voit même pas la nuance donc la différence fondamentale !
La méthode Agile est une méthode souple mais justement trop souple pour la rigueur nécessaire dans de tels dispositifs qui nécessitent une notion de sûreté de fonctionnement.
Airbus, Boeing, Alstom, Siemens et Bombardier n’utiliseront jamais cette méthode pour construire leur avions ou trains, de même que les constructeurs automobiles ne peuvent pas utiliser un telle méthode pour les calculateurs type contrôle moteur ou cruise control.
Ne mélangeons pas les choux et les carottes !
Merci pour ce retour. Effectivement mon article ne place dans un contexte de déploiement informatique, cela méritait sûrement une petite précision.
Néanmoins, je ne suis pas certain que la souplesse des méthodes Agiles nuit forcément aux exigences de sûreté de fonctionnement. Il est possible, de mon point de vue, de concilier souplesse de la méthode et rigueur de l’analyse. La revue d’architecture technique dans le cadre de l’implémentation d’un logiciel informatique requiert une très grande précision où la stabilité du système d’information et la sécurisation des données sont des enjeux majeurs. On est loin des risques humains que vous soulignez j’en conviens, mais je pense qu’il ne faut pas entendre souplesse comme laxisme.
En réponse 1 an plus tard au premier commentaire, cela marche très bien pour des produits physiques. J’ai travaillé chez Toyota plusieurs années, et plusieurs autres constructeurs automobiles travaillent en modèles itératifs et incrémentaux dans la même philosophie que les méthodes Agile qui rejoignent Lean (Toyota, Honda, Harley Davidson). Les phases de développement se recouvrent avec une intégration continue tout le long de la vie du projet, même avec de nombreuses normes.
Le fait de travailler d’une manière Agile ne signifie pas qu’on jette le fait de définir une solution, en faire le design, l’implémentation et le test, ils sont organisés d’une manière différente pour optimiser le feedback de l’utilisateur. Scrum est une manière de faire populaire qui fonctionne bien en IT mais certainement pas la seule méthode Agile qui existe. Voir the New New Development Game et the Lean Machine pour ceux que ça intéresse.