Bon alors qui a travaillé sur l’implémentation du pattern visiteur ? Et qui a codé la méthode assembleArticlesToMakeABlog() ? Et c’est bien Ronane qui a développé la modification demandée dans notre programme de gestion des machines à café?

Sais pas… moi je parle à l’équipe et je connais pas leurs prénom.

Alors là, levez la main ceux qui ont repéré l’acronyme dans le titre…

OK! la fin est un peu limite. Il est difficile de trouver une expression qui ait un minimum de sens avec ce terme. Il faut croire que ce mot (composé) est très mauvais à tous les points de vue…

Alors on le dit une fois  clairement : MICRO MANAGEMENT

Pour ceux qui ne savent pas, le micro-management est (et là je m’aide de la définition de wikipédia – n’oubliez pas de leur faire un don de temps en temps, ils essayent encore de nous fournir une information totalement gratuite) :

Le micromanagement est un style de management où le manager observe ou contrôle étroitement le travail de ses subordonnés ou employés.

Ce type de management se caractérise par un contrôle excessif, ou donnant trop d’attention aux détails.

Pour faciliter l’approche du phénomène, je vais d’abord expliquer ma compréhension d’une organisation scrum saine. J’introduirai ensuite le micromanagement dans cette organisation « idéale ». Je dirai quelle en a été mon expérience, les torts qui’il a causé et qu’il cause encore.

Ma première expérience de « scrumisation » d’un service a eu lieu dans une structure où existe une vraie bonne hiérarchie à l’ancienne. Sans en dire trop, je dirais que c’est assez normal pour cette organisation-là. Et pourtant, cette hiérarchie n’est pas aussi opportune au sein d’un service de développement de logiciels, dans lequel la structure elle-même doit favoriser l’initiative, l’acquisition de connaissance, la communication entre les développeurs,…

The scrum way of life

Une des caractéristique de « l’équipe de développement scrum théorique » est qu’elle est seule responsable de la manière dont elle transforme une user story en un « incrément de produit fonctionnel« . Il est du devoir du scrum master de garantir une indépendance suffisante à l’équipe. Des tâches à effectuer peuvent s’ajouter durant le sprint, mais elles doivent émerger d’une meilleure compréhension du sprint backlog, et doivent permettre de réaliser le « sprint goal ». Cette garantie vise à assurer la concentration de l’équipe sur son activité dédiée, afin de maximiser le retour maximum du travail et d’éviter de se disperser en « context switch » . Le « Focus » est une des valeurs de scrum, et s’applique par de nombreux aspects au travail des développeurs : focus sur le goal, focus de l’ensemble de l’équipe sur une ou deux tâches à la fois, focus sur le prochain item le plus important… je vous invite à lire l’article de Stéphanie Ockerman sur la valeur « focus » en scrum pour avoir une vision complète sur cet aspect.

Du coté des petites mains

Dans notre organisation, les développeurs ont trouvé un certain plaisir lié à la possibilité de gérer leur temps et leur travail. Mes consignes étaient claires : « vous prenez toutes les actions et contacts que vous estimez nécessaires pour venir à bout de votre sprint« . En cas de problème extérieur,  c’est le scrum master qui prend son téléphone et son bâton de pèlerin et va trouver qui de droit pour éliminer l’obstacle (gentiment bien sûr… souvent un contact direct et argumenté lève l’obstacle comme par magie). De cette manière, les développeurs peuvent se consacrer au travail technique et s’attacher à trouver des solutions.

Étonnamment, cette manière de (ne pas) gérer l’équipe donne des résultats surprenants. l’émulation entre les membres, les objectifs communs (au point de vue du produit, ou du sprint goal) et la tranquillité ont causé immédiatement un accroissement du rendement journalier (au sens temps de travail effectif par rapport à la journée de présence). D’initiative, l’équipe a adopté un taux de 5h de travail effectif et en commun, sur les 7h36 que compte la journée. Et je ne compte pas le temps entre 7 et 9 heures (heure du daily scrum) où diverses discussions se liaient pour résoudre les dernières de la veille.

A la grosse louche, nous avons obtenu 60% de rendement en temps, si l’on suppose l’un ou l’autre besoin biologique. A ce stade, il fut même bon de jouer un rôle de modérateur, en rappelant à ces braves gens que de faire un break est important dans la journée, et doit être planifié. Pourquoi ne pas aller courir quelques kilomètres. Ceci fait, et un rendement d’environ 50% de travail effectif atteint, nous avons trouvé un compromis agréable, rentable et durable. Les dernières réticences des développeur au sujet du travail en équipe s’évanouissaient (pratiques eXtrême Programming comprises).

Et du suivi du projet…

