Management de projets : 5 étapes pour passer à la méthode Agile

La méthode Agile, inaugurée avec son célèbre manifeste, date du début des années 2000. Pourtant, les approches innovantes en développement ne datent pas de 2001. Avec le RAD (Rapid Application Development ou RAB pour Rapid Application Building), des méthodes alternatives, comme le développement en Spirale, ont émergé dès les années 80. Le marketing de la méthode Agile a cependant été bien meilleur que celui du modèle en spirale de Barry Boehm.

Méthode agile
La Méthode Agile est avant tout un état d’esprit, et des principes de base (il y en a 12 qui sont décrits dans le manifeste éponyme)

Depuis lors le discours « agile » est même devenu une sorte de passage obligé au point d’être parfois vidé de sa substance. « Soyons Agiles » entend-on répété à l’envi dans les écoles et les entreprises dans le cadre de projets qui n’en ont pas toujours toutes les caractéristiques.

méthode Agile
Michel Operto

A l’opposé, la méthode Agile poussée à l’extrême est mise à toutes les sauces, y compris là où cela ne devrait pas être le cas. Car, c’est ce que j’ai appris avec Michel Operto, fondateur et animateur du blog Dantotsu, la bonne vieille méthode en V (ou la méthode en cascade, ou Waterfall en anglais) du développement logiciel n’est pas totalement à jeter. Tout dépend du contexte. J’ai interviewé Michel, un de nos meilleurs spécialistes du domaine, pour revenir sur les fondamentaux de cette méthode et en écarter les mythes, dans le cadre de notre dossier sur l’Environnement du travail, réalisé avec Selceon.

Dantotsu : s’améliorer sans cesse

Dantotsu est un mot que j’ai appris lors de voyages professionnels au Japon, qui signifie « Toujours chercher à s’améliorer« , précise Michel Operto. Et c’est ce que j’essaie de faire à travers mon blog dantotsuPM.com, dédié au management de projets, afin de permettre à tous les manageurs de projets de s’améliorer en permanence, en se familiarisant avec les nouvelles techniques, les nouvelles technologies, les nouvelles approches.

Le dossier sur l’environnement du travail de demain réalisé avec Selceon
Le dossier sur l’environnement du travail de demain réalisé avec Selceon

Méthode Agile définition et méthodologies

Pour Michel Operto la méthode Agile n’est pas seulement une méthode, c’est avant tout une approche, un état d’esprit, une mentalité, quasiment une philosophie par rapport au développement de logiciels, qui s’est étendue ensuite à d’autres domaines.

méthode agile
12 principes sous-tendent la méthode Agile. Elles sont décrites dans le Manifeste Agile, dont une traduction française est disponible en ligne. On peut les regrouper selon 4 règles principales décrites par Michel ci-dessous.

Il s’agit en premier lieu d’être capable de mettre en route toute l’entreprise et toute son organisation pour adopter les quatre grands principes du manifeste Agile, les suivre de manière régulière et volontariste, depuis le haut jusqu’au bas de l’organisation.

Les quatre grandes règles du manifeste Agile

4 grandes règles de la méthode Agile
Agile se décline en 4 grandes règles que voici dans la version anglaise originale. A noter que les éléments en gras à gauche (les buts), sont à privilégier sur les éléments à droite (les moyens)

Ces quatre règles sont assez simples, souligne Michel Operto :

  • La première règle de la méthode Agile est de favoriser les individus et les interactions entre les individus davantage que les outils utilisés ou les processus mis en place. Les relations interpersonnelles, les compétences douces, les personnes elles-mêmes sont mises en avant plutôt que les méthodes appliquées, les étapes à suivre, les outils à implémenter ;
  • La deuxième règle repose sur le fait de fournir au client des logiciels opérationnels qui marchent, plutôt que des documentations, de faire des promesses et « des plans sur la comète » ;
  • La troisième règle repose sur la mise en place d’une collaboration directe entre les développeurs et les clients, plutôt que la négociation de contrats impliquant des pénalités d’un côté et de l’autre, des délais, etc.
  • Le quatrième règle repose sur la capacité à s’adapter aux changements plutôt que de suivre un plan d’action rigide.

Méthode Agile ne veut pas dire absence de méthode !

