« C’est quoi l’agilité ? » Je pense que nous avons tous un peu notre réponse à cette question. Pour ma part, je concentre ma réponse autour de 2 points :
- Ce sont des valeurs et des principes, RTFM (Read The Fucking Manifesto ^^)
- C’est un changement de paradigme, du déterminisme à l’empirisme
Pour présenter les valeurs et les principes c’est facile. J’utilise le manifeste agile bien sûr, j’essaye de donner au moins un exemple concret par valeur, et aussi par principe si j’ai un peu de temps.
C’est un peu moins « prémâché » pour présenter le changement de paradigme. Et souvent, j’ai cette question : « Mais si on adopte une approche empirique, ça veut dire qu’on ne planifie et qu’on n’anticipe plus rien ? C’est l’anarchie ? »
Non. Je pense que c’est beaucoup plus complexe que ça.
Je soumets donc cette petite réflexion sur le sujet à l’intelligence collective pour avoir votre feedback et si possible tenter de l’améliorer !
Introduction
En « mode waterfall / cycle en V », dans un monde déterministe, nous essayions d’accumuler des connaissances pour prévoir l’avenir (planification des projets), avant de nous lancer dans la réalisation.
En « mode agile », dans un monde empirique, nous commençons par expérimenter, faire, réaliser, et c’est ainsi que nous gagnons les connaissances. Ces connaissance sont à la fois les connaissances liées au produit (nous le découvrons et l’adaptons au fur et à mesure en fonction des feedbacks clients), et les connaissances liées à l’équipe (dont notre capacité à produire).
Support visuel et discours associé
Je représente ça en général grâces aux triangles (scope-time-cost) que les managers de projet/produit connaissent bien.
Le discours associé à cette illustration :
Triangle de gauche :
En management de projet/produit classique, nous passons beaucoup de temps à essayer de déterminer très précisément le scope, ce afin d’en déduire un time (planning) et un cost (budget) précis et le plus fiable possible.
Nous commençons ensuite la réalisation. Et tout se passerait bien s’il n’y avait aucun changement, aucun risque, aucune incertitude sur le produit à réaliser, ni aucune incertitude sur la capacité de l’équipe à le produire. C’est impossible, à moins d’être dans une bulle étanche, d’avoir fait le produit une première fois pour être sûr que c’est le bon, et d’avoir des robots à la place d’humains dans les équipes… et encore !
Il y a donc des changements par rapport à ce qui a été planifié. C’est inévitable. Ces changements vont impacter les dimensions scope time et cost, et donc notre planification. Mais quand les trois dimensions sont fixées, par un contrat par exemple, ou par un engagement pris en comité de jalon ou de pilotage… comment faire ? Il reste une dimension dont nous n’avons pas parlé. La qualité. Et malheureusement… c’est souvent la qualité qui est impactée dans les projets « waterfall » quand une équipe est obligée de faire face à un changement tout en étant pieds et poings liés dans ce triangle figé.
Bien sûr ce n’est pas du management de projet « correct ». Il existe le mécanisme des « changes requests » et je suis convaincue que le rôle d’un bon project manager n’est pas de préserver coûte que coûte la planification, mais bien de gérer ces « change requests » de manière à faire évoluer le triangle scope-time-cost tout en le gardant sous contrôle. Mais cette « théorie » est peu compatible avec notre culture réfractaire au risque et qui cherche à tout prix l’engagement ferme et définitif (oh combien illusoire) pour se rassurer (à ce sujet, je renvoie à la théorie des dimensions culturelles de Geert Hofstede, c’est passionnant)… et parfois tout simplement inapplicable de par la dérive administrative qu’elle engendre face à des changements trop fréquents.
Bref. Ce n’est pas simple.Triangle de droite :
En mode agile maintenant. Nous commençons par définir une vision. Une vision ce ne sont pas du tout des spécifications ! C’est ce que l’on a au lancement du projet/produit comme idée de ce que l’on veut réaliser. Elle peut se limiter à un elevator pitch par exemple.
Ensuite, on fixe les dimensions time et cost. C’est « facile » : pour quand voulons-nous une première version de notre produit, combien d’argent sommes-nous prêts à investir au regard de sa proposition de valeur (qui doit être claire dans la vision) ?
A partir de là, on commence à réaliser. Et pendant toute la réalisation, notre variable d’ajustement sera la dimension scope par les mécanismes de gestion du product backlog, alimenté par les boucles de feedback.
La contrepartie à cette flexibilité sur le scope est la rigueur sur la qualité : la qualité n’est plus une variable d’ajustement.
Cela signifie aussi avoir le courage d’arrêter un projet/produit si nous découvrons (toujours par les boucles de feedback) que nous faisons fausse route… Notion de droit à l’erreur etc etc.
Bref… ce n’est pas simple non plus !!! Mais peut-être plus adapté pour certains projets/produits et dans tous les cas plus réaliste et transparent. Nous reconnaissons les incertitudes, regardons les risques en face et c’est la seule manière de s’ouvrir également aux opportunités (la version « positive » des risques) .
Insister sur la bascule
Ce n’est pas qu’un nouveau process, une nouvelle manière de gérer les projets. Et c’est pour ça que passer d’un processus jalonnés à l’application de Scrum ne suffit pas à être agile. Découper des spécifications détaillées pour les donner bouchée par bouchée à l’équipe au fur et à mesure des itérations tout en vérifiant qu’on respecte bien les engagements scope-time-cost, ce n’est pas être agile !
Passer d’un mode déterministe à un mode empirique, c’est un vrai changement culturel. Philosophique.
Petit tour sur la page wikipédia « Empirisme » :
L’empirisme désigne un ensemble de théories philosophiques qui font de l’expérience sensible l’origine de toute connaissance ou croyance et de tout plaisir esthétique. L’empirisme s’oppose en particulier à l’innéisme et plus généralement au rationalisme « nativiste » pour lesquels nous disposerions de connaissances, idées ou principes avant toute expérience.
… Et il peut être aussi difficile de « passer de l’autre côté » que de faire marche arrière.
This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.
[Morpheus, Matrix]
Mixer les deux approches ?
Si ce changement de paradigme est une bascule, est-ce qu’il est possible d’avoir une approche « mixte » ?
Je pense que oui. En fait, je pense qu’il faut trouver le bon compromis entre le 100% déterministe qui paralyse (je veux absolument tout prévoir avant de faire le premier pas) et le 100% empirique qui peut être anxiogène (essayez de marchez les yeux bandés sans avoir préalablement visualisé votre parcours…)
Pour faire le lien avec les techniques de management de projet/produit, je rapproche ça du management des risques/opportunités : il faut trouver le bon compromis car sans prise de risque, rien de nouveau et un bon management des risques ne veut pas dire chercher à les éviter à tout prix !
Je pense que ce compromis dépend : du produit, de l’équipe, du contexte, et de la phase dans laquelle nous sommes.
Rapport aux méthodes (en tout cas celles que je connais un peu ^^)
- Scrum est une proposition qui fait un compromis entre empirisme et déterminisme. L’approche est globalement empirique à l’échelle du développement du produit, mais les sprints sont déterministes.
- XP serait un peu plus empirique que Scrum (itérations plus courtes, possibilité de prendre en compte des changements pendant les itérations).
- Kanban (et le mode flux continu vs. itérations) serait le plus empirique
PS : un jour il faudra que je fasse un retour d’expérience complet sur un de mes anciens projets pour lequel nous avons fait la première release en mode « classique jalonné », la deuxième en Scrum et la troisième en Kanban…
Quand j’entends parler de mode « hybride », j’ai l’impression que l’on cherche une autre proposition de framework entre le « mode classique » et Scrum, donc a priori plus déterministe que Scrum mais en pouvant intégrer du changement en cours de réalisation… pourquoi pas.
Première valeur agile :
Les individus et leurs interactions plus que les processus et les outils
Nous devons adapter les process et des outils, du moment que c’est fait pour de bonnes raisons et en connaissance de cause (petit lien vers l’excellentissime conférence de Claude Aubry « Scrum ? mon scrotum ! » sur les dérives de Scrum, dont l’adaptation du process pour de mauvaises raisons (genre : « nan, mais on a arrêté les daily… trop contraignant… et puis l’agilité c’est d’adapter les process, non ? »).
Alors adaptons-nous (et faisons-le correctement) et trouvons le bon compromis entre empirisme et déterminisme en fonction du produit, de l’équipe, du contexte, du moment.
Nous avons pris conscience que notre ancien monde de prévisions et d’engagements n’est qu’une matrice fictive dans laquelle nous nous réfugions par peur du changement, des risques et de l’échec. Nous avons pris la pilule rouge, suivi le lapin blanc dans la réalité, le concret, l’expérimentation.
Et pourtant, ne nous interdisons pas d’utiliser les possibilités de la matrice quand celles-ci peuvent nous servir !
La prise de conscience est indispensable et irréversible. Après le reste… ce ne sont que des processus et des outils ! 🙂
elohappy.world 