Rétrospective sur SCRUM, 1ère partie🔗

Cela fait maintenant pratiquement 4 années que je pratique, à titre professionnel, la méthode SCRUM, à titre de SCRUM Master. Je n'en ai jamais parlé auparavant et il est temps de réparer cette injustice. Car s'il y a bien un truc qui a changé ma manière d'appréhender la façon dont je travaille, c'est bien cette expérience. A cet égard, elle constitue, à mes yeux, une véritable révolution.

Du coup, il fallait que je prenne un peu de temps pour en parler, pour faire une rétrospective sur ce sujet. En ces temps de bilan, ça semble être le bon moment. Malgré tout, un seul article ne pourrait suffire, il me faut faire une petite série pour que les lecteurs puissent mieux comprendre ce qui a changé, ce qui m'a affecté et ce que j'ai pu comprendre de tout ça. Et cela me permettra également de mettre mes idées en forme et d'essayer de prendre un peu de recul.

Encore une fois, et dans la majorité de mes écrits, je ne me présente pas en tant que donneur de leçons ou expert du sujet. Je tiens juste à raconter ce qui m'a frappé, ce qui me pose problème au quotidien et ce que j'ai constaté qui marche. Et souvent, je n'ai pas peur de le dire, je fais des erreurs, comme tout le monde en fait.

Aujourd'hui, je vais commencer par vous exposer tous les problèmes de "travail" que j'ai pu rencontrer ces vingt dernières années en faisant la liste de tout ce qui constitue, de mon point de vue, les limites d'un fonctionnement structuré, en équipe, à plusieurs, dans une organisation.

Si dans les années précédentes, depuis mes débuts dans le monde professionnel, j'ai toujours essayé de faire au mieux dans le travail, j'ai rapidement été confronté aux nombreux problèmes que finit par rencontrer toute organisation, tout groupe de personnes qui essaient de travailler ensemble.

Je travaille dans la fonction publique française (d'État mais aussi territoriale) et j'ai également passé un été dans une boîte privée industrielle à mes débuts (même brève, elle a été véritablement une expérience psychologique qui a finalement fortement orienté beaucoup de mes choix et surtout apporté un regard compréhensif face aux travailleurs, à leurs patrons et aux forces économiques du monde du travail).

J'ai travaillé dans des grosses unités (un gros truc centralisé de l'administration centrale d'un ministère), des petites unités (une équipe de 4 personnes), dans des trucs mixtes, en inter-ministèriel, en inter-équipes. Ce n'est pas une expérience "totale" mais disons que je ne me suis pas contenté de rester au même point, au même endroit pendant 20 ans. Sans pour autant pouvoir me qualifier de nomade du travail !

Mon expérience est forcément teintée, limitée et à prendre avec des pincettes et du recul. Néanmoins, dans ce qui va suivre, les "choses" qui me posent problème semblent communes, peu importe la structure de travail et c'est pour ça que j'en parle.

Pour faire simple, voici les principaux écueils que j'ai recontrés, sans priorisation:

• Changer les choses, le fonctionnement, c'est difficile. On se heurte à une inertie folle et écrasante.
• Même les gens motivés finissent par lâcher l'affaire.
• On se retrouve à faire des choses vides de sens, sans réelle valeur ajoutée. On a oublié l'objectif essentiel.
• On finit par se retrouver confronté à une paperasserie débordante qui n'a d'autre objectif que de se couvrir des erreurs des autres ou de décourager les personnes de faire telle ou telle action.
• On a du mal à échanger efficacement entre équipes ou entre agents, à partir du moment où on fait partie d'une structure. La discussion et la communication se retrouve finalement pilotée par la hiérarchie ce qui est souvent limitant.
• Les jeux d'influence sont tous non transparents, masqués et il n'y a pas de lieu pour qu'ils puissent s'exprimer: c'est le règne du non dit et ça pose de vrais problèmes. Ce n'est pas un fonctionnement collectif malgré le fait qu'on travaille à plusieurs.

Je vais maintenant développer chacun des points sus-cités.

Dans les "choses" qui m'ont toujours frappé, il y a d'abord ce que je qualifie de résistance au changement systémique qui tend à faire en sorte d'amener un vrai statu-quo.

Je pense qu'on l'a tous vécu à un moment ou un autre. Parfois, on a besoin de changer quelques virgules, dans un fonctionnement, un design, un processus, des choses qui paraissent insignifiantes. Et pourtant, il faut développer des trésors de patience, de discussions, de persuasion pour parvenir à changer cette petite virgule. On a l'impression de demander la lune et de se confronter à une peur panique de la moindre évolution. C'est comme si on allait tout changer alors qu'en fait on ne veut modifier qu'à la marge (mais cela reste important à modifier).

Je me suis toujours heurté à ce phénomène, dès le début de mes travaux. Et ça n'est pas compatible avec ma vision des choses, orientée sur le factuel d'un ordinateur: si un fonctionnement n'est pas optimal ou demande à être modifié, il ne faut pas hésiter, il faut y aller.

Ce n'est pas que tout changement constitue une avancée en soi. Une innovation n'est d'ailleurs pas toujours un progrès. Mais souvent, on se retrouve confronté à une pratique ou une activité qui présente de nombreux défauts. Et puis, d'une manière générale, les contextes sont toujours en train d'évoluer, de changer et qu'on le veuille ou non, il faut adapter la manière de faire. Il faut aussi savoir rester humble parce qu'il est toujours compliqué ou non essentiel de prévoir tous les cas qui pourraient survenir (à moins de s'appeler NASA), même avec une bonne analyse de risques. On finit toujours par se retrouver face à une situation inédite qui remet en question tel ou tel élément qu'on pensait stable ou invariant. En plus, de ça, je pense que les êtres humains sont finalement des êtres en changement permanent et non des robots pré-programmés, fixes.