Ceci ne signifie pas pour autant ne plus avoir de contrats avec les clients, de documentation, d’outils et de processus, mais simplement que les premiers éléments vont être favorisés par rapport aux seconds, parce qu’on reconnaît ces valeurs au niveau de l’entreprise et au niveau de la philosophie de travail de l’entreprise et de l’équipe.

12 principes de la méthode Agile
Les 12 principes de la méthode Agile selon le Manifeste éponyme

 

La méthode Agile se réduit-elle à Scrum ?

Ce serait là faire un raccourci. Il est vrai que Scrum reste la méthode agile la plus utilisée au monde à l’heure actuelle. Elle présente beaucoup de bénéfices car elle a permis de structurer la manière de travailler.

Scrum a créé des cérémoniaux, des réunions formelles tous les matins, par exemple avec les daily stand-ups de toute l’équipe de développement et le product manager, afin d’aller dans des cycles très rapides de développement, de ne pas avoir des questions qui restent en attente pendant des jours, des semaines, simplement parce qu’on n’a pas pu contacter le client et que la décision n’a pas pu être prise.

Scrum est une bonne méthode mais ce n’est pas la seule

Scrum est une très bonne méthode si on veut faire de l’Agile parce qu’elle fournit un cadre, des cérémonies à suivre et une approche. Elle recommande aussi l’utilisation de coachs agiles, certifiés, capables de gérer des projets agiles et formés sur Scrum afin de faciliter la structuration de l’équipe et de ses livrables.

Scrum fournit une structure qui va permettre au product manager, au product-owner selon la terminologie Scrum, aux responsables des équipes de développement et aux membres des équipes de développement, de structurer leur approche, d’avoir une liste de choses à faire, d’être capable de les prioriser avec le client, et ensuite préciser lesquelles vont faire partie de telle ou telle prochaine version du logiciel, puis livrer cette petite version du logiciel qui apporte réellement de la vraie valeur au business.

Et ensuite, seulement une fois que cela a été testé et vu par le client, éventuellement mis en production, passer aux besoins suivants en termes de priorités et de valeur business.

Scrum est une très bonne méthode, sûrement la plus connue en Agile

Il existe d’autres méthodes Agiles, notamment Kanban

Effectivement, et Kanban vient des équipes qui font du support en continu, gèrent des demandes clients et ont besoin d’organiser leur travail en matière de flux de travail entrant avec tout un ensemble de choses à faire.

Une partie est sélectionnée pour la to-do list, puis passent ensuite en actions en cours, jusqu’à ce qu’elles soient effectivement considérées comme faites, avec la fameuse définition du « done » très importante dans cette méthode. Le fameux Work In Progress (WIP) permet de travailler en étant toujours focalisé sur seulement quelques tâches.

méthode Agile Kanban Scrum et Scrumban
Les différences entre Scrum, Kanban et Scrumban selon agilewheel.com (cliquer pour agrandir)

On fait beaucoup d’hybridation entre Scrum et Kanban avec Scrumban par exemple, ces tableaux qui permettent de suivre les tâches et l’avancée du développement du prochain incrément de logiciel, sur quel user story on travaille réellement, lesquels sont terminés et peuvent passer en tests utilisateurs puis ensuite en production (voir schéma ci-dessus).

C’est par l’hybridation de toutes les méthodes que l’on réussit

On peut associer également du Lean pour faire des choses qui soient le plus efficaces possible, en ajoutant le moins d’overhead possible de choses qui ne serviraient à rien.

Lean suggère d’éliminer tout ce qui n’est pas impératif et nécessaire

Il existe également le cadre méthodologique (« framework » en anglais) SAFe d’agilité à l’échelle. Scrum recommande d’avoir de petites équipes de développement, de 10 à 12 personnes maximum. Mais pour développer de gros modules logiciels, il faut souvent beaucoup plus de personnes si on veut livrer rapidement. Safe s’est introduit, permettant de faire de l’agilité à l’échelle, de synchroniser plusieurs équipes Scrum ensemble, de faire du Scrum de Scrum, et coordonner.

méthode Agile
Vue d’ensemble de la Méthode SAFe de montée à l’échelle de l’approche Agile, avec le risque de retomber, selon Michel Operto, dans le problème des usines à gaz qu’Agile était justement censé remplacer (cliquer pour agrandir) – visuel conçu par Scaled Agile

