Résoudre la dissonance DevOps. Désapprendre… pour réapprendre.

Par Benjamin Lallement, conseiller DevOps

« What my experience taught me that was so powerful was that the way to change culture is not to first change how people think, but instead to start by changing how people behave… what they do. » (Shook, 2010)

Notre précédent article a largement souligné l’importance de la transmission de la connaissance dans une équipe multidisciplinaire. Nous avons aussi décrit l’importance de la culture organisationnelle sur le comportement de ses membres et, conséquemment, sur l’efficacité d’ensemble de l’équipe.

On dit souvent, et avec raison qu’il est difficile sinon impossible de changer directement une culture. La composition de ses valeurs et l’imposition de ses comportements constituent le fondement de l’environnement social et psychologique d’une organisation. Toute pression directe forçant un changement rencontrera un mur de résistance.

Cependant, il a été démontré qu’un changement progressif des comportements amènera une évolution de la culture courante. L’apprentissage continu permet l’insertion progressive d’approches comportementales favorisant l’ouverture, la transparence et l’entraide. Elle accroît la collaboration et entraîne une amélioration significative de l’environnement de travail. Éventuellement, ces comportements deviendront culture.

We are often asked by enterprise leaders: How do we change our Culture?

We believe the better questions to ask are

How do we learn how to learn?

How do I learn?

How can I make it safe for others to learn?

How can I learn from and with them?

How do we, together, establish new behaviours and new ways of thinking that build new habits that cultivate our new culture?

And where do we start?

Forsgren, Humble and Kim (2018)

Tout cela est bien beau, mais comment introduit-on de nouvelles approches comportementales dans une équipe formée d’un groupe de développeurs, d’opérateurs et de spécialistes d’assurance qualité (QA).

Ce n’est pas un bigbang

Beaucoup pensent que le DevOps est un ensemble d’outils, de technologies, et que le simple fait de les déployer sera une motivation suffisante pour qu’une équipe nouvellement formée et composée de Devs d’Ops et de QA deviennent DevOps. Erreur !

Parlons maintenant des vraies affaires :

Pour « faire » du DevOps, il faut comprendre le métier, maîtriser l’étendue de connaissances techniques et connaître les préoccupations et responsabilités de chaque rôle clé dans le processus de livraison. Ce processus est complexe et inclut les acteurs de Dev, Ops, QA et Sécurité (Sec) et ce, pour toutes ses phases soit, l’évaluation, la programmation, le contrôle de qualité, la validation et l’exploitation.

À maturité, chaque acteur doit adapter ses méthodes de travail et se brancher sur un réseau d’APIs humaines d’échange d’information pertinente à chaque rôle. Tous les acteurs doivent être en mesure de détecter et transmettre les impacts potentiels de leur travail sur celui de leurs collègues, et ce pour chaque phase du processus. Bref, se demander « en quoi son travail impacte celui des autres » fait partie du travail de chacun.

Pour les esprits mathématiques, voici une formule (tentative) calculant la somme des notions requises :

DevOps = (Dev * Ops * QA * Sec) * (évaluation * programmation * contrôle qualité * validation * exploitation)

Pas banal comme bagage intellectuel et connaissance tribale.

En plus d’être une discipline nécessitant un haut degré de connaissances techniques, le DevOps est une composition de Culture, d’Automatisation, de Processus, de Mesures et de Partage. Le DevOps force la collaboration interdisciplinaire en élargissant les responsabilités de l’équipe aux Ops, à l’assurance qualité (QA) et la sécurité. Cet élargissement génère une expansion des connaissances de chacun qui, par osmose graduelle, passent d’une spécialisation de Dev ou Ops ou Qa ou Sec (DOQS) à une reconnaissance des compétences et une certaine connaissance des autres spécialités.

Apprendre à changer

La neuroplasticité est le phénomène qui permet au cerveau de se transformer en fonction de ce que l’on apprend. La structure, les fonctions et les connexions du cerveau se reforment en fonction de votre apprentissage. Apprendre un second langage ou un instrument de musique provoque le même effet d’expansion cérébrale. Les débuts sont difficiles, car l’information doit être traitée à chaque répétition. Cependant, par un entraînement constant, elles sont imprégnées dans notre mémoire à long terme et deviennent automatismes. Une fois cet état atteint, l’apprentissage du domaine devient de moins en moins ardu, car ces connexions de bases sont durables.

Cependant, l’évolution de ces nouvelles connaissances en connections, structures et fonctions cérébrales durables nécessite du temps, des ressources et draine beaucoup d’énergie chez les membres. Ce n’est pas parce qu’on forme une équipe sur papier que ses membres sauront adapter leur comportement au DOQS dès le départ. En fait, dans le domaine des technologies (ingénierie, informatique, recherche, etc.), l’élévation d’une équipe ou d’un nouveau membre à un niveau d’intégration supérieur peut s’échelonner sur 2-3 ans.

Cette période peut être diminuée significativement dans la mesure où la disponibilité des ressources d’enseignement et l’environnement psychologique favorisent largement l’apprentissage dans un cadre proposant un objectif commun et favorisant la collaboration.

Cependant, il est important ici de faire la distinction entre la « formation de base » (training), la « formation approfondie » (learning ou apprentissage) et le « mentorat actif. »

Formation de base : vise à transmettre de l’information sans nécessairement permettre aux auditeurs d’approfondir leur compréhension de la motivation, de l’applicabilité et du contexte général de l’information.

Formation approfondie : en plus de l’information de la formation de base, apporte à l’auditeur des connaissances et une compréhension des motivations et mécanismes sous-jacents à l’évaluation et aux actions. Ce type de formation est généralement dispensé de façon classique soit professeur/conférencier, groupe d’auditeurs et période fixe.

Mentorat actif : insertion d’un mentor dans le milieu de travail permettant aux auditeurs d’acquérir non seulement les connaissances, mais aussi les comportements pertinents à la culture cible.

L’incubateur de Gologic

Gologic propose son incubateur chez les clients pour réaliser des projets en « pair-programming » avec objectif de travailler en mode collaboratif de proximité, proposer des innovations sur les façons de faire et amener la culture à se propager à travers les équipes. Réalisé en mode mentorat-actif, Gologic injecte un ou plusieurs mentor(s) dans vos équipes. Cet incubateur est équivalent à un émetteur de comportements DOQS qui influe sur les neurones miroir des auditeurs, et conséquemment, agit comme un catalyseur d’apprentissage.

En apprendre davantage sur l’incubateur Gologic.

L’élévation de vos équipes DevOps à un niveau supérieur vous permettra d’éviter des situations comme :

Restez à l’affût, nous sommes en écriture de notre prochain article qui traitera de la direction, au cœur de la gestion du changement vers une culture DevOps.

À bientôt donc.

Benjamin Lallement, conseiller DevOps et associé Gologic.

Avec la collaboration de Jacques Ledoux, jcq@ledx.com

Recherche