Pourquoi, en tant qu’Agiliste, aller à la conf DevOps REX ?

Cela fait maintenant 4 ans que chaque année, j’attends octobre avec impatience. Pour savoir pourquoi, vous devrez lire la suite.

Lever de rideau

Cela fait donc 4 ans que j’attends octobre avec impatience, pour l’arrivée imminente du Beaujolais nouveau peut-être me direz-vous ?

Ou comme excuse pour ne plus me raser la moustache afin de préparer « movember », le mouvement caritatif, alors ? Ou encore pour L’Oktoberfest, la fête de la bière ?

Ha oui… Halloween bien sûr !

Encore raté… depuis 4 ans je suis ravi de l’arrivée de l’automne, car je sais que j’y passerai des journées intéressantes, et que l’une d’elles sera au Grand REX sur le sujet du DevOps. C’est effectivement dans ce mythique cinéma parisien qu’a lieu la conférence DevOps REX, avec comme particularité le respect de la règle des trois unités :

•      Unité d’action, on n’y parle qu’en français et d’un seul sujet : le mouvement DevOps,

•      Unité de temps, une seule journée,

•      Unité de lieu, enfin, la grande salle de 2700 personnes.

En effet, tous les REX, les retours d’expérience donc, auront lieu en séquence, dans la salle de cinéma, où l’écran de 300 mètres carrés sera le seul décor pour les oratrices et orateurs, sur scène. Théâtral en somme !

Une conférence à retenir de cette édition 2018 ?

« Eh oui ! », en bon imposteur, je vous livre ce texte écrit en décembre 2018 et jamais achevé, jusqu’à aujourd’hui. Je n’ai pas pu assister personnellement à l’édition 2019 et on peut oublier collectivement 2020, ça fait déjà une année de retard en moins…  ^_^

Je reviens donc sur l’une des conférences particulièrement marquantes pour moi, et sur le fait qu’elle parle autant de DevOps que d’agilité.

La conférence “Mise à l’échelle d’une équipe d’astreinte dans un contexte de forte croissance”

Ce REX a pour sujet la construction de l’équipe pluridisciplinaire, constituée de plus de personnes issues du monde du développement que de celui de l’infrastructure.

« Est-ce que vous trouvez normal de confier la survie nocturne de votre environnement de production à une seule personne ? »

C’est par cette phrase que Damien PACAUD commence sa conférence sur son expérience chez Teads. Pour absorber leur forte croissance et maintenir leurs systèmes opérationnels, cette société est rapidement passée d’une personne seule (le directeur technique), à 3 puis finalement 5 personnes constituant leur équipe d’astreinte « historique ». Une personne d’astreinte par semaine en rotation toutes les 4 semaines. Au-delà du cadre légal à respecter pour faire travailler des salariés la nuit et le week-end, la très forte croissance de l’entreprise a amené des difficultés inattendues par rapport au besoin de maintenir une équipe d’astreinte compétente et opérationnelle.

Première difficulté : la peur, celle qui mène au côté obscur

Ces 5 « sachants », qui ont fait grandir le système et l’ont vu se complexifier au fil des semaines et des mois, sont maintenant considérés comme des experts. Ils ont atteint une compréhension profonde du système. Pour eux, la transition fut « douce », en tout cas continue, d’un produit simple vers une plateforme de plus en plus compliquée. C’est le recrutement qui en est maintenant d’autant plus difficile.

En effet, les nouveaux arrivants sont « terrifiés » à l’idée d’être réveillés la nuit et de devoir opérer un système complexe, qu’ils ne connaissent pas. Cette équipe avait donc atteint une taille maximale incompatible avec la croissance de la société. Ils se sont heurtés à un mur, une taille critique impossible à dépasser.

Second embarras, la documentation

Puisque le système semble inconnu de certains, il suffit de lire la « documentation exhaustive »… 

Vraiment ?

Or s’il existe bien une certaine doc, le constat est lui sans appel : elle n’est pas à jour, d’une part, et celle qui existait n’est en fait pas adaptée aux opérations de maintien en condition opérationnelle. Décision fût donc prise « de construire de la documentation » et après six semaines d’essai, ils furent contraints de constater l’échec : rien de concret n’avait été rédigé. Sans surprise, écrire de la documentation n’a pas marché… « Les individus et leurs interactions plus que les processus et les outils »[2], comme dirait l’autre.

