DevOps, ses acteurs et leurs motivations

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.

Les Parties prenantes

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.

acteur DevOps : le développeur

 

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.

acteur DevOps : l'Ops

 

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.

la Middle Manager

 

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.

le directeur informatique

 

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.

la directrice métier

Et après ?

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 :

  • Accorder une place à l’Ops au sein de l’équipe intégrée
  • Se doter d’une structure permettant de définir et faire évoluer les normes et standards
  • Adosser l’initiative DevOps à une démarche Cloud volontaire
  • Identifier, mesurer et suivre des indicateurs alignés avec les objectifs du DevOps
  • Faciliter le design et la mise en place de communautés par practice

 

Allons voir chacun de ces points d’un peu plus près…

Accorder une place à l’Ops au sein de l’équipe intégrée

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 ?

  • Prendre en compte le plus tôt possible les exigences non fonctionnelles liées notamment à la sécurité, la disponibilité, la continuité et les intégrer au backlog produit…
  • Guider l’équipe dans le respect des bonnes pratiques de production et la bonne utilisation des normes et standards
  • Permettre d’apporter un éclairage sur la faisabilité technique de certains développements et sur les capacités d’évolution des normes en cours
  • Faciliter la compréhension des outils orientés Ops du pipeline DevOps

Gains pour l’ensemble des parties prenantes :

  • Time To Market accéléré par l’anticipation des enjeux techniques et un meilleur respect des normes
  • Standardisation progressive du SI en évaluant mieux et plus en amont le coût du « non standard »
  • Accélération de l’adoption des outils du pipeline

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.

 

Se doter d’une structure permettant de définir et faire évoluer les normes et standards

De quoi s’agit-il ?

De standardiser et de normaliser les environnements techniques mis à disposition pour héberger les applications informatiques

Pour quoi faire ?

  • Maintenir et faire évoluer le référentiel des normes et standards en prenant en compte les nouveaux besoins techniques des équipes
  • Proposer et faire connaître les règles et le processus de gestion du référentiel
  • Permettre aux évolutions et innovations de s’inscrire plus harmonieusement dans l’existant

Gains pour l’ensemble des parties prenantes :

  • Connaissance et bonne utilisation des normes et standards
  • Gain de temps et d’énergie pour maîtriser les environnements
  • Maîtrise du processus de soumission d’une évolution ou d’une innovation

DevOps et automatisation riment nécessairement avec standards connus et appliqués.

 

Adosser l’initiative DevOps à une démarche Cloud volontaire

De quoi s’agit-il ?

De mettre à disposition de façon rapide et fiable les environnements standards

Pour quoi faire ?

  • Disposer d’environnements de façon prédictible
  • Bien maîtriser le provisioning / dé-provisioning
  • Pouvoir distinguer différentes qualités de service (sécurité, disponibilité, résilience,…) selon les besoins

Gains pour l’ensemble des parties prenantes :

  • Accélération du Time To Market à tous les stades du cycle de vie
  • Le juste environnement au juste prix pendant la durée qui convient
  • Garantie du standard
  • Adaptation possible au niveau infrastructure, Plateforme ou Applicatif

Pas de DevOps sans provisioning d’environnements automatisé donc pas de DevOps sans Cloud.

 

Identifier, mesurer et suivre des indicateurs alignés avec les objectifs du DevOps

De quoi s’agit-il ?

De disposer de métriques qui permettent de mesurer le succès de l’initiative DevOps

Pour quoi faire ?

  • Légitimer la démarche
  • Motiver les troupes
  • Renforcer l’alignement des objectifs et des moyens nécessaires pour les atteindre

Gains pour l’ensemble des parties prenantes :

  • Gagner en confiance
  • Accueillir et célébrer les succès
  • Se fixer de nouveaux objectifs encore plus ambitieux

Les équipes n’agissent pas uniquement dans le sens de ce qui les motivent mais aussi par rapport à ce qui est évalué/mesuré.

Faciliter le design et la mise en place de communautés (par métier, domaine business, rôle, type d’outils…)

De quoi s’agit-il ?

De permettre de structurer la connaissance collective et de faire en sorte qu’elle se diffuse

Pour quoi faire ?

  • Structurer la documentation et les binaires utilisés
  • Permettre un accès et une contribution simple à la connaissance
  • Fournir assistance et partage de bonnes pratiques

Gains pour l’ensemble des parties prenantes :

  • Possibilité d’avoir accès à de la documentation et l’expertise pour mettre en place et utiliser certains outils du DevOps
  • Ré-utilisation accrue de l’intelligence de l’organisation
  • Enrichissement mutuel des membres des communautés et recensement des compétences.

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.

 

En conclusion

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

Oubliez un instant la technique, DevOps est avant tout une aventure humaine

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.

Objectif n°1 : les exécutifs doivent sponsoriser la démarche en toute connaissance de cause et leurs préconisations doivent être prises en compte   

Moyens d’y parvenir : sensibiliser les décideurs aux tenants et aboutissants de la démarche DevOps et recueillir leurs enjeux et contraintes.

Objectif n°2 : permettre aux équipes de mesurer ce que l’on peut attendre d’une démarche DevOps

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.

Objectif n°3 : définir une cible motivante et la partager pour que chacun s’inscrive dans la démarche

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.

Objectif n°4 : monter en maturité sur la cohésion, l’organisation et les pratiques agiles / DevOps

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.

Objectif n°5 : permettre à la nouvelle organisation d’acquérir l’autonomie nécessaire pour poursuivre sa progression

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 :

  • sensibilisation des dirigeants et formation des équipes
  • définition des objectifs et de la roadmap DevOps
  • accompagnement à la montée en maturité agile et DevOps des équipes
  • formation des coachs DevOps de la nouvelle organisation.

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.
 
 

Une organisation DevOps efficace passe par l'autonomie des équipes

organisation-devopsLe 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 :

  • donner et partager le sens de l’activité de l’équipe en établissant un lient plus fort entre le métier, le digital et l’IT
  • travailler à des taches variées et enrichissantes au sein d’une équipe pluridisciplinaire
  • adopter des rituels de travails qui fluidifient le travail en équipe
  • définir et partager des valeurs et adopter des principes qui font progresser l’équipe.

Donner du sens à l’activité de chacun

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.

Travailler en équipe autonome pluridisciplinaire

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.
 

Adopter des rituels de travail qui favorisent le partage

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).

Partager des valeurs motrices

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.


Autres articles sur le même thèmes :
Importance des valeurs pour donner du sens
Dynamique d’équipe et harmonie au travail

Des rôles clairs, une organisation efficace