Blog ENI : Toute la veille numérique !
💥 Un livre PAPIER acheté
= La version EN LIGNE offerte pendant 1 an !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Passez au DevOps
  3. Culture agile et DevOps
Extrait - Passez au DevOps Votre nouvelle façon de travailler
Extraits du livre
Passez au DevOps Votre nouvelle façon de travailler
1 avis
Revenir à la page d'achat du livre

Culture agile et DevOps

Introduction

Les précédents chapitres ont mis en évidence que les principes du DevOps ne fournissent pas une méthode. Tout comme l’agilité, ces principes décrivent l’appropriation d’une nouvelle culture d’entreprise liée à l’ingénierie qu’elle met en œuvre pour innover et opérer. Il n’existe pas de recette pour adopter le DevOps. Par exemple, l’automatisation de toutes les tâches de déploiement (telle qu’elle existe désormais dans les grandes structures), si elle est nécessaire, ne suffit pas à affirmer que l’entreprise a adopté une culture DevOps.

Le DevOps et l’Agile participent à la même culture au travers de principes qui se rejoignent, parfois totalement. Cette culture est l’ensemble des valeurs auxquelles elle se réfère. Elle est un élément essentiel qui permet aux équipes de développement, des opérations et des métiers, de se projeter à travers une vision commune et globale et des pratiques qui s’alignent sur les mêmes objectifs. 

Une culture de la communication plutôt que du contrat

1. Les règles du contrat

Dans une organisation classique, il y a deux types de contrats :

  • Ceux qui régissent les interactions d’un service avec les autres services, ou avec les autres entités juridiques du groupe. Dans ce cas, les contrats internes sont en général codifiés et standardisés au travers de référentiels méthodologiques tels qu’ITIL.

    Ces contrats de service internes constituent les murs des silos. Ils construisent des barrières entre les équipes et cimentent le mur de la confusion. Afin de répondre à ses engagements de contrat, chaque service se retranche derrière les règles écrites, ce qui l’amène à optimiser son efficacité au niveau local sans mesurer les conséquences au niveau global. Cela conduira à des frictions et des oppositions comme évoqué dans le chapitre Le mur de la confusion à la section traitant de l’isolement des silos. Les organisations DevOps doivent par nature favoriser la fluidité des interactions et avoir des approches intégrées et transversales pour les équipes produit. Pour cela, elles doivent repenser leur organisation. Ce point sera abordé dans un prochain chapitre.

  • Ceux qui régissent, de l’échelle d’un service à l’échelle d’une organisation entière, les interactions avec les intervenants extérieurs tels que les prestataires de services, les vendeurs de logiciels, les fournisseurs de matériels, auditeurs, etc.

Un contrat client-fournisseur est caractérisé par des éléments structurants qui définissent le niveau de relation entre les parties. Leur structure minimale se construit généralement autour des éléments...

Une culture du résultat plutôt que du process

1. Pour quel résultat ?

Il convient ici de définir le "résultat" au sens agile du terme. Le résultat est une solution qui fonctionne et qui apporte de la valeur au client. Mais cette idée du résultat ne va pas forcément de soi.

Une autre définition du résultat pourrait être "Livrer un projet dans les délais et le budget prévu".

Une autre encore pourrait être "Livrer l’ensemble des livrables prévus au plan d’assurance qualité".

Ou enfin une autre pourrait être "Mettre en production une application qui ne produit pas d’erreur".

La notion de résultat est donc essentiellement liée au regard qui le conçoit. Le service opérations verra que l’application ne tombe pas en panne. Le service études verra que les fonctionnalités du cahier des charges ont toutes été livrées et que toute la documentation a été produite. Le responsable métier verra un budget respecté et une livraison dans les temps. Le client, lui, verra le résultat.

Le seul résultat qui compte est dans les mains du client. C’est lui qui va déterminer si le résultat est un succès ou un échec.

C’est en ce sens qu’il faut comprendre et interpréter les valeurs agiles :

"Valoriser des solutions opérationnelles, de préférence à une documentation exhaustive"

"Valoriser les individus et leurs interactions, de préférence aux processus et aux outils"

L’agilité et le DevOps mettent en avant les efforts pour produire un résultat qui apporte de la valeur au client plutôt que de satisfaire à des exigences de fonctionnement internes.

Cela...

Une organisation apprenante plutôt que la culture du blâme