Dans ma "branche" professionnelle, avec le recul, je me rends compte maintenant que même une politique publique qui est quelque-chose qu'on tend à faire durer dans le temps a finalement une durée de vie de plus en plus limitée, de plus en plus courte (je ne dis pas que c'est une bonne ou mauvaise chose). Le temps de l'action publique s'accélère de plus en plus avec celui de l'action politique. Et puis, par la force des choses, on assiste également à des changements fréquents des décideurs politiques (tous les 5 ans pour l'Etat, tous les 7 ans pour la territoriale) ce qui m'amène à dire qu'une politique publique qui normalement devrait répondre à une vision claire, sur un objectif de long terme n'a finalement plus qu'une durée de vie ultra-limitée de 5 ans. En plus de ça, son évaluation à mi-parcours (qui est plutôt une bonne chose pour éviter de se planter totalement) fait que les éléments qui ont été mis en place pour porter cette politique au départ peuvent changer 2 ans après ce lancement. Cette mouvance, ce besoin indispensable de fluidité et d'adaptation fait que, qu'on le veuille ou non, il faut sans cesse ajuster, y compris et surtout en matière de service public. Il reste des fondammentaux très stables mais j'ai pu mesurer qu'il y a toujours du changement. Ces modifications doivent se retrouver dans le travail des agents publics sinon on se retrouve à participer à l'échec d'une politique publique: à partir du moment où le "logiciel" ne suit plus l'idée porteuse, ça ne peut pas bien fonctionner.

Au final, dans la réalité quotidienne, on a souvent affaire à un fonctionnement qui n'est pas optimal voire pas du tout adapté et qui risque de mettre les agents et les citoyens dans des situations assez pénibles à vivre. En bon ingénieur, on tente de la corriger… pour se rendre compte que finalement c'est super dur de faire même de simples modifications, pourtant imposée par les textes.

Super dur parce que dans une organisation qui vit, j'ai l'impression que finalement, le système s'est adapté aux défauts, ils ont été acceptés, pire, ils font partie du système. Et dans ces cas là, autant dire que le changement, ce n'est pas pour maintenant !

Combien de fois j'ai été confronté à ça. J'ai déjà dû prendre mon bâton de pèlerin pour convaincre des cadres N+2 pour pouvoir simplement modifier une inter-action ou un simple processus entre deux équipes au niveau N. Il fallait rédiger des tonnes de doc pour réussir à convaincre, en parler pendant plusieurs heures, faire des rapports coûts/risques, faire des simulations. J'y ai passé des heures et des heures et je me suis souvent retrouver à essayer de démontrer à une assemblée de super-cadres que la terre était effectivement ronde.

J'ai connu de petites victoires mais aussi de grands échecs qui m'ont vraiment coûté beaucoup: du temps, de l'analyse et de l'énergie. Passé plusieurs années j'ai même cru qu'il fallait que j'arrête, que je reste dans mon coin. Mais c'est plus fort que moi. Quand je suis face à une inertie générée par un système d'organisation qui ne va pas dans mon sens (celui d'une adaptation, une adéquation avec un certain niveau d'efficacité), je ne peux m'empêcher de vouloir m'y opposer. Mais Dieu que ça demande de la force mentale…

