Par Benjamin Lallement, conseiller DevOps
Question de culture…
Dans le premier article de cette série, nous avons décrit la dissonance DevOps comme étant un défi important dans la fusion de deux groupes de professionnels des technologies de l’information ayant des intérêts opposés. Nous avons aussi avancé que la meilleure approche pour le résoudre et ramener l’harmonie ne peut être basée que sur des relations étroites entre les acteurs des deux groupes.
Nos fidèles lecteurs, impatients de connaître la suite des aventures DevOps de BeetHalen devront attendre un peu, car ce matin, Ludwig a été retardé par un imprévu.
En se rendant au travail, Ludwig entend un bruit bizarre qui semble provenir du dessous de son carrosse. Inquiet, il décide d’arrêter chez Jean-Seb son maréchal ferrant local. À son arrivée, on soulève le carrosse et rapidement, Woolfie, un jeune apprenti que Ludwig n’a jamais vu, commence à l’examiner pour déterminer la provenance du bruit suspect. Il découvre rapidement que le bruit vient du sproutz de transfert de puissance.
Woolfie est un élève de Jean-Seb. Il a peu d’expérience avec les sproutz, particulièrement pour la marque de carrosse de Ludwig. Il décide donc de consulter le manuel d’entretien et demande à Jean-Seb où il se trouve. Jean-Seb lui répond : « Notre manuel sur les sproutz, c’est Frédéric, il connaît la musique à propos des sproutz de toutes les marques. Ahh!! Le voici qui arrive. »
Jean-Seb présente Woolfie à Frédéric et lui demande de l’aider pour le sproutz de Ludwig, un bon client. Woolfie explique la source et le type de bruit à Fred qui sourit, et lui dit de le suivre. Fred écoute le son bizarre et explique à Woolfie : « Ce bruit est causé par la patente croche qui se situe généralement hors de portée du sproutz dont le lien doit être lousse. Ça cause une vibration du sproutz qui cogne sur la patente et cause ce bruit. Tu n’as qu’à resserrer l’écrou du sproutz et ça devrait ramener le silence en deux temps trois mouvements. »
Woolfie remercie Fred qui s’informe sur son expérience. Il répond qu’il a souvent travaillé sur toutes les gammes des trooms. Fred est bien content de l’apprendre, car ces composantes sont complexes et lui donnent souvent du fil à retordre. Bref, Woolfie a appris des choses sur les sproutz et Fred sait qu’il peut maintenant demander à Woolfie de l’aider sur les trooms.
En quelques minutes, Woolfie, Jean-Seb et Frédéric ont appris beaucoup sur les compétences de leurs collègues et, conséquemment, l’équipe a amélioré sa capacité et sa qualité de service, ce qui incite Ludwig à crier sa joie.
Le moins qu’on puisse dire, en lisant cette histoire, c’est qu’à la boutique de Jean-Seb, il n’y a pas beaucoup de cérémonie pour faire circuler l’information. Pas de meetings avec des diagrammes de Pablo, pas de dissertation sans fin de Victor bref, juste une conversation et une démonstration éclair pour transmettre la connaissance.
Bien sûr, chaque participant doit avoir une base commune, ici, la mécanique carrossière. Mais on peut aussi observer le même phénomène chez d’autres professions. Au hasard, prenons, les musiciens qui, lors d’une rencontre impromptue, échangent rapidement leurs approches musicales respectives et trouvent rapidement un “groove” commun qui “jive” pour tous, tout en laissant place à la créativité de chacun. Un seul “jam session” et les musiciens savent à quoi s’attendre l’un de l’autre.
Et la culture dans tout cela ???
Cette histoire n’est pas destinée à vous convaincre de faire du DevOps dans un carrosse chez un maréchal ferrant, mais simplement à illustrer, par une anecdote que pratiquement tous nos lecteurs contemporains ont vécue sans nécessairement s’en rendre compte : un flux d’information fluide dans une équipe multidisciplinaire résulte invariablement en une efficience accrue. Et pour que le flux d’information soit fluide, il faut d’abord que tous les membres de l’équipe connaissent parfaitement les forces de chacun de leurs collègues.
Cependant, cette ouverture sur les connaissances de “l’autre” est impossible si “l’autre” ne veut pas ou hésite à partager les siennes. En surface, on peut expliquer une telle attitude par la personnalité ou la spécialisation d’un collègue, mais, trop souvent, c’est l’odeur irritante de symptômes d’un problème plus profond : la fameuse “Culture organisationnelle” (CO).
Cette CO est souvent perçue comme une boîte de Pandore que l’on évite d’ouvrir à tout prix. Il n’est cependant pas question ici d’aborder la culture globale d’une entreprise, mais seulement la culture au niveau des équipes DevOps.
Ouf… je suis persuadé que certains lecteurs ont retenu leur respiration. Alors, maintenant qu’on a repris notre souffle, jetons les bases d’une compréhension commune sur ce sujet sensible.
Modèles de culture ou… culture modèle ??
Pour être en mesure de discuter sereinement d’un sujet, il importe de comprendre son vocabulaire et connaître ses principales références. Plusieurs modèles cherchant à cerner la nature exacte d’une culture organisationnelle ont été développés au fil des ans. Les spécialistes ont déjà amassé et classé des quantités de données, établi des relations et catégorisé les résultats de leurs observations. Commençons donc par identifier les bases de classification de COs. En 1985, Schein identifie 3 bases de culture organisationnelle servant à classifier les différentes variations et souvent utilisées dans les études de cas similaires à DevOps.
Pour bien illustrer nos propos, nous ramènerons sur le tapis notre API Humain ou APIH, afin de produire des exemples faciles à reconnaître. Voici donc les principales classes de cultures organisationnelles.
Les hypothèses simples : cultures basées sur les méthodes et comportements inférés par les membres de l’organisation au fur et à mesure qu’ils prennent conscience des relations, événements et actions qui les entourent. C’est un peu comme ajouter un poisson dans un aquarium. Par observation et sans aucune intervention extérieure, il prendra sa place dans le groupe et s’adaptera aux heures de repas et délimitations territoriales. Bref, il finira par faire comme les autres.
Spécifications de l’APIH :
- Requête : « Peux-tu m’expliquer pourquoi les ixes sont classés avec les igrecs?
- Réponse : « J’sais pas… mais on les a toujours classés de même. »
- Traitement de la réponse : « Ah bon… OK!! »
Les artéfacts : cultures basées sur la documentation de la mission, les convictions, technologies, procédures, etc. Les méthodes et comportements “by the book”. C’est un peu comme dans une horde de politiciens municipaux dont le chef ne souhaite pas avoir de “prix Nobel” dans son équipe. Ainsi, les membres de l’organisation suivent les directives à la lettre ou sont grondés par le “boss”.
Spécifications de l’APIH :
- Alerte : « Qui a classé ce ixe avec les doublevés? »
- Réponse : « C’est moi… ça a permis d’accélérer le dossier urgent de Madame Untel pour son traitement médical… Erreur!!! »
- Message d’erreur : « Je t’entends mais… (traduction libre de “Ta gueule!!!”) TU FAIS COMME ON TE DIT sinon TU DÉGAGES!! Remets ce ixe avec les igrecs et on se fout de Madame Choze. »
- Traitement de la réponse au choix de : « OK, OK j’ai compris » , ou alors « Bon bin… tu peux te la foutre où je pense ta job de me…!! »
Les valeurs communes : cultures basées sur les méthodes et comportement compris et acceptés, ouvertement discutés par les membres et ouverts aux améliorations. C’est comme deux mécaniciens dans une station-service, très qualifiés en mécanique générale, l’un ayant une super compétence en intelligence des ordinateurs de bord.
Spécifications de l’APIH :
- Requête : « Aye Gérard… peux-tu m’expliquer c’te rapport de scanneur là?? »
- Réponse : « Bien sûr. Ce modèle d’automobile est équipé d’un détecteur d’abc qui attirent les bcd. Le rapport indique que les narines du détecteur sont bloquées. »
- Relance de Roger : « OK mais le système détecte quand même la présence de bcd… c’est inscrit plus bas. »
- Réponse à la relance : « Ah oui!! Mais cela provient de l’inférence d’un autre détecteur qui déduit la présence d’un bcd par le mouvement du xy. La détection des abc sert à activer le détecteur de bcd à l’avance mais un mouvement de xy émet immédiatement une alerte de bcd. Tu peux configurer le lecteur de l’ordinateur de bord avec l’option “super xy” activée et tu auras toutes les réponses pour les modèles de ce genre. »
- Traitement des réponses : « OK donc, pour ce modèle, il y a deux détecteurs pour les bcd. J’me d’mandais à quoi servait l’autre option du lecteur. OK je comprends. Merci!! »
Pour conclure
Il faut retenir que nous n’avons présenté que des classes de culture et non des cultures en soi. Il serait possible de fournir des exemples très différents pour chacune de ces classes, car plusieurs variances de comportement peuvent s’appuyer sur la même base de classement.
Par exemple, une culture basée sur les hypothèses simples est nécessaire lorsque toute déviation aux méthodes imposées peut avoir des conséquences néfastes et irréversibles : la construction aéronautique et l’élaboration d’équipement de santé sont des exemples éloquents. Par contre, dans une culture de valeurs communes, celles-ci peuvent être basées sur la critique outrancière et la mauvaise foi, communément appelées chialage, bitchage, taponnage, niaisage et autres …ages de notre époque.
Nous encourageons nos lecteurs à laisser un bref commentaire identifiant la classe de culture de leur organisation rapprochée (groupe de travail) ou plus large (direction, entreprise), Dans le prochain article, nous décrirons la culture qui a généré les meilleurs résultats mesurables en matière de DevOps.
À bientôt donc.
Benjamin Lallement, conseiller DevOps et associé Gologic
La culture organisationnelle? C’est ce que les gens font lorsqu’on ne les surveille pas.
Auteur inconnu…
Références
Avec la collaboration de Jacques Ledoux, jcq@ledx.com