Le risque de l’Agilité à l’échelle est de retomber dans les méthodes traditionnelles et prédictives

Le risque, quand on rentre beaucoup dans ce type de méthode d’agilité à l’échelle, est de se retrouver dans les méthodes plus traditionnelles et prédictives, avec des releases, avec des trains qui doivent se rencontrer à un certain temps, qui introduisent des délais dans les livrables, des dépendances entre les équipes. On rentre dans de l’agilité beaucoup moins agile que si on travaille sur un projet bien ciblé, bien cadré, relativement petit, mais qui va délivrer un maximum de valeur rapidement.

Les méthodes traditionnelles prédictives, comme la méthode en V, restent très applicables dans beaucoup de domaines

Agile est très fort quand on a énormément d’incertitudes sur les besoins clients

Le client n’est pas vraiment capable de définir ce qu’il veut, ou est dans une phase d’innovation, de création d’un nouveau logiciel, et il n’existe pas de cadre bien défini.

méthode agile
Le traditionnel modèle en cascade ou « Waterfall model » en anglais vu par Kenscourses

Sur un projet plus traditionnel, le cycle en V est tout à fait approprié

Notamment pour les projets avec des livrables, un réseau à déployer, des sites à installer, par exemple du logiciel à développer pour une comptabilité et ensuite le déployer sur plusieurs pays, voire à l’échelle mondiale.

Si les besoins sont spécifiés au départ, le cycle en V reste pour Michel une bonne méthode, à condition d’arriver à bien cadrer et d’appliquer une légère hybridation de ce cycle en V (cf. la vidéo explicative ci-dessus). Par exemple les phases amont du cycle en V (phases de design, de définition des besoins), peuvent être réalisées en mode un peu plus agile en travaillant en collaboration avec le client, en faisant du design thinking, en cherchant où apporter le plus de valeur.

Une fois terminées ces phases de cadrage des besoins, on peut ensuite continuer sur du cycle en V, avec plusieurs releases du logiciel ou du projet qui vont arriver au fil du temps. Ce qu’on appelait en méthode traditionnelle prédictive les rolling-waves, des vagues de développement et de déploiement qui s’enchaînent les unes après les autres et qui permettent d’augmenter progressivement, soit la couverture d’usage du produit, soit son développement.

L’erreur que font certaines sociétés est de vouloir tout faire en Agile alors que ce n’est pas forcément la bonne solution

Pour les entreprises dans l’innovation ou pour des projets hyper customisés clients, avec des clients qui acceptent cette incertitude sur ce qu’ils vont avoir comme fonctionnalités, à quel moment, et l’absence de road map prévisionnelle très prédictive, Agile est très adapté.

L’abus de recours à la méthode Agile a-t-il nui à la qualité du logiciel ?

Pour Michel, les projets Agiles amènent au contraire la qualité, surtout au niveau du parcours client, de l’intégration, de la compréhension ce que veut le client, et permettent de livrer du logiciel de qualité.

Il ne faut pas, en Agile, bien sûr, se précipiter. Il ne faut pas non plus vouloir systématiquement mettre en production tout ce qui est produit par l’équipe à chaque incrément de développement. A chaque sprint, on va livrer des nouvelles fonctionnalités, mais ces nouvelles fonctionnalités ne seront pas nécessairement mises en production dès qu’elles seront finies.

Il faut toutefois leur laisser le temps de mûrir et il faut parfois leur laisser le temps d’être testées par des groupes d’utilisateurs cibles pour les adapter, pour changer un peu le parcours client, et être sûr d’avoir une qualité optimale livrée au client.

Existe-t-il une étude montrant l’impact de la philosophie Agile sur la qualité des logiciels ?

Il y en a beaucoup, notamment faites par scrum.org, par Project Management Institute, par PRINCE2-agile.

Ces études recommandent de plus en plus de pratiquer l’hybridation

Apporter certaines approches et cérémoniaux de Scrum dans les méthodes en V, comme par exemple les leçons apprises en fin de sprints à intervalles réguliers, permet de voir ce qui s’est bien ou mal passé. Ou encore les Daily Scrum où chaque jour, un petit créneau de temps permet de dire ce qui a été fait la veille, ce qui s’est bien passé, où de demander une aide pour débloquer quelque chose, et ce qu’il est prévu de faire aujourd’hui.