L’implication du manager est nécessaire à un niveau organisationnel : établissement, respect, inspection et adaptation des processus; recherche et économie rationnelle des ressources nécessaires pour réaliser les objectifs; maintient d’une saine ambiance de travail, du niveau de motivation, de l’implication du personnel. Le déroulement du projet lui-même est du ressort d’un « chef de projet », qui, en scrum, est le product owner. Comme le dit joliment ce nom, il est le possesseur, le mandataire, de la destinée du produit. Il est le gardien qui veillera à ce que le produit remplissent les besoins des différentes parties prenantes. Il est également le seul qui doit décider ce qui composera le produit, dans quel ordre les fonctionnalités seront ajoutées. Enfin il décidera lui-même des actions adéquates si le développement devait s’écarter de sa course idéale.

Les responsabilités sont donc claires : le scrum master enseigne les techniques et veille à l’application de la méthode scrum, le product owner veille sur son produit, l’équipe de développement développe et le manager met en place les ressources nécessaires.

Les frustrations

Maintenant on va parler du problème susmentionné. On a toujours bien dans les parages un manager quelconque qui cherche a avoir un contrôle au plus bas niveau. J’ai expérimenté la présence d’un manager qui n’arrivait pas à accepter les canaux prévus dans scrum pour être dûment informé. Alors que la méthode est pensée pour permettre à une équipe d’organiser son temps pour générer un produit, elle prévoit aussi différents canaux de communication afin de tenir informé l’ensemble de la communauté tournant autour du produit.

Tout d’abord, il est permis à tous de consulter le sprint planning afin de voir l’état du sprint en cours. Qu’il s’agisse d’un grand tableau avec des post-its ou d’un tableau en ligne (les outils ne manquent pas), scrum préconise qu’il soit visible et accessible pour toute personne intéressée.

De même, le product backlog devrait être consultable. De même il devrait être accessible pour toutes les parties prenantes, et permet de savoir ce qu’il reste à faire, dans quel ordre et l’état de la définition des stories.

Enfin, toute personne qui est partie prenante à la définition de l’application est invitée à contacter le product owner, ou à participer au sprint review et à donner son avis sur le contenu du backlog, qu’il soit qualitatif ou qu’il s’agisse de priorisation.

Toute intervention supplémentaire serait malvenue. En effet, elle ne pourrait que semer le trouble dans le travail de l’équipe. Celle-ci a pour objectif de réaliser les stories qui ont été ajoutée au sprint planning. Le contenu du sprint aura été convenu au sein de l’équipe scrum d’un commun accord entre les développeurs et le product owner.

Lorsqu’un autre intervenant veut ajouter des tâches supplémentaire en usant de sa qualité de manager, cela est néfaste. Il trouble le rythme de l’équipe, l’empêche de planifier son travail au jour le jour, ajoute une charge non prévue, et risque de mettre le sprint en péril. Je ne parle même pas de la pression qu’il fait peser sur les collaborateurs, ceux-ci se trouvant entre un product owner désireux que son produit évolue, et un chef hiérarchique qui exige que ses volontés soient accomplies.

En principe le scrum master est censé faire savoir à l’importun que son intervention n’est pas souhaitée. Cependant, dans une organisation fortement hiérarchisée, et faute d’appui de sa hiérarchie, ses pouvoirs sont limités. Seul le dialogue peut lui permettre de trouver une solution… a condition que le fautif accepte de suivre les règles. Si il ne trouve pas cet appui, autant dire que le combat est perdu.

Un petit témoignage perso (et malheureux)

Il faut bien avouer qu’ayant vécu cette situation, j’ai bien essayé de faire comprendre le danger de ces interventions incessantes. Cependant, à l’usure, cela s’est révélé insuffisant. Une super équipe qui était pourtant motivée et assidue a fini par perdre toute motivation. La conscience professionnelle des développeurs a fait que le travail s’est poursuivi, mais de façon bien moins soutenue. Cela s’est rapidement soldé par un, puis deux sprints perdus, où aucun résultat n’a pu être livré. A plus forte raison parce que le produit avait une lourde dette technique (héritée), et que les modifications de fond pour résoudre les problèmes fondamentaux de manière durable n’ont pas pu avoir lieu.

L’interventionnisme et le micromanagement ont été désastreux.

Pour lutter contre ce fléau, il n’y a pas beaucoup de solutions. D’abord, l’organisation doit être convaincue de l’intérêt de scrum, et doit activement veiller à ce que ce genre d’incident n’arrive pas. Éventuellement, le product owner peut intervenir pour défendre son produit.

Dans ce cas-ci, et à ce jour, une solution n’a pas été trouvée, et les prévisions ne sont pas encourageantes…

Le scrum master doit bien être au courant des dangers des interventions externes à l’équipe, et un travail de dialogue avec les principaux acteurs de l’organisation est important afin d’obtenir le maximum de soutien possible. Cela demande parfois l’assaut frontal, et peut être éprouvant sur la durée. Il ne doit pas travailler seul. Il doit faire comprendre à toute son organisation qu’au final, c’est elle qui sera gagnante avec des équipes sereines et assidues…

 

J’espère que ce témoignage pourra être utile à d’autres scrum masters.