Mais avec le temps, je me suis rendu compte que ça venait essentiellement du fait que rien n'existe dans la structure ou l'organisation pour vraiment "gérer" les adaptations ou même simplement, les accueillir. Rien n'existe que le commandement hiérarchique pour orienter l'organisation dans tel ou tel sens ce qui représente un premier niveau mais qui est plus un palliatif qu'une véritable solution. Au final, cette conduite du changement produit peu et il est rare de faire les évolutions nécessaires ou alors, à contre coeur ce qui les fragilise fortement.

Pire encore, il faut produire ou promettre un changement dans la perfection, sans aucun droit à l'erreur, ce qui est matériellement impossible. Il n'y a souvent pas grand chose pour faire des tests d'évolution. On reste dans le processus figé car parfait (ou l'inverse peut-être).

En conclusions, j'ai l'impression que la peur du changement, engendrée par ce besoin d'absolu, paralyse tout le monde et nous incite au statu-quo alors que tout le monde se rend compte qu'on ne peut pas continuer comme ça.

Bien souvent, l'organisation met en oeuvre des trucs dont on pense avoir vraiment besoin mais qui ne servent pas à grand chose, qui n'ont pas de valeur ajoutée (dans le sens du vocabulaire SCRUM/Agile).

L'exemple le plus flagrant est représenté par la foultitude de pointless meetings. Ceux qu'on reconnaît facilement car ils durent 3 à 4h et où tout le monde amène son PC portable pour faire autre chose pendant la réunion. Car, de mon point de vue, une réunion, ça sert essentiellement à synchroniser les gens pour prendre des décisions. Une réunion, ça ne doit pas servir pour savoir exactement ce que font les uns ou les autres en détails, ce dont on se fout totalement.

Or mon expérience tend à me démontrer que synchroniser des gens pendant plus de 20 minutes, leur demander de s'écouter tous avec attention au delà de cette période de temps est impossible pour le cerveau humain. Pourtant, j'en ai fait de ces réunions longues et pénibles et il m'arrive encore d'en faire, voire de les animer. C'est devenu la coutûme, la norme. La valeur ajoutée de ça est proche de l'ensemble vide. Au mieux, ça donne du temps aux cadres de pouvoir gérer leur paperasse pendant un temps calme, en étant pas dérangé pour un oui ou un non.

A l'inverse, faire des réunions courtes a de nombreux avantages:

• Ça habitue les participants à participer, à être actifs.
• Qui dit être actif dit avoir préparé la réunion.
• Qui dit avoir préparé la réunion implique de viser une certaine forme d'efficacité, de synthèse, de focus.
• Ça permet aux gens d'apprendre à se faire confiance: on n'a pas toute l'actualité de tous les services et ce n'est pas grave, de toute manière, ils ont notre confiance et c'est pour ça qu'ils sont payés.
• Ça permet d'avoir un lieu dédié à des échanges actifs plutôt que subis, où la parole se libère un peu plus car on a moins peur de se réunir en sachant que ça ne vas pas nous consommer 3h de temps précieux.

Quand une réunion doit durer plus de temps que ça, ça n'est plus une réunion, c'est un atelier: un lieu et un temps où les gens vont travailler ensemble, sur un sujet, en se répartissant les rôles; en étant le plus souvent actifs.

Je pourrais également parler des processus où on a oublié à quoi ça servait mais qu'on fait quand même, par habitude ou par réflexes. Par exemple, c'est surtout vrai au niveau des ressources humaines, on demande aux agents de remplir des tonnes de paperasses qui ne seront finalement jamais lues ou sorties des archives. On demande de faire des copies de copies, de suivre un protocole complexe, tout ça pour rien ou pour gérer des situations qui n'arrivent jamais ou très peu souvent. Très souvent, on essaye de prévenir un risque qui survient rarement et qui peut facilement se contourner avec des mesures différentes, souvent plus efficaces.

