Les dérives psychologisantes de l’Agile : étude de cas

IMG_8697 (1)

Lorsque j’ai commencé à me familiariser avec les pratiques agiles, j’ai rapidement été enthousiasmé par leur caractère pragmatique. Je constate cependant dans ce mouvement, depuis quelques années, des dérives “psychologisantes” avec lesquelles je suis bien peu à l’aise.

Ainsi lors de l’Agile Tour Bordeaux de 2015, y avait-il une “clinique” (yeux au ciel)  avec des “experts” (re-yeux au ciel – dont je peux parler en toute transparence car j’en faisais partie) qui avait pour objet de “soigner” des projets en difficulté. Les échanges entre nous montrent une fort penchant vers la psychologie voir même la psychanalyse. Une imposture (qui n’avait d’ailleurs eu aucun succès) dans laquelle je me jurais de ne plus jamais mettre les pieds.

J’ai été le témoin d’une illustration très éclairante de ces travers avec une équipe que j’ai accompagnée très récemment. Il me semblait important de vous présenter ce cas que l’on mettra en perspective dans un prochain article avec l’animation d’un atelier d’amélioration continue et ses résultats.

09:45 : Point du matin

Nous sommes avec une équipe agile qui livre du logiciel pour des clients et utilisateurs en ligne (du B to C, quoi). Nous sommes vendredi, c’est le dernier jour du sprint et nous avons livré en production la version du sprint précédent. Aucun flux n’atteint cette nouvelle version car nous souhaitons au préalable procéder aux dernières vérifications pour s’assurer que tout est en ordre avant d’ouvrir une partie des flux clients.

[Précision : j’accompagne cette équipe, parmi d’autres, dans une démarche d’amélioration continue. Il s’agit là du 4ème et dernier jour d’accompagnement pour cette équipe.]

Le point du matin démarre. Karima la testeuse est préoccupée car ses tests nominaux sur la production ne sont pas concluants. La MeP (mise en production) a eu lieu l’avant-veille et quelque chose ne fonctionne pas : il y manifestement un problème de déploiement. Entendant cela, je deviens nerveux car il est prévu d’ouvrir la production aux clients le mercredi suivant. Mais le point du matin continue. Gabriel, le Scrum Master “senior” (deux ans dans le rôle) donne la parole aux autres membres de l’équipe qui racontent chacun leur tour ce qu’ils ont fait la veille, ce qu’ils vont faire aujourd’hui et tout le tralala … En ce qui me concerne je ne les entends plus car je suis obsédé par le problème de production. Le point du matin s’achève et Karima est un peu désabusée.

N’y tenant plus, je demande à l’équipe : “euh excusez-moi mais la production ne fonctionne pas, Karima ne peut pas faire ses tests et on va mener notre journée comme d’habitude ? Quelle action prenons-nous ?”. Gabriel me répond : “et bien c’est Romain qui a fait la MeP et qui a les accès à la production. Il a tout de suite une réunion très importante sur nos besoins serveurs pour l’année prochaine. Il regardera cela ensuite, à 11:00″. J’enchaîne avec une autre question un peu moins ouverte. “Je comprends : nos besoins serveurs pour l’année prochaine sont donc plus importants que la production que l’on va ouvrir aux clients mercredi prochain ?”  Romain et Gabriel ont du mal à dissimuler leur agacement. Romain part aussitôt à sa réunion. Se sentant un peu coincé, Gabriel consent à demander à Jérôme, un autre développeur, s’il peut regarder le problème de Karima.

10:00 – 11:30 : Investigations et correction du problème

Jérôme s’installe aux côtés de Karima et démarre les investigations. Gabriel, culpabilisant, le rejoint 15 minutes plus tard. Jérôme pressent le problème. Il demande à Adrien et Gustave les autres développeurs, de regarder avec lui. A 10:25 Jérôme est quasiment certain d’avoir trouvé la cause : le moteur de messagerie asynchrone RabbitMQ n’est pas connecté à la solution applicative. Le système installé en production ne peut donc pas fonctionner. Il arrête ce même moteur sur son installation en local et, effectivement la solution présente les mêmes symptômes que ceux de la production. Malheureusement, ils ne peuvent pas valider ce diagnostic pour la production car, pour cela, il leur faudrait les accès et seul Romain (parti à cette réunion de la plus haute importance) en dispose. Ne pouvant valider leur première hypothèse, Gustave, Jérôme et Karima continuent à explorer d’autres hypothèses. Je demande alors : “vous êtes 5 autour du poste de Karima, frustrés de ne pouvoir valider votre hypothèse pour un sujet très important de production alors que Romain est en réunion pour un sujet qui va concerner l’équipe dans 6 mois. Vous avez gaspillé 2:30 (30 mns fois 5 personnes) alors que le moyen de répondre à cette question est dans la salle au bout du couloir. Vous êtes à l’aise avec ça ?” 

Gabriel prend alors son courage à deux mains : “bon je vais sortir Romain de sa réunion.” Une lueur d’espoir éclaire le visage de Karima. Làs ! Il revient deux minutes plus tard : “non je ne peux pas le déranger cette réunion est trop importante.” Jérôme souffle et retourne à son poste pour travailler à autre chose. Gabriel part fumer une cigarette.

