1. Paris DevOps
    1. Présentation
    2. Meetups
    3. Communauté
    4. Blog
  2. Blog - thèmes
    1. meetup (46)
    2. compte-rendu (6)
    3. parisdevops (1)
    4. devops (12)
    5. revue-presse (7)
    6. retour-experience (1)
  3. Online
    1. Flux RSS
    2. Calendrier
    3. Twitter

Compte-rendu du meet-up du 6 janvier 2015

Le 21/01/2015 Thèmes : meetup, compte-rendu

Le 6 janvier a eu lieu le premier Meet-up ParisDevOps 2015. A cette occasion, Dan Maher a présenté un talk sur les bases du DevOps.

Les points d’orgue qui ressortent de son talk énergique sont les mythes qui ont la peau dure:

Dan nous a aussi rappelé que le DevOps ne répond qu’à un seul problème, celui des silos. Sa réponse tient dans l’acronyme CAMS dont chaque élément est indissociable des autres :

Dan a conclut son intervention en nous proposant pour la nouvelle année de sortir de notre zone de confort et d’expérimenter non pas sur de nouveaux outils mais de nouveaux processus.

Suite à cette présentation, nous avons réalisé un open-space dont une des sessions portait sur “Le changement par le bas” ou comment convaincre la hierarchie de mettre en place la culture DevOps. Le débat a permis de trouver les pistes suivantes pour agir:

Trouver son périmètre d’action :

Pour débuter le changement, il faut définir au préalable son périmètre de départ. Est-ce que je vais passer par mon N+1 et N+2 ? Est-ce que je vais directement en discuter de vive-voix avec quelqu’un de plus haut placé ou échanger avec des collègues d’un autre silo ? Choisir son périmètre de départ, c’est aussi comprendre les enjeux des personnes ciblées et adapter son discours pour convaincre.

La culture devops n’est cependant pas une solution miracle et il faut vérifier qu’elle permet de résoudre les problèmes rencontrés. Si ce n’est pas le cas pour les problèmes de vos interlocuteurs, il y a peu de chance qu’ils soient convaincus.

Travailler avec son N+1 et N+2 :

Les N+1 et N+2 sont des alliés de choix dans votre démarche pour convaincre la hiérarchie et les décideurs de l’entreprise. Pour les convaincre, il est nécessaire d’identifier les problématiques de vos responsables directs. Vous pourrez ainsi développer un argumentaire correspondant à leurs attentes et au vocabulaire adapté (productivité, transparence, gain de rentabilité …).

Pour construire cet argumentaire, il faut faire un point sur l’existant en mettant en avant ce que vous considérez être un frein à la productivité de l’entreprise (silos, peu de releases, problèmes récurrents entre devs et ops). Grâce à cet état des lieux, vous pourrez choisir les métriques les plus adaptées pour constater le succès de l’introduction du devops dans votre entreprise en comparant à l’existant.

Si vous réussissez à faire concorder les objectifs de votre hiérarchie directe avec cette solution et que les métriques permettent de valider vos hypothèses, demandez à réaliser une mission de test pour concrétiser vos promesses et exploiter les métriques. Après cette mission, faîtes une réunion avec tous les parties pour mettre en avant ce qui a été appris. En cas de réussite, les métriques seront autant de preuves du bien-fondé de votre démarche. En cas d’échec, ce sera l’occasion de réaliser un post-mortem constructif (blameless) pour ne pas grever l’impulsion devops.

Si vos supérieurs directs ne sont pas convaincus par votre plan d’action, vous pouvez mettre en avant ce qui se passe chez vos concurrents ou d’autres entreprises équivalentes. Ces études de cas constituent des arguments d’autorité qui pourraient séduire vos chefs.

Travailler avec une hiérarchie plus élevée :

Non, vos managers directs ou chefs de projets ne veulent pas de ce changement. Que faire ? Si court-circuiter le N+1 peut s’avérer nécessaire, mieux vaut communiquer avec lui pour éviter qu’il se retrouve en opposition au mouvement de conversion.

Des guerres de territoires ou des objectifs contradictoires peuvent effectivement bloquer les différentes parties. Pour couper court à ces problèmes, il est possible d’aller trouver quelqu’un de plus haut placé comme le chef des deux silos concernés et de lui en toucher quelque mots autour d’un café. En lui expliquant rapidement ce qu’est le devops et en quoi c’est une solution aux problèmes de la société, peut-être sera-t-il convaincu.

Pour ce faire, préparez votre intervention en adoptant un vocabulaire de décideur en parlant argent, time to market et des problématiques business qui sont le quotidien des responsables hiérarchiques choisis. La mise en avant de métriques orientées business et de la communication inter-silo est un atout. La culture devops manque d’un vocabulaire commun mais il faut faire du “marketing technique” pour que votre idée passe.

L’utilisation d’exemple est un bon moyen de faire passer son message en s’appuyant sur des faits concrets comme l’introduction du devops dans une autre équipe en interne ou chez un concurrent. Un exemple proposé est celui de la War Room. Lors de rushs, des équipes constituées d’ops et de devs gèrent les crises. Grâce à une relation plus directe dépassant les silos, ces équipes sont à même de gérer rapidement les crises. Si cette exemple ne reflète pas la définition CAMS (Culture, Automation, Measurement and Sharing), il s’approche de ce que peut produire la culture devops.

Communiquer avec les autres silos :

Pour faciliter le mouvement de conversion, communiquez au sein des équipes, mais aussi avec les autres silos. En ayant des alliés dans les silos avec qui vous voulez faire du devops, il pourront eux aussi contribuer de la même façon à installer cette culture dans la société. Si vous ne pouvez pas de votre côté arriver à vos objectifs, peut-être que de leur côté ces alliés réussiront et installeront la culture devops.

Idées à retenir:

Merci à tous et à bientôt !

A lire aussi :

Commentaires :