Si je devais prendre un exemple de truc non optimal sans réelle valeur ajoutée que je vis, ce serait la gestion des remboursements de frais de transport en commun dans mon organisation actuelle. Ainsi, on me demande de fournir tous les tickets originaux de train, le justificatif de paiement, la preuve d'achat (beaucoup de papier), pour effectuer la prise en charge employeur des frais de transports en communs (une obligation légale depuis de nombreuses années). Je dois envoyer le tout par courrier papier au centre. Cela à l'air anodin comme ça mais dans la pratique, ce n'est pas si simple et surtout, je n'arrive pas à voir la valeur ajoutée de la procédure.

Car elle a de sacrés inconvénients:

• Ça oblige probablement 3000 à 5000 personnes d'envoyer mensuellement 4 papiers dans un courrier papier au lieu de pouvoir le faire en ligne. Ce qui oblige de payer des agents pour gérer la masse physique de papier (transport/archivage/traitement/etc.).
• Ça oblige 3000 à 5000 personnes par mois à faire des photocopies de leurs titres de transport ainsi que des nombreux justificatifs de paiement, pour pouvoir garder une preuve de leur côté.
• Ça oblige 3000 à 5000 personnes à tout le temps faire attention à bien récupérer tous les éléments. Ces derniers ne sont pas généralement pas fournis par défaut (les preuves d'achat et tout ce qui va avec) et il faut penser à les demander expressément.
• Pire, si tu as fait un oubli (ce qui peut arriver à n'importe qui avec un comportement par défaut qui va à l'encontre de la procédure), tu peux t'asseoir sur une somme significative (on est dans les 100€ par mois quand même).

Le pire, c'est qu'après mûre réflexion, la procédure est lourde pour tout le monde (les bénficiaires comme ceux qui sont en charge du traitement) sans offrir une réelle sécurité sur les paiements et les fraudes.

Déjà, la procédure vise à se prémunir d'un risque extrèmement faible de falsification de tickets de train. Ce risque est très faible parce qu'il me faudrait prendre un temps non négligeable pour effectuer cette falsification. Mais surtout, il est très facile de se prémunir de ce risque en croisant d'autres données disponibles (le lieu de résidence, la distance à parcourir, les prix des tickets qui sont publics dans le cas d'un abonnement et le calcul d'un trajet en voiture). De surcroît, je peux toujours frauder, c'est un peu plus compliqué mais pas vraiment impossible pour quelqu'un de motivé: je peux facilement acheter une imprimante SNCF réformée ainsi que le papier qui va avec et générer de faux tickets qui paraîtront originaux.

Par ailleurs, en cas de suspicion de fraude, il faudra faire une vraie enquête qui devra mobiliser tous les facteurs externes sus-cités (lieu de résidence, distance à parcourir, etc.). Au final, ça me demande d'investir plus de temps pour la procédure, de transporter plus de papiers, de faire plus attention lorsque j'achète mes billets de train et cela amène des situations où je suis dans l'incapacité de me faire rembourser (mince, j'ai égaré les preuves).

Enfin, tout le temps passé à gérer du physique, c'est autant de temps en moins pour faire de vrai contrôles, à l'aveugle ou en pilotant des requêtes sur une base de données, en se basant sur des évènements. Plutôt que de demander à 5000 agents de passer 30 minutes par mois à gérer ce truc, c'est sans doute plus rentable de minimiser leur temps de saisie et de renforcer l'équipe qui gère cette mesure avec des moyens plus modernes et à vraie valeur ajoutée. Dans l'idéal, on pourrait même imaginer un service pro-actif qui te rappelle quand tu as oublié de faire ta déclaration ou qui te la pré-remplie à l'avance pour ta faciliter la tâche. Vous allez me dire que c'est impossible et moi je vous dirai que même les impôts le font pour un truc très sérieux comme la déclaration annuelles des revenus. Ça doit donc être possible…

Avec le temps, j'ai compris que la principale évolution liée au soi-disant contrôle qualité, c'est que le papier a pris le pas sur l'action, sur le faire. Dans bon nombre d'administrations, on préfère avoir de beaux documents bien rédigés et volumineux, que personne ne lit, plutôt que de faire avancer des sujets.

Ça peut choquer de l'écrire comme ça mais c'est une forme de réalité. J'ai surtout compris ça quand j'ai pris conscience que les gens utilisent les documents pour se protéger de leurs erreurs ou des erreurs des autres. Arrive une situation qui pose problème et la réponse type consiste à se dédouanner en disant que ce n'était pas dans le manuel technique ou le dossier de cadrage ou la feuille d'émargement, etc.