Romain revient triomphant de sa réunion à 10:55 : “c’est bon on aura notre deuxième serveur d’intégration continue au printemps [6 mois plus tard].” Il est un peu déçu de constater que le reste de l’équipe ne partage pas son enthousiasme. Jérôme est en effet sur un autre sujet : “Romain, le problème de la prod’ est que RabbitMQ n’est pas connecté.” Romain répond : “impossible j’ai suivi la procédure”. Jérôme perd patience : “viens on regarde”. Romain : “mais non ce n’est pas la peine, je suis sûr qu’il est lancé“. Après une bonne dizaine de minutes de “débat” (on aime bien le débat dans le boulot chez-nous.fr), Romain consent à se connecter et à regarder la production. Et là, bien évidemment, il constate stupéfait que RabbitMQ n’est pas connecté. “Je n’y comprends rien, RabbitMQ marchait quand j’ai lancé l’installation”. Jérôme lui répond : “ben oui mais il faut le redémarrer lorsque tu déploies la solution applicative car sinon il ne pourra pas s’y connecter.” Romain relance l’installation, procède aux vérifications et à 11:25 la production fonctionne convenablement, validée par Karima, soulagée. Ouf ! tout le monde est soulagé : on peut faire une pause et accompagner Gabriel fumer une cigarette.

Voilà donc un problème de production qui a monopolisé 5 personnes de 10:00 à 11:30 (5 fois 1h30 = 7h30, soit une journée/homme de travail jetée dans les poubelles de l’histoire), sans compter le temps perdu par Karima et la frustration qu’elle a ressenti la journée précédente.

J’attends avec impatience la rétrospective du Sprint qui a lieu l’après midi pour voir les enseignements tirés par cette équipe agile.

14:00 – 16:00 – Rétrospective

Gabriel nous présente la structure de cette rétrospective. Chacun doit prendre une carte parmi un jeu représentant des images surréalistes du type celles que l’on trouvait sur les pochettes d’albums de rock progressif des années 70, toutes lestées d’un symbolisme lourd, du genre un bateau qui s’approche d’une chute d’eau, une route qui part dans le lointain mais finalement mène dans une grotte, ou encore une coupe avec des toiles d’araignée sur les poignées (celle que je choisis).

Chacun choisit sa carte puis, à son tour, la présente au reste de l’équipe. Cette dernière doit alors réfléchir à ce que cette carte signifie pour le collaborateur qui l’a choisie. Chacun propose une signification et au bout de 20 minutes le collaborateur donne son explication. Dans ma grande mansuétude, et parce que la vie est courte, je vous fais grâce des nombreuses analyses psychologiques qui aboutissent à des “avancées significatives” (yeux au ciel, oui, encore) : on a un problème de stratégie, on a un problème de vision produit, sans oublier l’inévitable on a un problème de communication. Le point saillant : à force de tourner en boucle sur ces sujets, l’équipe développe une vision insaisissable et négative du projet et de son statut. Elle identifie cependant des “actions” : demander au métier de mieux définir la stratégie et la vision produit ; mieux communiquer (oui : c’est une action inscrite sur un post-it). Etant le coach, je passe en dernier. Je présente l’image de la coupe avec la toile d’araignée et leur propose de gagner du temps (on a pris à peu près 20 minutes par personne) et leur pose mon point : je demande si le sprint est réussi et ce qu’il y avait à réussir sur ce sprint. Gabriel le Scrum Master me répond :

  • Mais oui le sprint est presque réussi. 
  • Comment ça “presque”. Soit il est réussi, soit il ne l’est pas. Quels étaient les objectifs ?
  • Et bien de livrer 6 User Stories.
  • Et les a-t-on livrées ?
  • Ben oui !
  • Alors le sprint est réussi !
  • Ben, presque …
  • Ah et pourquoi ?
  • Parce qu’elles ne sont pas testées …
  • Et bien si elles ne sont pas testées elles ne sont pas terminées, non ? Regarde la definition of done
  • Oui mais dans ce cas ça va déprimer l’équipe car on n’a pas atteint nos objectifs
  • (je prends sur moi et me retiens de ne pas lui montrer qu’avec sa rétrospective à la pochette de Yes, il a complètement démobilisé l’équipe). Gabriel tu te rappelles le premier des 12 principes agiles ?
  • Ben oui, des équipes auto-organisées 
  • Tu es sûr ? Tu veux qu’on regarde ensemble ?
  • Euh non, je ne suis plus sûr, tu m’embrouilles avec toutes tes questions, là. C’est quoi ?
  • Le premier principe agile : “satisfaire le client en livrant de la valeur tôt dans le projet puis de façon régulière”. Si les US ne sont pas testées, a-t-on livré de la valeur au client ?
  • Bon. Euh, non. 
  • Bien ce n’est pas grave. Ce qui est important c’est que l’on comprenne pourquoi pour pouvoir ajuster notre mode de fonctionnement, c’est à cela que sert une rétrospective, non ?
  • Oui. Bon excuse moi je vais coller les post-its sur le tableau.

Une fois les post-its collés au mur avec les actions précisées ci-dessus, Gabriel annonce : bien merci à tous pour cette rétrospective, si vous n’avez pas d’autre point je suspends la séance.

Comme suite au point du matin, je relance ma question : “excusez moi, à quoi sert la rétrospective ?” “A échanger sur notre de travail, non ?” me répond Jérôme. Je rajoute : “que s’est-il passé ce matin ? N’y a-t-il rien à apprendre ?”. Romain exaspéré me répond : “c’est bon on l’a corrigé le problème, c’est derrière nous.”

Il s’agissait la de ma dernière journée au sein de cette équipe. Il se peut qu’elle se soit améliorée de façon significative depuis. Mais comme elle ne donne la priorité ni au client (c’est à dire à la production) ni à ce qu’elle livre (les User Stories non testées), je ne vous cache pas que je suis parti un peu inquiet.

Dans le billet suivant nous présentons une autre étude de cas avec une équipe utilisant une approche de l’amélioration bien plus prosaïque afin de mettre les deux en perspective.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s