Je rencontre de plus en plus de personnes s’inquiétant d’un certain nombre de conséquences négatives voire néfastes de la méthode Scrum et, plus généralement, des méthodes agiles.
De l’autre côté, les spécialistes de la méthode avec lesquels je discute me disent : « C’est parce qu’elle est mal appliquée. »
Je suis dubitatif.
Mon expérience personnelle m’a amené à faire très attention à la façon dont nous formulons et construisons nos phrases. Cette construction traduit notre façon de penser, les connexions implicites sous-jacentes, si bien que ce qui peut paraître anodin et sans conséquence devient, pour moi, très lourd de sens. Les mots et leur contexte d’usage ont une importance particulière pour son émetteur. Avec le recul, rien n’arrive jamais – ou très rarement – par hasard.
C’est pourquoi, contrairement à ce qu’on pourrait penser, je perçois le glissement de vocabulaire de « méthodologie pour un développement agile » à « méthode agile » comme plus que significatif, sans être un hasard.
Scrum, une des méthodes agiles les plus populaires, ne fait pas exception à la règle.
Au risque de me faire quelques ennemis, voici mon analyse du sous-texte ainsi que quelques propositions d’amélioration.
La psychologie du développeur
Pour bien comprendre la méthode Scrum, il faut avant tout comprendre la psychologie du développeur à l’origine car c’est, selon moi, le point essentiel pour comprendre la différence de perspective à l’origine du glissement.
Scrum pour le développement logiciel est fondé sur le manifeste agile. Ce dernier a été édicté en 2001 par des développeurs experts, avec le recul de leur expérience.
La plupart de ces développeurs sont de la génération qui a créé Internet, c’est-à-dire avec des valeurs d’égalité, de partage, d’ouverture et de confiance. Sur Internet, tout le code est ouvert, tout le monde peut proposer des améliorations ; la hiérarchie est horizontale, tout le monde se tutoie.
En développeurs passionnés, ils ont pensé pour des gens passionnés comme eux et, donc, cherchant spontanément à mieux faire.
Comme tout bon développeur, l’administratif n’étant pas leur fort et, de leur point de vue, contre-productif au regard de la société procédurière, une hiérarchie mène toujours à de la complexité et de la lenteur. D’autre part, l’homme étant un animal social par défaut, il est capable de s’auto-organiser.
Ainsi, de l’extérieur, certains pourraient penser qu’ils vivent au pays des Bisounours – mais les faits montrent qu’ils ne sont pourtant pas loin de la réalité.
De son côté, la société pense que tout problème humain – compréhension, perspective, … – peut être résolu par une hiérarchie, des procédures et des « outils ». Le manager tend donc à penser que l’humain n’est pas capable de résoudre les problèmes par l’auto-organisation. ce qui est aussi vrai. Aurcun projet commun ne peut arriver à terme s'il n'y a pas une structure hiérarchique avec une personne capable de trancher – parfois arbitrairement – afin de mettre de l'huile dans les rouages. On ne peut non plus reprocher au manager de justifier l'utilité de son rôle.
Ces deux visions opposées expliquent pourquoi le travail à la maison est si peu répandu alors que l’informatique est le métier qui permet justement de le mettre en place – le cordonnier est le plus mal chaussé – pour la simple et bonne raison que le manager pense – à tort – qu’un individu est fainéant par défaut et que, si on ne le surveille pas en permanence, il n’a aucune raison de faire son travail. Chez lui, sans surveillance constante, il se laissera aller à l’improductivité payée.
Et c’est justement cette perspective qui fait toute la différence.
Les développeurs de la méthodologie pour un développement agile aiment le travail vite fait et bien fait. Leur objectif est de livrer rapidement de la valeur. « Livrer rapidement de la valeur »… ça veut dire « productivité ». Il n’en fallait pas plus pour aiguiser les appétits parce que la productivité implique toujours une augmentation de richesse.
Seulement, les développeurs ne sont pas sensibles aux préoccupations purement matérialistes. Pour eux, l’ouverture, le partage, le travail bien fait comptent bien plus.
Pas de problème, il suffit donc de leur vendre le produit adéquat bien enrobé dans un beau paquet cadeau.
Ainsi naquit la « méthode agile », glissement délibéré d'un vocabulaire à un autre,nis vu ni connu, afin de faire « la même chose, mais en différent », tout en gardant l'agrément « méthologie de développement agile ».
Vous pensez que j’exagère ?
Gestion de projet
Scrum est une méthode de gestion de projet, or la méthodologie pour un développement agile n’a jamais été une méthode de gestion de projet mais un framework d’outils/principes pour le développement. Et le glissement de vocabulaire de « méthodologie pour un développement agile » vers « méthode agile » n’est pas un hasard, il traduit bien la perception et l’objectif des deux méthodes. Car il s’agit bien de 2 méthodes bien distinctes, comme le déplore – sans le savoir – David Thomas.
La gestion de projet est déjà clairement une perspective de manager, là où une équipe auto-organisée à hiérarchie horizontale se contenterait de nommer l’un de ses pairs pour s’occuper des relations publiques et de la paperasse (Scrum Master). Le chef de projet n’existe pas… et pourtant il y a toujours un chef de projet agile pas très loin.
Le chef de projet se cache généralement derrière le Scrum Master.
Le rôle de ce dernier étant de protéger les développeurs des perturbations extérieures, les qualités requises sont communes au responsable/manager traditionnel dont le rôle est de protéger ses gens.
Il n'est donc pas rare de voir d'anciens chefs de projet se reconvertir en Scrum Master ou, pire, en « chef de projet agile ».
Il est beaucoup trop rare de rencontrer un Scrum Master qui n'a jamais été chef de projet auparavant et qui est un ancien développeur ayant évolué directement vers ce rôle grâce à sa connaissance des problématiques agiles et son expertise propre.
La dérive est donc facile. Les anciens chefs de projet changent juste de dénomination, tout en gardant les mêmes réflexes et, surtout, la même perspective. Alors que la méthodologie agile devrait faire de lui un « servant leadership » qui ferait de lui le dernier, il ne garde trop souvent que la partie « leadership », qui fait de lui le premier.
Ce même Scrum Master intègre une structure (projet agile) évaluée et mise en place par une organisation hiérarchique traditionnelle (donc verticale) dont la préocupation majeure est la productivité et le ROI. Hiérarchie verticale qui, encore une fois, par sa perpective verticale ne peut pas comprendre la philosophie sous-jacente de la méthodologie pour un développement agile.
Idéalement, la méthodologie pour un développement agile devrait émerger d'elle-même grâce à l'auto-organisation : une équipe de développement, confrontée à la difficluté du terrain, décidant d'améliorer sa façon de fonctionner en appliquant progressivement la méthodologie agile. Dans ce cas, la décision se fait naturellement (à l'image de la perspective originelle) sans intervention biaisée provenant de l'extérieur par une décision verticale.
Le mythe de la hiérarchie horizontale
Qu’à cela ne tienne. Ce n’est pas bien grave. Chef de projet ou Scrum Master, c’est kif-kif. Ce n’est qu’un problème de vocabulaire.
Eh non !
Avec la méthode agile, on a vendu la hiérarchie horizontale. Parce que dans une entreprise, il y a toujours une hiérarchie. Les organigrammes ne mentent pas.
Cependant, dans les faits, la hiérarchie est rarement verticale pour celui qui est en bas de l’échelle. Il ne côtoie généralement que son N+1 et N+2, rarement plus. Donc la hiérarchie, selon sa perspective à lui, est simple et plutôt horizontale, dans tous les cas.
Cette limitation de vision n’est pas très importante en soi. Comme l’a rappelé Simon Sinek, le rôle d’un dirigeant n’est pas prendre soin de tout le monde, mais uniquement de ses proches collaborateurs qui prendront soin de leurs proches collaborateurs, …
La hiérarchie horizontale est donc un mythe, pourtant vendue par la méthode agile juste pour convaincre les développeurs – généralement des individus sensibilisés aux libertés individuelles. C’est un argument qui ne coûte rien à celui qui le propose.
De plus, il ne faut oublier que la hiérarchie s’instaure naturellement à partir du moment où un individu a le pouvoir d’en faire licencier en autre et que ce dernier n’a pas ce même pouvoir en retour. Cette asymétrie impose de fait une hiérarchie verticale et à sens unique. Et cette verticalité à sens unique implique de fait une responsabilité de dominant sur l’autre.
Le principe de responsabilité
Le développeur, en adulte responsable est soumis au principe de responsabilité, ce que rappelle bien Adrian Cockroft (Netflix), rien ne vous interdit d’être créatif et innovant, mais sans oublier le principe de responsabilité. Si vous prenez un nouveau chemin et que vous introduisez une erreur, vous devez la corriger, même si vous devez y passer la nuit – là où Scrum limite la semaine normalement à 40 heures. Donc, dans la pratique, le développeur ne prendra pas le risque de travailler toute la nuit sachant qu’il doit délivrer d’autres fonctionnalité et que son errement abaissera la productivité.
Il y a donc bien ici un double langage. Même si rien n’empêche le développeur d’être créatif, il n’a généralement pas le temps de l’être car la créativité requiert du temps improductif.
Et c’est bien la limite de de la hiérarchie horizontale. Le rôle du responsable est de protéger ses gens des dangers extérieurs mais aussi de leur permettre de s’épanouir en toute quiétude, même – et surtout – en cas d’erreur. Car le succès est toujours fondé sur un certain nombre d’échecs.
Or, avancer le principe de responsabilité individuelle est certes normal, mais contre-productif dans la créativité et donc l’innovation, mais aussi le bien-être des employés. Autoriser les autres à se tromper est l’indicateur ultime de la confiance et nous acceptons – ou pas – d’en prendre la responsabilité partagée. Reporter la pleine et entière responsabilité sur l’employé lui fera bien comprendre qu’il n’a pas le droit à l’erreur. S’il commet une erreur, il ralentit le groupe – dans le meilleur des cas – ou prend la porte – dans le pire des cas.
Ainsi donc, le développeur n’a aucun intérêt à être transparent par défaut avec celui qui peut le licencier.
La transparence
La hiérarchie s’instaure pour la simple et bonne raison : celui qui est en haut doit protéger ceux qui sont en bas des dangers extérieurs. C’est à lui d’aller au combat pour protéger les autres et risquer sa vie/son poste si c’est nécessaire. En échange, ses protégés acceptent qu’il ait des avantages et les privilèges. Son revenu supérieur est une compensation pour le risque supplémentaire encouru et la fragilité de sa position.
Cette asymétrie implique aussi que celui qui est en bas n’a pas à faire confiance à son supérieur par défaut tant que ce dernier n’a pas prouvé sa capacité à prendre ses responsabilités.
C’est donc au responsable de confirmer ses compétences de responsable en premier lieu afin d'obtenir la confiance – alors que la confiance est généralement spontanée pour des individus de même rang. C’est à lui de mettre en place de la transparence afin de l’obtenir des autres. On attend de lui qu’il montre l’exemple avant de le suivre.
L’asymétrie implique donc, de fait, une absence de transparence par défaut. Et cette asymétrie ne pose de problème à personne. Dans une démocratie saine et équilibrée, personne ne s’étonne de l’obligation de transparence du pouvoir – qui doit rendre des compte sur les privilèges dont il jouit –, ce dernier ayant pour tâche de protéger la vie privée et l’intimité de ses administrés – donc tout le contraire de la transparence.
A contrario, un régime totalitaire qui voit des dangers partout, dans chaque individu, met tout en place pour garder le contrôle… grâce à la transparence. Le besoin de transparence est généralement le premier signe du besoin de contrôle.
Acquérir la confiance des autres quand on est de niveau hiérarchique supérieur est donc compliqué. Et le responsable n’est pas idiot, il le sait bien.
Le rôle du responsable implique une protection par défaut de son protégé. Or, il arrive souvent que ce ne soit pas le cas. C’est bien visible lorsque, par exemple, le développeur est en conflit avec une personne plus gradée d’une autre équipe. L’expérience démontre trop souvent que le manager s’empresse de désigner le coupable et le développeur sera licencié sans personne pour venir à sa rescousse et sans procès équitable. Le développeur n’est pas idiot non plus, il en est parfaitement conscient.
On est donc toujours plus réticent à faire preuve de transparence avec une personne qui a le pouvoir de nous licencier, notamment si on commet une erreur – ce qui peut arriver à n’importe qui. Une erreur mal perçue et on est viré. On n’a pas généralement le droit à l’erreur sous peine d’être pris pour un incompétent ou un saboteur ou un râleur. Le réflexe naturel est de se protéger.
Il faut donc ruser… grâce à la hiérarchie horizontale. Plus de hiérarchie, plus de méfiance… et la transparence est acquise sans effort.
Cependant, il n’y a pas de transparence dans Scrum. La preuve ? C’est écrit noir sur blanc dans le rôle du Scrum Master : protéger l’équipe des perturbations extérieures.
Ça veut dire l’absence de transparence pour le Scrum Master.
Si des bruits de couloir faisaient état d’un plan de licenciement, ces derniers pourraient déconcentrer les développeurs. Pour qu’ils demeurent isolés et concentrés, il faut à tout prix éviter de propager les rumeurs. On ne peut pas isoler en étant transparent.
Le rôle tampon du Scrum Master agit dans les deux sens : prendre la pression et les coups à la place de son équipe, mais aussi les protéger des coups et des pressions qui viennent de l’extérieur.
Pourquoi cette transparence est-elle si importante ?
En soi, la transparence n’est pas importante. Les démocraties fonctionnent très bien avec l’opacité de la vie privée. Un développeur pourrait très bien faire son travail normalement, sans rendre de comptes en permanence, juste en relevant quelques points de blocage de temps en temps, le reste étant à sa discrétion, bien protégé sous le sceau de la confiance.
Mais c’est sans compter la perspective du manager qui voit dans chaque individu un danger. L’information étant le pouvoir, le seul moyen d’éviter les catastrophes est d’avoir l’information le plus tôt possible, soit pour réagir, soit pour maquiller. De là, naît un besoin maladif pour la transparence, car la transparence c’est le contrôle.
Tout comme « ceux qui n’ont rien à cacher n’ont rien à craindre » est le leitmotiv de ceux qui n’ont pas confiance, la transparence vendue n’est que l’expression du manque de confiance du micro-manager qui a trouvé là un moyen de vendre là une méthode qui lui offre le contrôle sur tout et sur tous, en temps réel et de leur plein gré.
Du micromanagement ?
Contrôle continu et en temps réel de la performance, délégation de responsabilité sans délégation d’autorité, la direction d'un projet peut être changée plusieurs fois dans des directions opposées – ce qui n’est pas anormal si la méthodologie a pour but de suivre le changement.
Oui, nous avons ici beaucoup de signes précurseurs du micromanagement.
C’est pourquoi je vois très souvent des micromanagers se précipiter sur les méthodes agiles car ils ont bien compris l’intérêt. Surtout le leur.
La méthode agile vend de la transparence pour palier le manque de confiance, qui est généralement compensée par le micromanagement.
Sous couvert de respecter les lois édictées par le déveoppeur lui-même, ce dernier donne tout clef en main. C’est génial ! Pourquoi se priver ?
La méthode agile est juste une méthode de gestion de projet qui industrialise le micromanagement en poussant à l’extrême les principes du framework de la méthodologie pour un développement agile. C’est une nouvelle définition du « Extreme Programming ». Même vocabulaire; sens différent.
Productivité et rythme de développement
Si le micromanagement n’était que le seul problème ! Micromanager en méthode agile ou pas, les développeurs peuvent le gérer – comme avant.
Cependant, n’oublions pas que le but ultime est de « livrer rapidement de la valeur ».
En isolant le développeur des perturbations extérieures, on l’aide à se focaliser sur ce qu’il sait faire de mieux (et ce pour quoi il est payé) : développer (et seulement développer). Comme l’objectif est de délivrer rapidement de la valeur, la méthode met tout en œuvre pour minimiser les temps de latence et les goulots d’étranglement.
Cette méthode n’est pas nouvelle, elle a été mise en place par… Taylor et la division du travail, ce qu’on appelle le Taylorisme.
Ce n’est pas pour rien que la méthode Scrum a d’abord été mise en place dans l’industrie avant de gagner l’informatique. Ce n’est pas pour rien non plus que la majorité des exemples qui fonctionnent proviennent de l’industrie automobile et aéronautique car la division du travail s’y prête particulièrement bien et ces entreprises impressionnent par les milliards de revenus générés par leur succès.
En soi, livrer de la valeur n’est pas le problème. On en paie pas les gens à se tourner les pouces. Cependant, le manifeste agile dit : « Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. »
Et c’est là que le bât blesse.
Mais le problème de Scrum n’est pas si ça fonctionne, mais si ça fonctionne sur la durée.
Or, l’objectif de la méthode agile est de délivrer rapidement.
On a fait de l’urgence le fondement même de la méthode. Le point central et faible de tout développement logiciel est le développeur car c’est, en définitive, celui qui réalise. Sans lui, rien est possible. On a donc mis une méthode en place pour le rendre disponible et corvéable à souhait, en fonction des priorités du chef de produit. C’est au développeur de s’adapter à l’impatience des autres là où la méthode classique disait «Hé ben, vous allez attendre !».
Et toute la difficulté est de trouver l’équilibre de cette maintenabilité indéfinie. Or, selon mon expérience et mes observations, c’est très rarement le cas. Je rencontre de plus en plus ce chefs de projets qui s’inquiètent et s’interrogent sur la façon de faire de l’agile sans risque un burn out dans son équipe.
Il y a encore 15 ans, le burn out était réservé aux responsables. À présent, c’est le développeur qui le subit.
Et c’est vraiment ça qui m’inquiète. La méthode agile est une optimalisation pour garder le développeur en flux tendu afin d’avoir l’efficacité maximale. Pour prévoir le futur, il suffit de transposer le présent ad vitam aeternam. Ça marche pour une machine, mais pas pour un être vivant.
Or, l’humain, s’il est capable de piquer des pointes de vitesse durant de courtes périodes, il peut se fatiguer sur le long terme. Il se fatigue d’autant plus qu’on ne lui laisse aucune distraction pour s’ennuyer.
Le paradoxe de la créativité
Comme l’a bien rappelé Derek Muller (Veritassium) dans sa vidéo « Why Boredom is Good For You », la créativité requiert une dose d’ennui pour être efficace.
La créativité est, en effet, un processus long qui, comme le sommeil, requiert du temps pour se mettre en place, et pas seulement 5 minutes par-ci par-là le temps d’un café.
Le but de la méthode agile étant d’industrialiser la performance du codeur en limitant les moments improductifs, on ne lui laisse plus la possibilité de s’ennuyer, donc de laisser son esprit vagabonder… et donc d’être créatif.
Et ça, sur le long terme, c’est contre-productif car la créativité est nécessaire au changement et à l’amélioration donc la productivité. Sans créativité, pas de changement. Ce qui ne change pas finit par disparaître.
Le manifeste agile dit : « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »
Or, ceci n’est pas fait en profondeur. Les réflexions sont succinctes du simple fait de ne pas avoir assez de temps pour être créatif.
Sur le long terme
Nous arrivons à un autre problème. Au bout de quelques années, les développeurs agiles ont passé leur temps à développer. Ils sont très bons… mais n’ont pas eu le temps de faire autre chose parce qu’on ne leur a pas laissé le temps (autre que leur temps personnel chez eux, durant les jours de congé). Et ceci finit par les pénaliser dans leur carrière et la productivité de l’équipe.
Beaucoup vivent une frustration ambiguë. D’un côté, ils sont bons dans ce qu’ils font et sont contents de leur travail. Mais de l’autre, ils ont plus l’impression de stagner professionnellement.
Conclusion : quelques suggestions d’amélioration
Les cordonniers sont les plus mal chaussés
Par exemple, les développeurs BI ne profitent jamais des outils de reporting pour monitorer leur propre activité et doivent développer leurs propres outils. C’est là une perte de temps. En leur permettant d’utiliser à leur compte des outils de l’entreprise ils pourraient acquérir de nouvelles compétences pour évoluer dans leur carrière tout en améliorant leur propre travail.
Réfléchir sérieusement aux moyens de devenir plus efficace
Je n’ai jamais vu aucune équipe agile avoir un backlog pour ses propres sujets, ses propres outils et ses propres axes d’amélioration.
Or, l’amélioration personnelle nécessite du temps, du sérieux, de la discipline et de la rigueur.
Nous prenons l’amélioration comme accessoire et trop à la légère. « Plus tard, quand nous aurons le temps ». C’est le problème d’une méthode qui optimalise le rendement et l’impatience.
Ce qui fait que les problèmes des clients sont résolus… mais pas ceux de l’équipe.
Permettre un temps d’improductivité
La créativité nécessite du temps personnel afin d’être confronté à ses propres idées.
Il faut donc se réserver du temps improductif pour penser et s’égarer. En règle générale, le temps optimal qui fait consensus est 1/2 journée par semaine durant lequel le développeur pourra travailler sur un sujet de son choix (par exemple, celui du backlog d’équipe), de la façon qu’il veut, sans aucune limitation autre que ses propres ressources.
Auto-organisation : permettre la mobilité
Réfléchir est une chose, mais réfléchir avec les personnes de votre équipe, composée de développeurs comme vous n’apporte que rarement un intérêt créatif. Pour confronter efficacement ses idées, il faut sortir de sa zone de confort. Une équipe pluridisciplinaire n'est pas non plus la solution car les memebres de l'équipe sont généralement inposés et non choisis.
Or, que faisons-nous ? Nous rassemblons dans un même bureau les individus travaillant sur un même projet et une même technologie.
En permettant à chacun de profiter de sa 1/2 journée improductive pour s’installer dans un autre bureau, dans une autre équipe de son choix, on lui permet d’être confronté aux personnes de son choix qui le stimulent intellectuellement plus. C’est aussi ça l’auto-organisation !
De là naîtra une plus grande créativité et satisfaction personnelle. Certes au détriment d'une perte de productivité à court terme. Mais on n'a rien sans rien.