La conséquence la plus directe c'est qu'à la fin, une organisation préférera toujours avoir de beaux documents bien remplis plutôt que des personnes efficaces et qui achèvent une masse de travail conséquente ou qui débloquent des situations complexes, là où on en a le plus besoin. J'y vois un très grand gachis de ressources et de talents. Le pire exemple est sans doute celui du chef de projet informatique qui rédige des documents de spécifications détaillées. En mode non agile, on demande à un ingénieur, un type qui a beaucoup de talents ou de compétences, qui a passées de nombreuses années à faire des études, de remplir un pappelard de plusieurs centaines de pages qui:

• ne sera pas lu dans la majorité des cas, en tout cas, pas dans sa totalité.
• documente des choses dont les clients ou les gens qui vont se servir plus tard du logiciel n'ont absolument pas conscience et sur lesquelles il faudra forcément revenir. Les phrases et les engagements écrits semblent alors complètement fantomatiques et inutiles.
• ne servira sans doute pas non plus en cas de litige ou d'erreur car on essaiera toujours de privilégier la négociation avec le client ou la réadaptation (privilégier l'évolution au bloquage).
• finira par servir uniquement en cas de poursuites juridiques, c'est-à-dire, dans une situation extrême.
• le contenu complet de ce document sera balayé en quelques instants au moment où le client final sortira la sacro-sainte expression: "Maintenant que je le vois, je crois que finalement ce que je voulais au départ ne répond pas à mon besoin !".

Je ne dis pas qu'un document de spécifications ne sert à rien, bien au contraire. Par exemple si je prend toutes les PEP Python, c'est de la spécification ultra-détaillée et qui sert vraiment à quelque-chose. Je l'utilise de manière très plaisante et c'est vraiment important d'avoir plein de détails et d'exemples sur les implémentations. Les RFC Internet font également partie de ce genre de spécifications dont personne ne peut se passer pour pouvoir se parler grâce à des standards.

En revanche, écrire des spécifications détaillées pour quelque-chose d'exploratoire comme un projet informatique où il y a des aléas, des risques, des choses non prévues, des choses qui vont forcément évoluer, et surtout une vraie absence de connaissance du champ des possibles par les clients/utilisateurs ainsi qu'une véritable dichotomie entre les besoins et l'imagination de leur réponse en outil, ce n'est pas du tout adapté et ça ne sert non seulement à rien mais en plus ça ralenti l'ensemble du processus de construction.

Ma conclusion, c'est qu'il faut toujours analyser si le niveau de bureaucratie est adapté ou pas à l'action. Et dans la majorité des situations professionnelles que j'ai vécues, c'est souvent peu le cas. On finit par faire des papiers pour faire des papiers, parce qu'on a l'impression qu'avec des documents, on est protégé. C'est certes le cas mais pendant ce temps, on n'a rien accompli ! Comme je me le dis souvent: un ingénieur, c'est payé pour trouver des solutions et les mettre en oeuvre, pas pour écrire des romans ou faire des rapports.

Un autre point de déception que j'ai rencontré vraiment très souvent, c'est la limite de ce que j'appelle la bonne volonté. Pour ma part, la bonne volonté appliquée à un système d'évolution c'est le phénomène qui consiste à piloter un changement avec les volontaires, ceux qui veulent s'en occuper, le tout, en plus de leur travail déjà existant. J'ai déjà expérimenté cette technique qui semble si simple et si évidente pour en conclure qu'elle a vraiment des problèmes majeurs, pire qu'elle est dangereuse.

Très souvent, je rencontre des collègues ou des collaborateurs qui essayent d'aller dans le bon sens. Ils sont plein d'énergie positive pour faire évoluer les choses dans l'intérêt commun ou l'intérêt de l'organisation. Ça fait toujours du bien de rencontrer ou de travailler avec ces personnes. Ils sont toujours enthousiastes, ne comptent pas leurs heures, savent avaler n'importe quelle couleuvre, se débattent avec une énergie folle pour porter un projet qu'ils incarnent véritablement.