Dernier problème « assez important » : un membre de l’équipe veut arrêter l’astreinte

Ce départ, et la difficulté à recruter de nouveaux membres dans l’équipe, provoqua le passage du mode « c’est compliqué » au mode « Houston, nous avons un problème ». Et paradoxalement, c’est ce sentiment d’urgence, qui je pense, leur a permis d’innover.

En replaçant les individus au cœur de la problématique et en cherchant les vraies raisons de la difficulté à recruter et à construire une connaissance commune, ils ont pris plusieurs décisions et engagements importants :

•      Pour remplacer 1 personne, ils allaient en recruter 8 nouvelles (pour avoir une équipe de 12 personnes),

•      Plutôt qu’une personne d’astreinte, ce serait un binôme, soit 2 personnes d’astreinte par semaine,

•      Il n’y aura plus de processus d’escalade,

•      Le discours attenant : « Nous avons conscience que vous ne pouvez pas tout savoir, tout résoudre. Nous savons que vous allez faire de votre mieux pour résoudre tous les problèmes qui arriveraient pendant la nuit, pendant le week-end »,

•      Sanctification du post mortem : systématiquement fait dans un délai de 48 heures suivant un incident, avec les 12 personnes, pour la recherche de la cause racine.

Pour éviter à quelqu’un d’affronter seul la panne, la nuit, et d’avoir à prendre la décision de réveiller un collègue, c’est la machine qui réveillera en même temps les deux humains. L’union fait la force, et la méthode du canard où l’on explique à haute voix son problème à un objet inanimé dans l’espoir de le résoudre seul, marche d’autant mieux avec une personne réelle.

Une personne issue plutôt du build[3], une autre issue plutôt du run[4], de l’infra, le binôme aura un « set (ensemble) de compétences mutuellement exclusif », ou en tout cas « une surface de connaissance de l’ensemble de la plateforme beaucoup plus large ». On laisse à ce binôme toute latitude pour corriger les problèmes et surtout, on lui fait confiance pour ça ! C’est cette confiance, exprimée clairement, et le fait d’être par deux, Dev et Ops, qui permirent de faire disparaître la peur et de débloquer le recrutement. Depuis environ un an, Teads est « absolument ravie » de son équipe d’astreinte. Elle est vivante, les entrées sorties ne posent pas de difficulté, elle se constitue une bibliothèque de runbooks[5] au fil des rétrospectives (post mortem) et ils ont déjà identifié des pistes d’amélioration

Ce que j’en retire

Ce retour d’expérience m’a inspiré car il démontre selon moi que l’on a beaucoup à gagner en remettant l’humain au centre, et qu’il est toujours bon de changer de perspective, de point de vue, voire de paradigme. 

Parce que d’une part, ils ne pouvaient pas faire plus de la même chose : avoir une équipe plus grande. Et, d’autre part, ils ne pouvaient pas faire mieux la même chose : faire une meilleure documentation. Ils ont simplement arrêté d’essayer pour faire différemment. « L’adaptation au changement »[6], ça vous rappelle probablement quelque chose ? 

Durant toute la présentation, j’ai noté ce parallèle entre l’esprit DevOps de cette équipe et l’agilité de leur transformation: « Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance (…) », ou encore « À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence », c’est pratiquement le Manifest Agile « by the book »…

Et à vous, ça vous dit quoi ?

Voilà pourquoi, ami(e)s agilistes, amis facilitateurs, amies actrices du changement, vous devez aller à DevOps REX, ou à toute autre conférence ou atelier DevOps. Et ce même si vous êtes loin de la technique. A quel moment ce texte vous a-t-il perdu ? Damien a-t-il parlé de technologies nuageuses ? De magie noire automatisée ? De serveurs de « CiDi »[7] ? A aucun moment… et pour cause. DevOps, même s’il vient avec une panoplie d’outils et de technologies, est avant tout un mouvement culturel. Il s’agit de changer la culture des organisations, là encore, ça doit vous évoquer quelque chose, non ? 

