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 ?
Ton analyse du cycle traditionnel d'un projet est pertinente. Merci de nous rappeler qu'il n'est pas adapté pour la plupart des projets. Ton article est très simple d'accès je le diffuse. :)
Pierre
Rédigé par : Pierre | 21 avril 2011 à 15:49
Complètement d'accord avec ton analyse.
Je me bat tous les jours pour ajouter un peu plus de bon sens et de souplesse aux méthodes utilisées chez nous (le sacro saint cycle en V légèrement arrangé pour qu'il soit encore plus proche de l'usine à gaz), avec peu de résultats malheureusement.
Pour moi,c'est une question de personnes avant tout. Ce n'est pas parce que l'organisation préconise un cycle en V que l'on est forcé de travailler de cette façon. Certes il y a des contraintes indéboulonnables, mais il y a aussi pas mal de marge de manœuvre du moment que le projet avance et que les jalons sont tenus.
Si tout le monde pense "out of the box" (ce qui est rare mais qui tend à changer), alors pas de problème. En revanche, de même que le débit d'un réseau est bridé par l"élément le plus lent, si la personnes ou les équipes "passage obligées" pense "cycle en V ou rien" alors c'est mort. L'énergie dépensée pour faire évoluer leur mode de pensée, garder le projet sous contrôle et hors du tunnel, .... sera clairement disproportionnée par rapports aux maigres résultats qui seront obtenus. Pourtant il faut en passer par là pour petit à petit faire évoluer les mentalités mais c'est usant et sur l'idée du le "vaccin contre la motivation" je ne peux que te rejoindre.
C'est ce qui m'est encore arrivé hier (équipe technique "rigide"), et quand j’imagine l'énergie que je vais dépenser pour amener seulement un peu de bon sens... et très peu de résultats je suis bien démotivé d'avance. Mais bon, il faut savoir se satisfaire des petites victoires et construire dessus un avenir plus agile.
Rédigé par : Fabien Grenet | 22 avril 2011 à 09:35
Je partage votre analyse pertinente du cycle en V.
Et en plus, article bien rédigé.
Rédigé par : Mistra | 31 mai 2011 à 10:05