Un brin de coaching peut faciliter la mise en oeuvre de DevOps. Cette vidéo introduit le rôle du coach DevOps.
Donner des perspectives à votre équipe
Renforcer la cohésion et nourrir la dynamique de l’équipe
Suivez nous sur YouTube pour ne rien rater
Au cours de ma carrière de consultant puis plus récemment de coach DevOps, j’ai souvent constaté l’incompréhension qui règne entre les différentes parties prenantes de la fourniture d’un service informatique.
Les intérêts et les objectifs des uns vont parfois à l’encontre de ceux des autres. L’antagonisme souvent mis en avant entre Dev et Ops est, à ce titre, emblématique.
Entre des Dev qui veulent aller plus vite jusqu’à la mise en production qu’ils estiment parfois qu’ils sont en mesure de maîtriser et des Ops soucieux de la prise en compte anticipée des exigences techniques et des normes et standards de la production.
Ceci ne doit pas nous faire oublier qu’il y a, au cœur de toute initiative DevOps qui se respecte, un travail sur la culture, l’organisation Agile et l’outillage et qu’une grande partie des objectifs du DevOps est source de motivation pour l’ensemble de ses parties prenantes.
Cet article propose une analyse des profils types des principaux acteurs impliqués dans le DevOps sous forme de personas. Nous proposerons, ensuite quelques moyens de concilier les motivations des uns et des autres pour donner toutes les chances de succès à la mise en place progressive de nouveaux modes de fonctionnement.
Dans cette partie, je propose une descriptions des acteurs du DevOps avec l’aide des « personnas » qui permettent de présenter chaque profil comme s’il s’agissait d’une personne dont on décrit les principales caractéristiques.
Commençons par l’ingénieur de développement. Dans de nombreuses structures, il intervient au sein d’une équipe agile de 4 à 8 personnes. La mise en œuvre des principes Agile et leur appropriation par les équipes est une des conditions nécessaires au DevOps.
Je vous présente Franck, il est sysadmin, ingénieur de production, on l’appelle plus simplement l’Ops. Il est notamment le garant des règles de la production, du respect des normes et standards techniques et de la traçabilité de ce qui est fait en production.
Amélie est middle Manager dans L’IT. Depuis l’avènement des équipes agile, son rôle change. Elle a parfois du mal à trouver sa place dans ce nouvel écosystème.
Paul est directeur informatique. Qu’il soit CIO, CTO ou CDO, il doit composer avec un SI historique qui ne peut évoluer qu’à grand renfort d’investissements importants et l’avénement (et l’urgence) du digital. Il sent bien que ces histoires d’Agilité et de DevOps ont quelque chose de bon mais il a souvent du mal à le quantifier.
Représentante ultime des utilisateurs et de la raison d’être de l’entreprise, Françoise est à la tête d’une direction métier. Elle ne cherche pas particulièrement à comprendre l’IT mais voit d’un assez bon œil l’implication directe de ses équipes dans les projets informatiques.
Alors que faire avec tout cela ?
Cela peut ressembler de prime abord à un champs de contraintes…
Mais à y regarder de plus près et en allant au-delà de la mise en place d’un pipeline de distribution (qui est bien souvent la partie immergée de l’iceberg DevOps), il y a pas mal de choses à faire pour alimenter la motivation des parties prenantes et avancer résolument sur le chemin :
Allons voir chacun de ces points d’un peu plus près…
De quoi s’agit-il ?
De faire en sorte qu’un Ops puisse prendre part à tout ou partie des rituels de l’équipe intégrée
Pour quoi faire ?
Gains pour l’ensemble des parties prenantes :
Accorder à l’Ops sa juste place au sein de l’équipe intégrée est, à mon sens, un des fondements de la démarche DevOps.
De quoi s’agit-il ?
De standardiser et de normaliser les environnements techniques mis à disposition pour héberger les applications informatiques
Pour quoi faire ?
Gains pour l’ensemble des parties prenantes :
DevOps et automatisation riment nécessairement avec standards connus et appliqués.
De quoi s’agit-il ?
De mettre à disposition de façon rapide et fiable les environnements standards
Pour quoi faire ?
Gains pour l’ensemble des parties prenantes :
Pas de DevOps sans provisioning d’environnements automatisé donc pas de DevOps sans Cloud.
De quoi s’agit-il ?
De disposer de métriques qui permettent de mesurer le succès de l’initiative DevOps
Pour quoi faire ?
Gains pour l’ensemble des parties prenantes :
Les équipes n’agissent pas uniquement dans le sens de ce qui les motivent mais aussi par rapport à ce qui est évalué/mesuré.
De quoi s’agit-il ?
De permettre de structurer la connaissance collective et de faire en sorte qu’elle se diffuse
Pour quoi faire ?
Gains pour l’ensemble des parties prenantes :
Le DevOps implique de nombreux corps de métier. Il serait illusoire de penser tous les maîtriser au sein d’une entité centralisée.
Une initiative DevOps qui atteint ses objectifs commence le plus souvent par du « bien travailler ensemble ».
Intégrer les Ops au sein de l’équipe agile est, de ce fait, LA priorité qui va permettre une bonne acculturation Agile/DevOps et de favoriser la compréhension mutuelle des cultures, enjeux et objectifs. Ce faisant, les équipes apprennent à travailler efficacement ensemble et l’osmose entre le fonctionnel et le technique peut se faire. Disponibles en production plus tôt et avec une meilleure qualité, les développements sont également plus pertinents par rapport au socle technique de l’entreprise et l’émergence de nouveaux besoins permet de moderniser et de standardiser le SI.
Découvrez aussi notre vidéo sur le rôle du coach DevOps
Depuis plusieurs années que j’accompagne les plus grands comptes dans leur démarche DevOps en compagnie de mon collègue Sylvain Gautier, je me rends compte que la plupart de nos clients sont déjà bien engagés dans la mise en œuvre des solutions techniques leur permettant d’outiller leur pipeline. Les standards de fait ont émergé et nos clients semblent s’y retrouver dans l’offre proposée (finalité et couverture fonctionnelle).
Il est cependant un domaine qui semble aujourd’hui plus ardu à aborder car il remet en cause les modes de fonctionnement (silos, mode ticket, faible collaboration).
Vous qui avez entamé (ou qui êtes sur le point d’entamer) une démarche DevOps, ce court article vous invite à vous focaliser sur 5 objectifs pragmatiques pour transformer de façon durable la culture de la collaboration au sein de votre organisation informatique et avec le métier.
Moyens d’y parvenir : sensibiliser les décideurs aux tenants et aboutissants de la démarche DevOps et recueillir leurs enjeux et contraintes.
Moyens d’y parvenir : Partager avec les équipes ce que sont les grandes lignes du DevOps (principes et bonnes pratiques notamment) sur un plan organisationnel et fonctionnel.
Moyens d’y parvenir : exprimer les objectifs de la mise en place du DevOps, identifier les priorités pour y parvenir de façon pragmatique et établir la roadmap.
Moyens d’y parvenir : proposer des ateliers pour renforcer la cohésion, co-construire l’organisation cible et bâtir des plans de progrès pragmatiques.
Moyens d’y parvenir : Former des coachs internes DevOps pour donner la capacité à la nouvelle organisation d’accompagner par elle-même équipes et individus.
Qui sommes-nous ? : nous sommes 2 coachs très expérimentés qui accompagnons depuis plusieurs années les plus grands groupes à faire progresser leur démarche DevOps et à en tirer le maximum de bénéfices :
Coach d’équipe et ancien dirigeant d’une practice Conseil en DevOps et management de l’IT, Loïc anime des ateliers d’intelligence collective visant à rendre les équipes plus autonomes.
Passionné par la réussite collective des projets, Sylvain est un coach agile et DevOps qui accompagne les projets DevOps de toutes tailles.
Le mouvement DevOps réconcilie des logiques jusqu’à récemment difficilement conciliables pour apporter agilité, réactivité et alignement métier aux services et produits informatiques.
En tant qu’ancien consultant en management de l’IT, j’ai eu la chance d’évoluer dans un milieu qui m’a permis de voir émerger cette tendance qui s’est largement imposée aujourd’hui
J’ai choisi de travailler sur les organisations DevOps en tant que coach d’équipe parce qu’on y met en place des modes de collaboration et d’organisation dont j’ai la conviction qu’ils sont pertinents dans le contexte qui est le notre. En particulier, ils répondent à une recherche d’innovation, d’efficacité mais aussi de qualité de vie au travail dont notre société a besoin de la part des acteurs économiques.
DevOps induit des modes d’organisation autonomes, itératifs et collaboratifs. En cela il permet, à mon sens, de :
A travers les nouvelles pratiques organisationnelles et opérationnelles qu’il introduit, DevOps reprend à son compte des démarches qui mettent le client au cœur de la conception et de l’évolution des produits et services.
Cette orientation client assure une meilleure utilisation et un meilleur usage de ce qui est produit (plus pertinent, plus fréquent et surtout plus utile). Il est évident que cela contribue au sens et à la fierté de ceux qui conçoivent (avec le client), construisent, prototypent (avec le client) livrent, font évoluer (avec le client) et supportent les produits et services.
Les acteurs impliqués dans le cycle de vie d’un produit ont le sentiment justifié d’apporter de la valeur ajoutée économique, pratique et même en terme de bien-être puisque ce qui est pris en compte dans le besoin du client ne se limite pas à la seule composante économique mais inclus des aspects pratiques, d’affectif ou de ressenti.
Une telle démarche contribue à donner du sens à l’action de l’équipe et à l’inscrire dans la raison d’être de l’entreprise.
Ce point est manifestement un des piliers de l’efficacité et de la motivation d’une équipe. L’équipe DevOps est une équipe autonome, cela signifie non seulement qu’elle dispose d’un nombre important et varié de savoir-faire et d’expériences en son sein (métier, développement, opérations, contact client) mais également qu’elle bénéficie d’un bon niveau d’indépendance pour réaliser des choix sur ce qu’elle doit faire et comment elle doit s’y prendre.
L’équipe autonome pluridisciplinaire permet d’estomper les frontières entre différentes fonctions jusque là rattachées hiérarchiquement à des branches différentes de l’entreprise et dont les objectifs étaient difficilement conciliables (phénomène de silos).
En travaillant ensemble dans la même équipe, des personnes de culture différentes en viennent à mieux se comprendre, à appréhender la diversité des enjeux et contraintes qui évoluent pour constituer ceux de l’équipe dans son ensemble.
Ainsi ce sont de véritables objectifs d’équipe, compris et partagés par tous qui émergent et qui permettent à tout ses membres de tirer dans le même sens plutôt que de devoir composer avec des objectifs individuels trop souvent contradictoires ou obscurs.
L’émulation qui en découle provient de ce sentiment de corps avec une finalité claire et affichée qui sert tout à la fois les intérêts des clients et la vision de l’entreprise.
Dans une pratique DevOps, les rituels de l’équipe sont pragmatiques et visent à partager, élaborer mais également renforcer le lien et la cohésion. L’idée est de travailler ensemble quotidiennement en privilégiant le face à face sur tout autre forme de communication.
De tels espaces permettent de pratiquer l’ouverture et la sincérité et trouver ainsi du soutien et des solutions auprès de ses collègues en n’hésitant pas à parler de ses vulnérabilités, failles ou autres erreurs. Le groupe bienveillant est un bon endroit pour trouver collectivement des solutions, faire jouer la synergie et la complémentarité.
Les rituels réguliers sont l’occasion de prendre du recul pour s’améliorer et être encore plus efficace : exposer une situation, enrichir les solutions entrevues par l’intelligence collective et modéliser des bonnes pratiques qui pourront être utiles à tous.
Partager efficacement cela veut également dire que l’on met à contribution le maximum de facultés sensorielles pour ce faire. Ainsi l’utilisation de tableaux visuels (dont beaucoup peuvent être issus de pratiques Lean) peut être, par exemple, complétée de post’its que l’on manipule, de vidéos ou de fichiers audio qui permettent à tous d’appréhender les éléments à partager selon sa propre sensibilité (visuel, kinesthésique ou auditif).
Les rituels réguliers en face à face sont des espaces d’échange primordiaux parce qu’ils mobilisent l’ensemble des sens et qu’elle permet l’expression de chacun dans la plus grande ouverture possible. C’est en particulier grâce à ces rituels ouverts que les individus et leurs interactions priment sur les processus (établis de façon plus ou moins rigide).
Le premier des principes qui me vient quand je pense à DevOps serait également bénéfique pour toutes les équipes (professionnelle ou non). Il est souvent exprimé selon l’expression « No Blame » que l’on peut traduire par « pas de reproche » et qui peut s’élargir à « pas de jugement » ou encore « pas de médisance ».
C’est, à mon sens, un principe extrêmement puissant et simple à la fois pour établir un climat de confiance et de collaboration au sein d’une équipe. Je l’associe au « parole impeccable » des 4 accords Toltèques de Miguel Ruiz. Il s’applique à autrui comme à moi-même et évite de se complaire dans l’espace problème dans le reproche ou la rumination. La parole dirige notre pensée et notre action. Une parole positive et bienveillante engendre des actions positives alors qu’une parole négative nous enferme dans la spirale infernale du pessimisme et de la recherche des coupables.
Le second point est le rapport à l’échec. Dans la culture DevOps, il faut essayer rapidement pour échouer vite et savoir ce qui fonctionne. C’est une culture de l’initiative, de la tentative, de l’itératif : j’essaie et si ça ne fonctionne pas : « No Blame » certes…
…mais je réessaie différemment après avoir tiré les leçons du premier essai. C’est certainement un challenge pour la fierté des coqs latins que nous sommes en France mais c’est une attitude salutaire pour innover et arriver à un résultat satisfaisant.
Le troisième principe est que pour aller loin, il faut commencer par faire quelque chose. C’est le Plus Petit Progrès Partagé Possible (PPPPP) dont parle le Kaizen et c’est le travail par incrément cher aux pratiques agiles.
Par quoi commencer ? Le principe c’est qu’il faut savoir selon quel critère je vais prioriser les activités : apport métier, risque, coût, temps passé. Une fois que les critères sont clairs, je vais pouvoir maximiser la valeur apportée par mes taches au regard de ces critères. Je sais ainsi en permanence ce que je dois faire et pourquoi je le fais. En fonctionnant toujours par priorité, je peux maximiser le nombre de taches que je ne mène à bien et ne pas perdre de temps à faire des choses qui ne ne s’avèrent pas si importantes que ça au vu des enjeux.