A ce stade, leur travail n'est plus du tout alimentaire mais se transforme en mission véritable avec un niveau d'engagement proche de l'absolu. Des gens déterminés et qui ont une véritable envie d'améliorer les choses, les processus, ou de surpasser les limites qu'ils ont rencontrées. J'en rencontre souvent dans la fonction publique d'ailleurs. Ils sont souvent jeunes (c'est mon constat de quadragénaire) sans que ce soit la norme (j'ai aussi vu des jeunes gens qui ne veulent pas en foutre une de plus que le strict cadre de leur fiche de poste). Ils ont souvent vu des choses marcher ailleurs et essayent de mettre en place ce qu'ils ont vécu dans d'autres structures. Ils forment, à n'en pas douter, le véritable trésor d'une structure de travail. Si tout le monde avait ce niveau d'engagement, on pourrait vraiment déplacer des montagnes, et ce, de manière ultra-efficace.

Très souvent, il n'existe rien dans l'organisation pour gérer ces évolutions internes. Au mieux, on forme un groupe de travail, sans réel pouvoir (faut pas déconner) où des personnes qui n'ont rien demandé se retrouvent catapultées. Mais comme il existe un ou plusieurs leaders déterminés, ils font avec. Au final tout repose sur la bonne volonté des gens du groupe de travail ou de l'organisation informelle non hiérarchique qui a été mise en place.

Mon expérience de ces vingt dernières années m'a démontré par A+B que la bonne volonté a des limites énormes qui font que le changement aura de toute manière du mal à prendre forme. Car la bonne volonté est une ressource rare dans le monde du travail. Pas parce que les gens ne veulent pas et qu'il s'agit d'une ressource limitée en quantité mais bien parce que cette ressource reste fragile, surtout à l'épreuve du temps.

Faire reposer un changement ou un projet important sur de la bonne volonté c'est s'exposer à un échec à long terme. Pourquoi ?

• Dans une organisation informelle, les travailleurs se retrouvent tiraillés entre leur métier véritable (celui de la fiche de poste, sur lequel on leur demande des comptes et qui leur permet de justifier leur salaire) et celui du groupe de travail. Cela conduit à faire en sorte que, pour des raisons d'agenda, de charge de travail, le projet se retrouve toujours mis en défaut par manque de ressources humaines.
• Dans la suite du point précédent, la bonne volonté ne résiste pas longtemps aux grains de sable. Il suffit que le projet rencontre un écueil qui demande un effort supplémentaire pour que les gens se retournent assez facilement vers leur métier premier et fasse passer le projet au second plan. C'est la fuite face à une situation plus compliquée que prévue.
• Le groupe de travail est ensuite toujours malmené par la hiérarchie. Il s'expose aux décisions, parfois arbitraires des directeurs/chefs de service/unités qui peuvent, en 3 mots, tout arrêter ou faire en sorte de mettre suffisamment de bâtons dans les roues pour que le projet cesse ou soit carrément nié.
• Disons que la bonne volonté amène finalement à un niveau d'engagement moyen assez faible sur le long terme. Le porteur de projet s'y engage à fond (120%) mais, si on fait la liste complète, on finit par se retrouver avec des agents qui font le miminum syndical ou carrément rien du tout ou pire encore, qui milite contre le projet car ils se retrouvent en dehors de leur zone de confort ou qu'ils n'arrivent pas à jongler entre leur activité quotidienne, les ordres de leur hiérarchie et l'intérêt du projet. Dans ces conditions, c'est toujours le projet qui en pâti.
• Par ailleurs, si on arrive à recruter toutes les personnes motivées, il reste tous les autres, confortablement installées sur leur zone de confort, sur ce qu'ils savent faire de mieux et qui peuvent facilement couler le projet de l'extérieur car ils en sont exclus, non consultés et aussi parce que la critique par les mots ne coûte rien alors que la réponse à ces critiques demande une démonstration et, au final, beaucoup d'efforts. Le jeu est inégal.

Ma conclusion personnelle c'est que s'il n'y a pas de mandat clair pour le groupe, pas de possibilité de renverser l'organisation globale, pas de pouvoir hiérarchique et surtout pas une méthode claire et efficace, on n'arrive à rien.

Tant d'efforts, tant de travail, pour au final, revenir au point de départ ! Combien de fois je l'ai vécu au point d'en être dégouté. La bonne volonté est un ingrédient important pour réussir un projet ou un changement d'organisation mais ça ne peut pas être le seul.

Le silo. Vous connaissez ? Je suis sûr que je n'ai pas besoin de qualifier plus ce terme pour que ça vous parle. Moi aussi je l'ai vécu. J'ai même fini par croire qu'il était inévitable. Mais c'était faux.

Le silo caractérise l'effet de groupe qui affecte une équipe de personnes qui travaillent ensemble. Par effet de groupe j'entends que l'équipe se concentre sur elle-même, sur ses relations internes essentiellement, sur sa propre vie, sur ses processus en ignorant très fortement ce qui se passe à l'extérieur. C'est un phénomène que je qualifierais de "naturel": le cerveau humain ne peut pas gérer tous les éléments de contexte de l'environnement. Il concentre donc son attention sur ce qui est immédiat et à proximité, sur ce qui est facilement disponible. Dans un groupe, ça veut dire qu'il est facile de faire attention au groupe et à se qui s-y passe, moins aux autres groupes ou aux facteurs extérieurs.

Le problème que j'ai rencontré avec ce phénomène c'est que le groupe finit par se couper lui-même de ses origines, de pourquoi il a été constitué. Il continue à vivre en dehors de toute utilité, pire en faisant fi des éléments de valeur qu'il pouvait ajouter au départ.

L'autre sujet, c'est que sans concertation globable, sans synchronisation minimale, on finit toujours par se retrouver sur le constat que deux équipes différentes, situées parfois très loin dans l'organigramme font la même chose ! Tu pensais être la seule équipe qui codait dans toute ta structure pour te rendre compte que non, il en existe une autre, super loin de toi et qui a d'autres pratiques, d'autres méthodes et que l'organisation a finalement accouché de deux équipes de dev au lieu d'une seule prévue. Luxe absolu pour lequel on te dit tout le temps que tu coûtes déjà trop cher à toi tout seul. C'est le symptôme révélateur d'une vision totale de l'organisation en silo qui fait que, comme les équipes ne se parlent pas trop, elles s'ignorent. Ainsi, si une équipe a un besoin de devéloppement informatique, si tu bosses trop en silo, elle finira par former sa propre équipe de dev plutôt que de venir te voir. Ton équipe sera trop loin d'elle, elle aura été trop fermée, elle aura oubliée ce pour quoi elle avait été créée au départ. Elle se sera installée dans son silo, son bunker… si tu ne fais rien pour la sortir de là, elle pourrait bien finir par y mourir aussi.

Le pire étant ensuite, si les deux équipes qui font la même chose entrent en compétition. On a là le gachis de ressources le plus ultime: au lieu de collaborer ensemble et aller collectivement plus loin pour l'organisation, cette dernière te demande de jouer à Highlander: à la fin, il ne peut en rester qu'un ! Tout ça à cause d'un effet de groupe.

Ma conclusion c'est que le travail en équipe apporte un certain confort mais qu'il faut surtout savoir rester à l'écoute de tout le reste de la marche de l'organisation ou de la structure. Et ça, ça demande du temps, un processus, de la gestion. Trop souvent, ces trois derniers points n'existent pas. A partir de cet instant, l'équipe que tu animes est en danger !

Les gens parlent dans ton dos. Tu peux même être sûr qu'en ce moment ils sont en train de casser du sucre sur toi. Parfois c'est justifié (on n'est pas parfait), souvent, c'est pour un tas de raisons sociales puantes et malveillantes. Tu as aussi remarqué que quand tu laisses une rumeur enfler, ça finit souvent par se retourner contre toi ou contre ton équipe, alors que tu n'as rien demandé et que tu pensais bien faire ton travail.

Pire, tu as capté qu'il y avait des désaccords sur ce que tu faisais, parfois en interne dans ton équipe. Mais comme ils ne s'expriment pas ouvertement, tu fais comme s'ils n'existaient pas. Tu penses qu'en faisant, tu finiras par convaincre. C'est là que tu te trompes.

D'abord, il est tout à fait normal que des gens ne soient pas d'accord et, généralement, c'est plutôt sain. Car si on analyse assez froidement la réalité du désaccord, dans le milieu professionnel (sans doute moins au niveau politique) on capte les problèmes qui suivent:

• La mauvaise compréhension: quelqu'un n'a pas compris un terme ou ce terme est ambigu ou alors a une signification différente selon le contexte. Quand on reformule ou qu'on précise, souvent, les gens comprennent et le désaccord disparaît de lui-même.
• Le manque d'explications: souvent, le désaccord sur un point technique apparaît parce qu'on considère que l'idée initiale est une mauvaise pratique ou bien a déjà été testée comme non valide. Donc, on ne peut pas être d'accord, de prime abord avec cette idée. Toutefois, si la personne qui propose l'idée au départ expose une situation nouvelle, un nouveau cas, on peut expliquer la différence et l'opposition tombe d'elle même.
• La posture: les gens font du théatre en permanence. Ils ne sont pas d'accord au début, juste pour la posture. Si on les écoute, si on les laisse parler, si on les amène à sortir de la posture dans laquelle ils se sont eux-même fourvoyés, d'un seul coup tout est possible !
• Le faux désaccord: je ne compte plus les situations où les gens se crient dessus pour dire qu'ils ne sont pas d'accord alors qu'ils expriment la même idée, juste avec des termes différents. Quand ils trouvent un vocabulaire partagé, ils se rendent compte à quel point ils ne savaient pas s'écouter.
• L'oubli: le type qui émet l'idée initiale a simplement oublié une situation qui l'invalide. Autant lui dire plutôt que de le laisser se tromper non ? Après, en restant bienveillant et en expliquant factuellement l'origine du problème, ça passe.

En conclusion, quand elle est prise en compte, quand on laisse les gens s'exprimer dans un cadre non toxique, c'est-à-dire avec une méthode ou une technique qui permet de gérer les points sus-cités, quand on tente d'assainir le débat, l'opposition finit par se focaliser sur les vrais points de contradiction sur lesquels on doit travailler. Dans la pratique, avec une bonne technique, on a rarement des oppositions totales qui suscitent une descente dans la rue ou une grève (bien sûr, ça implique de rester bienveillants et de ne pas vouloir faire du tord aux gens, sinon, c'est normal qu'ils résistent).

Par expérience, j'ai aussi appris que, si elle est tue, masquée ou étouffée par la hiérarchie ou par un groupe de personnes, la controverse finit toujours par sortir et souvent, elle sort là où ça fait le plus mal, au plus mauvais moment.

Prenons un exemple type. Le patron/directeur de la société machin veut impulser une nouvelle direction/directive et annonce à ses employés qu'on va faire comme ça. S'il n'y a pas de place pour la controverse, pour le débat, pour la discussion, on assiste aux phénomènes suivants:

• Les gens n'adhèrent pas. Ils s'impliquent peu voire pas du tout. Rien que ça, ça peut plomber le projet.
• Pire, ils tentent de le boycotter, par les actes ou la "grève du zèle". Simplement pour dire qu'ils auraient aimé être consultés, avoir leur mot à dire, surtout parce que c'est eux qui font. Déjà, le projet semble mal barré.
• Si le projet part un peu de travers, on grossi le trait pour dire que ça ne marche pas du tout, parce qu'on n'est pas convaincu. Dans la pratique, le projet prend simplement un peu de retard mais les gens exagéreront en disant que c'est complètement foutu et qu'il n'y a plus rien à faire.
• Si jamais le projet part un peu plus de travers, immédiatement, il n'y aura qu'un seul responsable: le patron/directeur.
• A ce stade, si une autorité supérieure au patron/directeur (les actionnaires, les autorités administratives ou judiciaires, les clients) se pointe en constatant le manque de résultats, on dira que c'est parce que ça a été décidé comme ça, brutalement et qu'il faut faire payer le coupable (vous savez qui c'est ici).

Tout ça pour dire qu'il faut des lieux et des temps d'expressions dédiés au sein des équipes, que la prise de décision est finalement un processus partagé dès lors qu'on n'est pas tout seul à y aller. Si rien n'est fait de ce côté là, on aura sans cesse des forces qui s'opposent au lieu d'aller dans le même sens. Et que l'opposition, bien gérée avec méthode, c'est un atout pour éviter de faire des conneries et aller plus loin.

Bon, c'était long à écrire et sans doute loin d'être parfait dans le mode d'expression mais j'ai essayé de faire le point sur ce qui n'allait pas dans les organisations dans lesquelles j'ai essayé de travailler.

Pendant des années, j'ai toujours essayé de combattre ou corriger les problèmes sus-cités, parfois après avoir passé une énergie folle pour des résultats finalement assez minces ou peu durables.

Le seul truc qui a finalement, à mes yeux, à peu près fonctionné, c'est la méthode SCRUM, avec quelques adaptations sans doute. Elle a non seulement triomphée de pratiquement tous les problèmes sus-cités mais elle m'a permis de constater que les changements mis en oeuvre deviennent enfin à peu près durables, enfin marquants dans le temps.

Pour le prochain article, je vais essayer de vous montrer quels changements laisse apparaître SCRUM pour essayer de corriger les problèmes évoqués ici…