Et même si vous restez écartés des phases de d’exploitationeffectives des produits que vous aidez à concevoir, il faut vous y intéresser. Notre monde est devenu numérique, le moindre produit maintenant est connecté… il y a donc quelque part des machines qui écoutent, qui répondent, et ces machines sont mises en place par des femmes et des hommes qui devront interagir à un moment avec celles qui ont réalisé le produit ou service. Sans quoi, sans cette bonne interaction, il est envisageable que la valeur ajoutée soit faible pour l’utilisateur. Sans ce partage, il est possible que les clients soient frustrés par la belle application qu’ils utilisent et qui n’affiche plus rien car la partie serveur, chez l’hébergeur, n’arrive pas à suivre L’agilité est un moyen de délivrer plus rapidement de la valeur, DevOps est nécessaire pour que cette valeur arrive tout aussi rapidement à celles et ceux qui l’attendent.

Pour aller plus loin

[0] Illustration de mon ami et grand maître Gribouilleur Jean-Pierre BONNAFOUS (@ramuncho)

[1] Illustrations créées par pch.vector — fr.freepik.com https://fr.freepik.com/vecteurs/personnes

[2] C’est la 1ère valeur inscrite dans le Manifeste Agile : https://agilemanifesto.org/

[3] Je nomme « build » l’ensemble des personnes et métiers qui construisent, au sens large, la solution (produit et/ou service).

[4] Je nomme « run » l’ensemble des personnes et métiers qui exploitent, durant sa vie commerciale, la solution (produit et/ou service).

[5] Le runbook est le dossier d’exploitation, c’est une compilation systématique des procédures et des opérations que l’administrateur ou l’opérateur du système effectue.

[6] C’est la 4éme valeur inscrite dans le Manifeste Agile : « L’adaptation au changement plus que le suivi d’un plan ».[7] Je n’évoque pas « l’antique » CD audio mais le terme de génie logiciel « CI / CD » qui fait généralement référence aux pratiques combinées d’intégration continue et de livraison continue.

“L’agilité peut-elle sauver le monde ?”

