Le middle management cause de tous les problèmes ? 

Dans le petit monde du coaching agile, il y a un certain consensus qui traîne pour nommer le middle management comme étant la plus grosse contrainte dans le chemin de l’agilité. Encore dernièrement sur tweeter, cette information a circulé (cf alistair et jurgen).

Middle Management

J’étais, jusqu’à peu de temps, assez d’accord avec cette assertion. Dans mes expériences de salariat passées, à chaque fois que j’avais tenté d’entreprendre une démarche agile, systématiquement, nous sommes entrés en guerre contre le middle management. Je ne prétends pas en connaître les raisons. De manière complètement naïve, je penserais à un mécanisme de défense : défendre son job, défendre ses intérêts, etc. On pourrait aussi parler de peur : la peur de faire confiance, la peur de changer, la peur d’être le seul responsable en cas d’échec. Bref, je vous laisse aller creuser l’avis de Jurgen et Alistair.

Crushing FireCeci dit, les derniers tweets cette semaine m’ont amené à me reposer la question. Le middle management est-il réellement la plus grosse contrainte ? Le fait est que dans les contextes dont je parle, nous avons obtenu des résultats. Sans éliminer ce frein, nous avons pu, la plupart du temps, le réduire considérablement. Comment avons nous obtenu ce miracle ? En ne poussant pas seuls la démarche, mais en étant appuyés par l’équipe entière. Sans ce mouvement de masse de la « base », honnêtement, nous aurions épuisé nos forces, coincés entre deux piliers inamovibles.

Comment l’équipe s’est-elle retournée contre son middle management ? Par l’éducation j’ai envie de dire. Par la découverte que le « command and control » et la pression n’étaient pas des faits établis, et qu’ils pouvaient être compensés par plus de professionnalisme. En pratiquant le TDD, le refactoring, en estimant elle-même les histoires, tout ceci étant souvent fait dans le dos du middle management, l’équipe petit à petit a pris conscience de l’absurdité d’un commandement en pyramide, et mis le doigt sur les gaspillages du projet. Dans le cas le plus extrême auquel j’ai pu assister, le middle management en place a carrément été viré.

Morale de l’histoire ? Certes, le middle management est une énorme résistance, mais le faire changer n’est pas possible sans résoudre une première contrainte : le manque d’éducation des développeurs. Dis autrement : les mécanismes de contrôle ne sont peut être là que pour compenser le manque de professionnalisme des développeurs que nous sommes.

Comme l’explique très bien Uncle Bob dans The clean coder, un professionnel est capable de dire non. En ayant conscience d’avoir un vrai travail, pas juste une étape en attendant d’être chef de projet; en ayant des disciplines de production de code, comme le TDD et le refactoring, nous gagnons la connaissance et la confiance suffisante pour dire « non » face à des demandes ou des situations aberrantes. En devenant professionnel, ce même management n’a plus besoin de craindre que nous ne fassions rien, que nous livrions trop tard ou que nous les truandions sur les coûts réels. Du coup, en devenant transparents, la nécessité apparente du « command and control » devient inutile.

Quand je parle de dire « non », je n’invite pas à la revendication facile de « eux versus nous », mais vraiment à un « non » calme et posé d’une personne éduquée qui, en fonction des données, sait dire « non » quand elle sait qu’elle va dans le mur ; et qui, en contre-partie, propose des solutions créatives. Sinon, nous tombons dans la « lutte des classes » bête et méchante, et dans l’émergence d’un certain protectionisme comme en parlait Olivier Azeau.

C’est donc sans grande originalité que je viens de décrire le cercle vicieux de la théorie X, et je reste convaincu qu’il peut se briser non pas que en ayant le soutien d’un top management éduqué, sorte de despote éclairé des temps modernes, mais bien par l’éducation et la professionnalisation de nous autres, développeurs.

C’est pourquoi, chez Arpinum, nous enseignons en 4eme et 5eme année de cycle d’ingénieur, c’est pourquoi nous co-organisons l’agile tour, nous participons au dojo d’Okiwi, nous tenons ce blog et faisons des vidéos. Nous ne sommes pas les seuls bien sûr à diffuser ces idées et plus nous serons nombreux, plus le glas des sociétés dilbertesques sonnera. Je pense également que finalement, le mouvement du Craftmanship, et les idées véhiculées dans Apprenticeship patterns tendent vers cette réalité.