Pour bien comprendre l'agilité, c'est essentiel de comprendre de quelles frustrations elle est née. Voici donc un nouveau post autour de la non-agilité.
Vous connaissez surement le la gestion de projet façon cycle en V. Si, si : faisabilité, spécifications, réalisation, tests, recette, etc
On appelle ça un cycle en V parce qu'on descend la réalisation du plus général au plus détaillé, puis qu'on remonte les tests du plus détaillé au plus général.
NB : Je parle ici plutot de développement info, mais ça s'applique très bien à l'immense majorité des projets.
Sur le papier, c'est superbe, une vraie horloge : on décide soigneusement de ce qu'on va faire, on le fait, on le teste, et tout le monde est beau.
Dans la réalité vous aurez sans doute constaté que le papier est plus rugueux qu'il n'y parait. C'est beau, mais ça dérape dans tous les sens : votre beau planning sert plus à constater le retard qu'à le prévenir, et chaque demande de changement de périmètre est un psychodrame.
Qu'est-ce qui ne colle pas entre le papier et la réalité ? quelques pistes de réflexion...
1. Le cycle en V ne permet pas de changer d'avis.
Plus précisément le cycle en V ne prévoit à aucun moment d'ouvrir la porte aux changements de la part du responsable produit. On se met d'accord au départ, on fait, et il faudra attendre le prochain cycle en V pour changer quoi que ce soit.
Si on a des cycles en V d'une semaine, pas de problème ( on a alors fait un premier pas vers l'agilité), mais la tendance que vous observez surement est plutot d'étaler un cycle sur 3 à 6 mois, voire un an.
Et dans notre glorieux XXIe siècle, il s'en passe des choses dans la vraie vie en un an... qui impliquent des changements de cap... qui créent des psychodrames dans les équipes de développement.
Plus insidieusement, ce cycle en V qui ne laisse pas de place au changement véhicule l'idée qu'un changement d'avis est un problème en soi, une perturbation tout à fait anormale qui ne devrait pas avoir lieu.
Vous avez là un premier superbe lumbago structurel dans le cycle en V : le changement n'est pas le bienvenu, alors que la durée du cycle le rend inévitable.
2. Le mirage de la planification
Le cycle en V part du principe que nous autres gens bien élevés savons planifier à long terme... ce qui est faux.
Pas besoin de vous rappeler le programme rêvé de vos dernières vacances par rapport à ce que vous avez réellement fait, ni votre dernière période de Noel, où même en vous y mettant deux mois à l'avance avec les meilleures résolutions, vous avez couru un peu partout entre le 20 et le 24 pour trouver vos cadeaux.
Ce n'est pas si terrible de l'admettre : quelqu'un de normalement constituté a toutes les peines du monde à planifier correctement à plus de 15 jours ce qu'il va pouvoir réellement réaliser.
Il y a au moins deux problèmes qui font déraper au delà de 15 jours :
- le premier est lié à la vraie vie : des centaines d'événements et de décisions vont impacter significativement votre projet, dont mathématiquemnet plusieurs dans les semaines qui viennent. C'est tout simplement impossible de les prévoir.
- le second est terriblement humain : vous aurez forcément une impression de confort au début qui fera que vous serez systématiquement à la bourre à la fin. Une pile d'études sociologiques le montrent : nous sommes indécrotablement optimistes et sous-évaluons choniquement les risques. Etre à la bourre sur la fin d'une période de 15 jours, ça s'absorbe, sur la fin de 6 mois, ça fait mal.
En fait, le temps s'accélère progressivement dans un cycle en V.
Regardez par exemple le temps moyen d'un aller-retour de mails entre l'équipe opérationnelle (dév) et le responsable produit. Vous observerez un délai en gros d'une semaine en début de projet ( en phase de spécifications par exemple), et une heure à la fin ( en phase de tests à l'arrache).
Finalement ce temps qui s'accélère n'est pas un drame en soi, c'est le fait que la pression le suive de très près qui ne fait plaisir à personne.
La conséquence, c'est que c'est toujours la fin du cycle qui trinque.
Et la fin du cycle en V, ce sont toujours les tests. Qui dit moins de tests, dit davantage de bugs, et des bugs qui seront vus plus tard, c'est-à-dire en plein milieu du cycle en V suivant... qui sera déjà sous l'eau, etc.
Je résume : basé sur une vision plus qu'optimiste de la capacité de planification d'une personne normale, le cycle en V crée mécaniquement non seulement de la pression mais aussi des bugs cachés, qui diminueront à l'avenir encore plus la capacité de planification de l'équipe.
Le cycle en V devient cercle Vicieux.
3.le cycle en V est ingrat.
Il est ingrat car comme on l'a vu au-dessus il crée lui même une bonne partie de ses problèmes.
Il est ingrat car il ne fait rien pour mettre en lumière la foule de petites victoires au quotidien.
Il est ingrat car c'est à ceux qui prennent le plus de risques ( ceux en bout de chaine qui doivent produire coute que coute) qu'on fait le moins confiance.
Ce cycle se construit effectivement le plus souvent sur un mécanisme de commande et de contrôle :
- des responsables hiérarchiques décident
- des opérationnels réalisent sagement suivant les process qu'on a pensés pour eux
- un service qualité s'assure que ces process sont respectés, ce qui est censé garantir la qualité du produit final.
La confiance est donc placée dans le processus et dans les outils de controle, et pas dans les personnes qui l'exécutent.
C'est ingrat de travailler avec des méthdoes qu'on n'a pas choisies, c'est ingrat de passer des heures à remplir des tableaux de reporting -que personne ne lira-, c'est ingrat de se faire taper sur les doigts parce qu'on n'a pas suivi une règle qu'on n'a pas choisie.
Les inconvénients du cycle en V en 10 mots : rigidité, cocotte-minute et vaccin contre la motivation...
Mais alors pourquoi on l'utilise ? next post !
Vous en voyez d'autres, des lumbagos du cycle en V ?
