le mélange des pinceaux

Lors de mes études terrain, séminaires agiles et expériences professionnelles, j’ai vraiment pu me rendre compte que les sociétés, quel que soit leur domaine, avaient des perceptions de l’agilité très disparates et diverses (de l’agilité, c’est une mode à ok je veux de l’agilité au forfait en passant, notre société est agile par nature -et parfois c’était vrai, mais pas souvent, la seule agilité qu’on pouvait voir c’était la courbure d’échine dorsale) ce qui n’a pas manqué de m’étonner non parce que l’agilité ne peut pas prendre plusieurs forme, mais juste par le fait qu’on appelle parfois des projets agiles, agilisés, agilifiés (oui, moi aussi je kiff les néologismes), ou de transformation agile; des projets qui sont tout tout tout… sauf agiles.

J’ai donc eu l’occasion de constater que des comptes de faits peu réjouissants existaient sur l’agilité :

Voici deux cas un peu représentatifs de ce que j’appelle faire de l’agilité comme Stephen Hawking fait de la GRS.

Stephenhawkinglikesgym

  • Cas 1 : « Attention peinture fraîche »

Dans le premier (et le pire) des cas, l’agilité n’est qu’une épithète appliquée à un projet comme on applique une nouvelle peinture sur le mur : l’équipe ne change pas ses méthodes de travail et faire toujours du prédictif sur moyen à long terme, on la renomme juste « équipe agile » comme on change un étiquetage et de la même manière, on rebaptise gentiment le Chef de projet maîtrise d’œuvre en « Scrum Master » ou pire encore chef de projet agile (et pourquoi pas Chef du projet à Gilles tant qu’on y est ?), le Chef de projet client se transforme comme Sailor moon en « Product Owner ». L’équipe agile reste une brochette de ressources qui n’ont pas trop leur mot à dire sauf quand ça compile sur leur machine mais pas sur le serveur… et niveau « package documentaire » ? Même topo, un « cahier des charges » qu’on ose renommer en backLog alors qu’il ne comporte aucune user story, des « spécifications » (là on ose pas trop changer le nom), et éventuellement on se colle un « cahier de recette » (parce que c’est connu la restrospective, la démo tout ça ça sert à cacaouette), et enfin…. de la comitologie à gogo… coproj, copil, coex… Bref ça n’a d’agile que le nom.

saiormoonproductowner

  • Cas 2 : « De l’agilité, par petites touches de ressentit »

Dans le deuxième cas, on applique de l’agilité en autorisant l’équipe de réalisation à utiliser quelques outils de l’agilité : (éventuellement un ptit kanban par ci, pour décorer le mur, quelques post-its histoire de faire de jolies dessins sur les vitres, peut-être un peu de poker planning estimation quand on s’ennuie à la pause… mais sans changer le fondement du mode de gestion du projet : On doit livrer un projet -et non un produit- sans pragmatisme, ni priorisation, ni prise en compte des changements… en gros, on fait semblant de faire de l’agile comme si on jouait à la dinette dans un 3 étoiles du guide Miqueline.

bernardloiseauaimeladinette

Le problème ? Ben c’est surtout que ces pratiques, lorsqu’elles interviennent dans le cadre d’une « transformation agile » (parfois vendues par des sociétés dont je tairais les noms), sont génératrices de frustration pour le client (et de traumatismes, du coup après, pour les guérir en leur disant qu’on le fait avec un médoc éprouvé : l’agilité, ben euh difficile de dialoguer….) : En gros, certaines société promettent une « transfo agile » avec un rafraîchissement du cadre de travail, plus de confort, plus de résultat, plus de lumière, plus de potentiel, plus de gens heureux et finalement on a juste repeint mode truelle couleur agilité, on a enduit (oui oui du verbe enduire) le client dans l’erreur et on l’intoxique à l’agilité mauvaise qualité.

duluxvalentinechanson

Du coup, le client, il opte soit pour faire machine arrière, soit pour continuer mais « à conditions forfait » car ça lui fait craindre que tous les projets se dérouleront de la même manière….

Bref l’agilité, soit t’en fait, soit t’en fait pas mais y’a pas d’agilité où on trempe que les doigts de pieds.

Comments 1

  1. C’est toujours le même problème : appliquer des pratiques agiles sans comprendre ou accepter les valeurs de l’agilité.

    L’agilité implique un changement de paradigme : on passe du forfait-contrat-tunnel à un processus itératif ou l’objectif de tout le monde est de produire vite un truc qui marche et qui colle au besoin, en acceptant que tout, surtout le périmètre, puisse changer en cours de route.

    Ca implique que les acteurs, notamment les client, CDP, PO, sont responsables, prennent des décisions souvent et ne peuvent pas blâmer l’équipe si le produit ne leur convient pas, puisqu’en théorie ils le valident tout le temps. Le concept du forfait étant de déléguer puis d’attaquer si c’est mal fait, ça peut être dur.

    Ca implique aussi que le pilotage à long terme est compliqué : quelles stories on va faire dans 6 mois ? C’est quoi le budget ? J’embauche ou je dis à mes prestas de régler leurs affaires ?

    On ne fait pas de l’agile, on est agile.

    http://agilemanifesto.org/

Laisser un commentaire