Cet article suit le même modèle que le précédent : "Accept we are part of the problem". Le principe : étudier des "capabilities" managériales pour découvrir la systémique.
"The ability to encourage new interaction patterns within an environment rather than solely attempting to change (or remove) individuals. Help individuals connect and become exposed to new information and experiences."
Interview Question:
Describe a situation where you facilitated new ways for people to interact or share information. Or a situation where you exposed people to new kinds of information or experiences. What prompted you to make the change, and what was the outcome?
Probablement l’un des plus complexes de la liste, pas nécessairement dans la pratique, mais dans la compréhension. D’un point de vue systémique, il s’agit de comprendre que l’organisation de composants peut drastiquement changer un système, et avant tout de façon imprévisible. Si vous connaissez Cynefin, le mot « complexe » pour décrire la dynamique de système qu’implique cette "capability" est plutôt bien choisie. Aucun regroupement d’expert ne peut vous dire quelle est la solution en observant le système. Mais il reste possible d’expérimenter et d’observer et d’en tirer des conclusions a posteriori. Pour comprendre cela, il faut également savoir que chaque composant du système peut agir de façon différente, et particulièrement dans un système humain, chaque personne peut tenir des rôles officiels et des rôles implicites, parfois même inconscients pour ces mêmes personnes.
Un des rôles connus au sein des systèmes est celui de régulateur. D’un point de vue téléologique, finalité, le régulateur contribue à rectifier quelque chose, à garantir une stabilité du système. La soupape d’une cocotte remplie cette finalité. Quand la pression devient trop élevée, elle évacue pour que la cocotte n’explose pas. Votre chef également à cette fonction, dans le but de réguler les comportements qui permettent au système, l’équipe, l’entreprise, de fonctionner dans les bonnes conditions. Cependant, ce qui n’apparaît probablement pas très clairement dans ces deux exemples, c’est que « pression trop élevée » comme « bonnes conditions » implique que cet élément régulateur « sait » quels sont les paramètres optimaux. Dans le cas de la soupape, c’est le designer qui a développé un modèle, basé sur les mathématiques et la physique selon des théories éprouvées, permettant de concevoir un régulateur qui réagira toujours de la même façon au même niveau de pression. Dans le cas du manager, son modèle mental est le fruit des interactions avec sa direction, son équipe, son contexte. Quand bien même on pourrait maximiser l’alignement des modèles mentaux de chaque manager, in fine, l’unicité de cette personne, de son expérience personnelle, font que son modèle mental est unique. Elle ne régule donc pas uniquement selon des règles explicites de son entreprise, mais aussi ses propres règles personnelles, conscientes ou pas, qui lui indiquent comment réagir. Et en l’exposant de cette façon, on peut bien imaginer qu’il n’est pas nécessaire d’être manager, rôle officiel de régulateur, pour l’être soi-même au sein d’une équipe. Chacun peut être régulateur selon les conditions, et… chacun a un modèle mental unique qui conditionne ses actions. Ce qui conditionnera l’activation ou l’inhibition des compétences et actions de ces personnes dépendra alors de ce à quoi elles sont confrontées. Des problèmes techniques qu’elles connaissent ou non, des personnalités compatibles ou non, « je suis d’accord / je ne suis pas d’accord », des processus et interactions avec lesquelles elles ont familières ou non, tout ça la fois et d’autres causes également. Connaître ces paramètres a priori est impossible. Même si d’une situation à une autre, des comportements, événements, organisations se ressemblent, il faut se prémunir d’une conclusion trop hâtive. Face à un système complexe, il faut agir pour comprendre comment le système réagit dans son ensemble.
Dans cet exemple, une équipe de développement réalise un produit avec difficulté. Elle a de nombreux bugs et incohérences d'une fonctionnalité à une autre, et quand on regarde le code, il est très hétérogène. Un peu comme si plusieurs équipes avec différents standards avaient fait des changements sans aller au bout de leurs idées, ou sans en avoir eu l'occasion ou les moyens. Les développeurs étaient vus comme des personnes peu capables par la hiérarchie : certains étaient des experts, mais bossaient dans leur coin, et d'autres étaient plutôt moyens ou aux compétences peu reconnues, et il était dit qu'il fallait nécessairement repasser derrière ces derniers. La stratégie de la hiérarchie était jusque-là de changer les consultants par d'autres à l'issue de leur contrat en espérant améliorer la situation. Cependant, même si quelques recrutements ont pu apporter des modifications intéressantes, la qualité générale, elle, n'évoluait pas, et les mêmes catégorisations de bons ou mauvais développeurs avaient lieu.
Après avoir échoué avec tous ces renouvellements, la solution de la hiérarchie a été d'ajouter une personne, dans le but qu'elle enseigne une fois pour toutes les bonnes pratiques à l'équipe. Cependant, cette fois-ci, cette personne a préféré observer le système avant de commencer à lui infliger ses connaissances.
Ce qui lui a sauté aux yeux était la façon dont les développeurs se répartissaient le travail : jamais une seule fois ils ne se retrouvaient sur le même ordinateur pour s'occuper d'une fonctionnalité. Pas de mob programming, ni de pair programming, et très peu de revue de code synchrone. Pas même lorsqu'il s'agissait d'une nouvelle fonctionnalité qui aurait bénéficié de plusieurs cerveaux pour en poser les fondements. En regardant les commits des différents développeurs, il a également observé qu'ils avaient chacun des standards différents au sein de l'équipe. De tout ce qui était présent, il n'y avait pas de standard meilleur qu'un autre, mais leur hétérogénéité rendait la lecture de la base de code difficile. Par exemple, la manière d'appeler un service dans une partie du code était souvent différente dans une autre partie. Et, systématiquement, l'intervention d'un développeur dans une partie du code dont il n'avait pas été à l'origine donnait un résultat mixte de standards. Ainsi, lors du parcours du code, on pouvait être surpris d'une solution différente pour les mêmes types de problèmes. De même, lorsqu'un travail de design avait lieu, seul un, ou bien la même poignée de développeurs, faisait le travail, et les autres continuaient leurs tickets. En observant la qualité de leurs interactions, on pouvait voir de nombreux conflits, le plus souvent résolus soit par l'idée d'une personne qui avait une autorité reconnue, par exemple, le tech lead, soit par la décision seule de la personne qui devait implémenter l'idée, et en ignorant le résultat du débat.
Plutôt que de définir « la » bonne pratique pour chaque problème de la base de code, il a alors exposé le constat à l'équipe. Celle-ci a bien répondu que cela lui semblait juste, mais elle ne voyait pas quoi en faire. Pour tenter de faire émerger des standards d'équipe dans un cadre propice à ce type de décisions, il les a invités à faire du mob programming, une session de développement où toute l'équipe développe sur le même ordinateur, en prenant comme sujet de nouveaux domaines de l'application. L'équipe a accepté de suivre la méthode. Au premier essai, la matinée a été épuisante pour tous. Les échanges très conflictuels étaient encore de mise durant la session, et quand bien même ils s'entendaient parfois sur des standards, tout était à discuter puisqu'aucun standard n'avait jamais été partagé jusque-là. Le conducteur du mob programming, la personne qui tenait l'unique clavier du groupe, n'hésitait pas à décider lui-même de ce qu'il allait écrire, faisant fi des avis des autres, et donc des règles de la session. Le nouvel arrivé, en posture de facilitateur, a tenu le cadre, parfois en les incitant à suivre les règles sans trop réfléchir, mais également en invitant chaque personne à rappeler à l'ordre ses coéquipiers, un type d'interaction qu'ils connaissaient déjà auparavant et ne se gênaient pas d'appliquer. Session après session, les membres devenaient autonomes sur la bonne exécution des règles du mob programming et, progressivement, les débats se sont trouvés confrontés à l'unique issue possible en suivant ces règles : des décisions partagées par l'équipe. C'est-à-dire que quel que soit le type de consensus, l'équipe était capable d'accepter le résultat d'un débat à partir du moment où tout le monde suivait le mode de décision. Par la répétition du geste durant chaque séance, l'équipe a fini par trouver sa fluidité dans ce mode d'interaction : le facilitateur n’intervenait plus. Dès la quatrième session, elle a même pu réaliser une journée entière de mob programming sans se fatiguer. Un des membres a même dit lors des sessions : « j'ai compris que ce n'était pas grave si ce n'était pas mon idée ». Par la suite, l'équipe réussissait même à réaliser des ateliers de design ensemble en parvenant à trouver des solutions avec beaucoup moins de frictions. Les conditions pour que des standards partagés émergent étaient désormais en place.
Si on réduit le système à son état initial, chaque membre est porteur d'idées, de gestes, qui lui sont propres et applique ce qu'il sait à la base de code. Lorsque deux membres ou plus doivent échanger sur la même portion de code, le conflit débute, car leurs idées et leurs gestes sont incompatibles. De même, quand une personne modifie une portion de code qu'elle n'a pas créé ni modifié auparavant, elle est confrontée aux altérations d'une autre personne – altérations qui ne lui conviennent pas, parce qu'incompatibles avec ses idées et ses gestes – et donc modifie la base de code selon ses propres standards. Chacun se comporte comme un régulateur des standards de la base de code, mais personne ne partage les mêmes règles, donc pas le même modèle mental. Chaque régulateur va réprimer les actions non voulues, mais dans ce cas précis les actions de chaque membre sont régulées par chaque membre. Le système s’étouffe alors dans l’indécision, il change continuellement sa direction sans pouvoir converger vers un état cible.
Durant les premières séances, les membres avaient tendance à reproduire le schéma qu'ils pratiquaient d'ordinaire : chacun applique immédiatement une décision lorsqu’il a analysé un écart. Sans étape intermédiaire, chaque membre juge et agit sans tenir compte des autres, ce qui les empêche collectivement d'avancer puisque la base de code, le résultat de la succession de décisions, est partagée entre tous.
Le facilitateur régule alors lui-même de plusieurs façons :
De nouveaux gestes et automatismes pour conduire un dialogue de groupe se mettent alors en place. Chaque voix doit avoir pu s'exprimer, ce qui permet de s'assurer que chaque personne est avec nous, mais également qu'on bénéficie du point de vue de chacun. Ainsi, chaque avis doit être étudié pour valider le modèle mental de chacun et trouver les points incompatibles. On exploite donc au maximum la variété des points de vue, ce qui augmente de fait la capacité totale de l’équipe à pouvoir répondre à des problèmes. Tout ce processus introduit alors une étape intermédiaire entre l’analyse d’un écart par l’un des membres et la décision qu’il prend : rechercher l’alignement avec les autres parties avant l’action.
Chaque membre du groupe reste alors régulateur, à la fois sur le comment discuter, et aussi sur le comment on a décidé de résoudre un type de problème. Mais il retarde l’action tant qu’il n’a pas trouvé de résolution aux écarts de règles avec les autres. Une fois ces automatismes ancrés, l'équipe a acquis la compétence de réconcilier le modèle du problème et de la solution entre ses membres. La solution coule alors de source, car le système converge vers un état compris et voulu par chacun.
Touché. Même si, on l’a vu, tester de nouveaux modes d’interactions n’était pas dans les intentions du management. J’ai présenté cet exemple parce qu’il illustre pour moi au mieux les effets de nouveaux modes d’interactions, et qu’il ne dépend pas nécessairement d’un changement de la composition d’équipe. Mais ici, il aura fallu un nouvel arrivé. Cependant, si personne au sein de l’équipe n’avait le recul, le modèle mental, la sensibilité pour guider le système dans la bonne direction, où pouvait se trouver la réponse ? Eh bien c'est très certainement pour ça qu'ont été conçues les questions qui suivent.
Il serait malhonnête de dire que la nouvelle personne avait analysé la situation avec autant de détails sur le moment et en calquant des concepts systémiques pour analyser le système. Cependant, ces concepts lui étant connus, elle a inévitablement été influencée dans sa manière d'analyser les évènements, d’analyser les membres et leurs interactions. Et à mesure que la situation avançait, le système et ses interactions sont devenus plus évidents. La question « what prompted you to make the change » suppose alors d’avoir une analyse au moins partielle de la situation avant de déclencher de nouveaux modes d’interaction. On construit un modèle mental à partir de ce qu’on observe, même s’il est faux ou incomplet. Mais elle est également suivie par « what was the outcome » qui suppose que l’effet peut avoir été inattendu. Comme l'illustre bien la modification progressive des interactions de l'équipe à travers la pratique du mob programming, les effets sont difficiles à déterminer à l'avance. Ils sont complexes et résultants de plusieurs cycles d'interactions et de correction entre chaque membre. De nombreux évènements auraient pu donner un résultat décevant :
Encourager de nouveaux types d’interactions implique d'agir sur un système complexe, avec donc pour conséquence des résultats peu prédictibles. Cette capability implique d’agir par petites itérations et d’observer les effets pour réajuster. A contrario donc : méfiez-vous des managers trop prompts à appliquer de nouveaux modes d’interactions telles des recettes toutes faites, spécialement lorsque l'ensemble des changements à appliquer est trop conséquent. Et pour donner un exemple qui devrait vous parler : "on va utiliser le modèle de squads Spotify".