C’est avec plaisir que nous avons eu la chance de participer à l’Agile Tour de Nantes. Jusqu’à la dernière minute, nous pensions qu’il allait être annulé (#confinement2), résultat des courses : 

Une journée sur deux, nous sommes chanceux !

Un programme de qualité, riche et varié quelles que soient les connaissances sur l’agilité. Nous avons pu vivre des méthodologies agiles IRL (en période de Covid, cela fait du bien) permettant de faire émerger l’intelligence collective comme des icebreakers (roue de l’influence par Virginia Satir) ; des ateliers en groupe en mode team building. Le Manager voudrait savoir où en sont les équipes dans leurs livraisons ou dans l’utilisation des outils collaboratifs très appréciés comme Klaxoon ou de chez Extia.

Détails du programme ici

Retrouvez sur Twitter avec le #ATN2020 tous les posts live de cette journée mémorable !

Un thème assez ambitieux

L’agilité est le mot que l’on entend souvent en tant qu’agilistes dans nos projets, avec nos responsables, avec les décideurs qui avancent avec nous. Il faut remettre souvent ce mot dans le contexte de ce pourquoi on doit être agile. La raison même. Et ne pas seulement faire de la gymnastique avec nos projets ainsi que notre capacité à nous adapter vite et bien avec les équipes. C’est un peu plus complexe que cela.

Notre sélection

Comment l’agilité peut-elle contribuer à sauver le monde ?

Animateurs : Pierrick Thibault et Dorothée Le Seac’h, créateurs de la société de services Agile Garden 

Ils nous font part de leur révélation et l’arrivée dans leur vie professionnelle de l’agilité, ainsi que dans leur vie personnelle. Comment mieux accompagner le client ? Ce sujet d’agilité semble être plus fort, plus puissant, nous vivons l’ère du changement (on se regarde tous, entre les participants à cette session de 9h du matin…). De nouvelles pratiques s’ouvrent à nous, s’organisent, nous sommes plongés dedans. Voulons-nous être acteurs et suivre ce vent porteur de ce que l’organisation humaine voudrait faire ? L’agilité est un moyen de passer de l’Ancien Monde au Futur Monde. Yannick Roudaut, TedEx de Nantes, nous confirme que nous sommes dans l’ère de l’effondrement de notre civilisation, dans la fin d’un certain monde.

Et vous agilistes, pourquoi et comment l’êtes-vous devenus ? Nous commençons à faire un icebreaker très enrichissant, proposé par une psychothérapeute Virginia Satir spécialisée en thérapie familiale et PNL. Elle a créé le cercle de l’influence et modèle du changement permettant de tirer l’origine des personnes/concepts qui nous inspirent, nous influencent dans notre parcours, et qui nous passionnent toujours aujourd’hui ! Le résultat est assez bluffant. Envoyez-moi un message en MP sur LinkedIn pour savoir comment produire cette Roue de l’influence.

Une métaphore nous est présentée. Le mouvement des organisations actuelles est comparé à une baleine, difficile à bouger ! En revanche des petits bancs de poissons qui vont dans la même direction, un peu partout dans le monde à un moment pourraient :

  • Aider à faire basculer plus d’entreprises en même temps.
  • Aider à faire bouger les esprits de l’intérieur des organisations plus que la baleine elle-même.

Nous ne sommes pas seuls, d’autres bancs de poissons sont aussi actifs, rejoignez-les, trouvez-les afin de prendre la température et s’encourager, partager, débriefer de nos difficultés entres agilistes. 

Quelques références pour aller plus loin : Romain Couturier, Christian Lapointe, Marc Halevy

Comment maximiser l’effet « nouveau venu », moteur du changement dans une équipe ?

Animateur : Simon Pichon, coach agile de l’ESN Conserto

Il nous a dépoussiéré ce fameux rapport d’étonnement qu’on demande à tout nouveau de rédiger, ou de faire faire en tant que responsable d’équipe, manager.

Utiliser ce fameux rapport d’étonnement au bénéfice de l’équipe :

  • Collecter les informations pendant au moins 3 semaines.
  • Organiser un atelier d’étonnement et le présenter à l’équipe.
  • Trouver ensemble des pistes acceptables en comprenant les enjeux, tenants et aboutissants de l’équipe en mode rétro avec l’outil retroTool.io : à faire, à continuer, à arrêter et identifier les priorités/deadline/owner des sujets.

Simon nous a aussi donné des conseils pour accueillir le nouveau :

  • Lui donner des opportunités lui permettant de poser ses questions (en moment off, hors réunion : pause-déjeuner, café, trajet du travail vers les transports…) 
  • Prendre un #buddy, un référent, hors de l’équipe. Un collaborateur du même niveau hiérarchique permettra d’avoir au moins un premier contact pour déjeuner, lui montrer les bons plans de l’entreprise et l’aider à s’y installer à court terme.
  • Profiter aussi de ce moment pour valider si nos outils d’embording sont adaptés à ce nouvel arrivant et lui faire compléter le cas échéant.
  • Partager les connaissances de l’équipe ou d’un nouveau projet, utiliser des nouveaux outils pour monter en compétence et changer sa manière de fonctionner par le #Mobprogramming

“On a toujours fait comme ça.” Une phrase qu’on a beaucoup entendu dans l’accompagnement au changement face à des équipes non-agiles, en cycle V. Il faut savoir faire confiance, laisser les équipes expérimenter dans leurs directions et pratiquer de l’empathie. Pourquoi les équipes ont toujours fait comme ça ? Comprendre l’historique des métiers, de l’entreprise, vont nous permettre d’aller plus loin. Savoir se questionner : quelles sont les raisons qui me motivent vers ce changement ? La CNV est bien sûr une technique à utiliser pour favoriser l’accompagnement au changement et avoir des résultats concluants dans vos équipes.

Quelques références pour aller plus loin : Alexis Monville, Terrence Ryan

Tous facilitateurs !

Animateur : Julien Fallet

Petit icebreaker sympathique : s’accorder 1 minute, et prendre la météo intérieure, sa température : quelles sont nos pensées, notre condition physique, nos émotions dans l’instant T. On peut utiliser cet outil avant chaque réunion hebdomadaire.

Individuellement, on ne vivra jamais les mêmes expériences qu’en collectivité, mais pour cela, il faut savoir faire émerger les intelligences collectives, les émulsions.

Il faut savoir aussi maîtriser les siennes pour comprendre celles des autres.

Comment ne pas se fixer sur des conclusions hâtives liées à nos observations d’une situation ? Est-ce qu’on est assez neutre pendant cette observation ?

On est très avare pour donner des feed-backs positifs ou négatifs, dans les deux cas, il faut savoir le faire pour le bien-être de l’équipe. De cette manière les équipes grandissent ensemble, pas contre, en explorant ensemble les pistes en vivant ensemble les expériences.

Polarity Management : la solution aux problèmes insolubles

Animateurs : Olivier MY et Irène Doan

La tradition ou le changement, centralisation ou décentralisation, fromage ou dessert… Qui n’a pas vécu de telles oppositions dans sa vie. Le polarity management nous apprend comment appréhender ces situations quand on les rencontre dans notre quotidien ou dans nos équipes.

Lorsque ce type de duel a lieu, on se retrouve souvent avec deux camps ne voyant que les points positifs de leur position et les points négatifs du camp d’en face.

Le polarity management nous apprend que chaque point de vue est une vision de la réalité et que le bon choix est souvent situé à la croisée de ces visions.

Savoir représenter les atouts et inconvénients de ces options ; les partager, les accepter, trouver un compromis. C’est ce que nous apprend le polarity management. 

Quelques références pour aller plus loin : Polarity Management

Conclusion

Un agréable moment qui nous a permis de nous retrouver, d’échanger sur nos problématiques agiles actuelles face aux changements que nous faisons subir à nos équipes. Un sentiment qui nous fait sentir que nous sommes moins seuls dans cette tâche pas si simple ! D’autres sujets agiles ont émergé avec des nouveaux outils, des méthodes.
À suivre bientôt : nos sujets agiles de l’ouest #meetup #agileattitude #agile-ouest

Guillaume Raulet – Coach Safe @ Extia

Sandy Barreau – Product Owner @ Extia

Clarifier un objectif avec le modèle GROW

Le modèle GROW est un outil initialement utilisé en coaching. Par sa simplicité, il peut également être utilisé en management, en gestion de projet ou pour soi. Adaptable, l’exercice peut durer plusieurs heures ou le temps d’un café

par Claire Bresson
le 21 décembre 2020

Les derniers articles

Pourquoi, en tant qu’Agiliste, aller à la conf DevOps REX ?

Cela fait maintenant 4 ans que chaque année, j’attends octobre avec impatience. Pour savoir pourquoi, vous devrez lire la suite. Lever de rideau Cela fait donc 4 ans que j’attends octobre avec impatience, pour l’arrivée imminente du Beaujolais nouveau peut-être me direz-vous ? Ou comme excuse pour ne plus me raser la moustache afin de […]

par Frédéric André
le 1 février 2021

Le codéveloppement professionnel

Le codéveloppement professionnel (que l’on abrégera en codev dans cet article) est une approche de formation qui mise sur le groupe et sur les interactions entre les participants. Cette pratique basée sur le pouvoir de l’intelligence collective a été théorisée et popularisée dans les années 1980 par deux auteurs canadiens : Claude Champagne et Adrien Payette.

par Claire Bresson
le 21 décembre 2020

REX Agile Tour Nantes – 29 octobre 2020

C’est avec plaisir que nous avons eu la chance de participer à l’Agile Tour de Nantes. Jusqu’à la dernière minute, nous pensions qu’il allait être annulé (#confinement2), résultat des courses… Une journée sur deux, nous sommes chanceux !

par Sandy Barreau
le 26 novembre 2020

Terminez sa formation à distance 3/3

Dernier article consacré à l’animation de formation ou d’atelier à distance.
Cette fois-ci quelques conseils pour l’après formation.

par Claire Bresson
le 7 septembre 2020