Il y a beaucoup à apprendre dans ces méthodes.

Le conseil de Michel Operto aux entreprises : 5 étapes pour passer à la méthode Agile

Le bon sens est la clé de tout, y compris en développement de logiciels.

Pour basculer d’un mode plus traditionnel vers l’agile, Michel Operto recommande une approche en cinq étapes :

  • Commencer par regarder votre culture d’entreprise et essayer de voir quel est le delta entre votre culture d’entreprise et ce que supposent ces fameux principes agiles qui favorisent vraiment les gens par rapport au planning, aux process et aux outils, qui favorisent plutôt ce qu’on livre, par rapport à ce qu’on dit qu’on va livrer ou les plans et les projections.

Il faut essayer d’évaluer ce gap culturel, s’il est vraiment très important ou non.

  • Ensuite, il va falloir travailler beaucoup sur l’adhésion à ces nouveaux principes puisque c’est un changement assez fondamental pour l’entreprise. Et on s’aperçoit en pratique que dans une entreprise qui se dit agile et qui veut faire beaucoup de projets en agile, il y a beaucoup de résistance, beaucoup de latence dans l’organisation. Les finances continuent à travailler sur des budgets annuels, voire pluriannuels, et vont demander des projections sur les retours sur investissement à 3 ans. Pour un projet agile où on délivre toutes les deux semaines du logiciel, il y a vraiment là une incompatibilité assez forte entre les principes et les modes de travail de l’organisation et ce que nécessite l’agilité.

Il faut s’assurer qu’on a dès le départ une bonne adhésion du haut de l’entreprise. C’est très important que le Comité Exécutif soit convaincu des bien-fondés des principes de l’agilité, qu’il les adopte lui-même. Il faut aussi bien expliquer à la base ce qu’est l’agilité, et que ce n’est pas tout changer tout le temps, sans préavis, sans raisons. L’agilité est structurée, il y a des définitions. Il faut travailler sur ces priorisations.

  • En troisième point il va falloir bien manager ce changement vers l’Agile, bien l’accompagner en donnant en quatrième point beaucoup de formation à l’ensemble de l’organisation sur ce qu’est Agile, comment y aller, quelles sont les différences, s’il va y avoir des projets pilotes sur lesquels les équipes pourront s’habituer, se former, et ainsi y aller progressivement.
  • Le cinquième point est de mettre en place une collaboration permanente au sein des projets entre toutes les équipes et le client. C’est la grosse différence d’agile avec les méthodes cycle en V, où au départ le client donnait ses besoins, puis ne voyait rien de concret avant d’arriver tout au bout du cycle en V. Et il y avait souvent un très important décalage entre ce que le client voulait il y a 2 ou 3 ans et ses besoins d’aujourd’hui, entre ce qu’il avait expliqué et ce qu’on avait compris.

Cet aspect de collaboration est important à mettre en place en permanence avec l’implication du client dans chacun des livrables. En général, les cycles de développement sont entre 2 et 6 semaines, et à chaque fois, le client verra ce qui a été réalisé. Le feedback direct du client permettra d’ajuster et éventuellement de rectifier ou d’influencer les prochains développements.

C’est une collaboration de tous les instants.

Yann Gourvennec
Follow me

2 thoughts on “Management de projets : 5 étapes pour passer à la méthode Agile

  1. Merci Yann pour cet article intéressant et complet. Je retiens les 4 principes qui traduisent bien l’état d’esprit Agile:
    – favoriser les individus et leurs interactions
    – être concret et pragmatique dans les livrables
    – créer une coopération directe avec ses clients
    – s’adapter aux changements
    A bientôt,
    Laurent

    1. Merci Laurent. Ce sont en effet les 4 grandes règles du manifeste Agile. Qui se scindent ensuite en 12 principes fondateurs. Ces principes et règles ont l’air évidentes énoncées comme cela, mais encore faut-il les appliquer correctement, et c’est loin d’être évident pour tous et surtout pour toutes les organisations (et ce n’est pas qu’une question de taille).

Comments