La question de la performance abordée précédemment est aussi liée à la façon dont l’organisation perçoit le besoin de prendre des initiatives et d’en apprendre quelque chose, quel que soit le résultat, succès ou échec.

Dans une organisation reposant sur des processus statiques satisfaisant au seul besoin des silos, chacun doit absolument agir conformément au processus. Si un individu ne parvient pas à réaliser ce qui est attendu par le processus et mesuré par des métriques, il est alors sanctionnable en tant que personne. Il n’y a pas de place pour l’initiative car elle constitue un risque de ne pas satisfaire à ces métriques et de s’exposer au blâme de la direction et même de l’équipe entière, qui voit sa performance se dégrader, impliquant de perdre la rétribution qui lui est attachée.

images/04EI08.png

À l’opposé, dans une organisation agile et DevOps, la performance est directement associée à la capacité de l’équipe de s’adapter au besoin et au contexte. L’adaptabilité n’est pas un processus qui se décrète. C’est une expérience qui se vit et se construit au quotidien. Pour cela, il est nécessaire d’essayer, d’échouer, d’apprendre, et de recommencer.

images/04EI09.png

Autant la performance d’une organisation en silos doit être linéaire du début à la fin d’un projet afin de répondre à un enjeu de stabilité et de conservation des engagements entre services, autant elle suit une courbe exponentielle dans une organisation agile. Chaque changement, chaque amélioration, permet d’en apprendre un peu plus sur la façon d’être...

La posture managériale

1. Le management par le contrôle

L’ensemble des notions abordées dans ce chapitre amènent à questionner la posture des managers qui ont pour mission d’accompagner la mise en place des pratiques agiles et DevOps dans l’entreprise. Si John Shook préconise un changement culturel en favorisant l’introduction de nouvelles pratiques amenant à une nouvelle culture, il n’en reste pas moins que la place du management dans une phase de transformation est centrale.

Le socle culturel et méthodologique des managers est souvent éloigné de la culture agile, et même de la culture Lean. En effet, même si celle-ci est revendiquée dans le secteur industriel, il ne s’agit bien souvent que de la superposition de principes rationalistes cachés dans un formalisme Lean. Ainsi, la pensée issue du rationalisme cartésien prédomine encore. Elle sépare l’action, qui relève du corps et du faire, de la conception et de la décision, qui relèvent de l’esprit et de la pensée. Cette vision (dont nous pouvons largement avouer qu’elle nous est devenue plus intuitive que réfléchie), nous amène à reconnaître deux classes d’acteurs dans une organisation productive :

  • ceux qui font et exécutent,

  • ceux qui commandent et contrôlent l’exécution.

Dans cette école, le manager décide, planifie et conçoit. Il veille ensuite à la réalisation en mettant en place un système de contrôle qui mesure les écarts par rapport au plan qu’il a mis en place, tant en termes de résultat que de planning et de coût. Philippe Lorino décrit plus en profondeur le principe du rationalisme cartésien à l’adresse :...

L’impact sur les stratégies RH

1. Faire évoluer le recrutement

Le recrutement est un processus clé et critique lorsque l’on souhaite faire évoluer l’organisation et la culture dans l’entreprise. Il est important que les nouveaux collaborateurs participent, et même promeuvent, ces changements.

Pour cela, les grilles d’évaluation utilisées pour sélectionner les candidats doivent intégrer des compétences en lien avec les besoins d’une organisation DevOps. Globalement, il faut passer d’une grille de lecture focalisée sur la valorisation de l’expertise, ce que l’on appelle les hard skills, techniques ou managériaux, vers une grille d’évaluation introduisant les compétences relationnelles et l’aptitude à intégrer une équipe, ce que l’on appelle communément les soft skills.

Un exemple hyperbolique illustrant le besoin d’équilibrer les compétences est celui des astronautes. L’image de technicité et d’expertise que dégage ce métier laisse penser que la compétence technique est prépondérante. Notre imaginaire positionne l’astronaute comme une sorte de héros moderne capable de comprendre et de maîtriser les systèmes les plus complexes. Pourtant, ce qui est le plus critique est la capacité de vivre avec des collègues dans un environnement exigu, hermétique, sans échappatoire et pendant de longs mois. La compétence relationnelle est critique car il n’est pas possible d’embarquer dans une aventure de longue haleine et dans cet environnement en risquant de provoquer des conflits interpersonnels irréparables qui pourraient mettre en danger la mission tout entière. Les compétences techniques s’acquièrent...