Cet article fait partie de la série "Monthly DevOps War Stories" (Chaque mois les histoires de la guerre de DevOps"). Chaque mois nous découvrons ce que DevOps apporte à des organisations différentes, nous apprenons ce qui a marché et ce qui a échoué, et nous faisons le tableau des défis à relever pendant l'adoption.

Adapter les leçons de DevOps au management

Il y a de nombreux post de blog, articles et tweets à propos de DevOps sur Internet. Certains débattent des avantages et des inconvénients, d'autres des conséquences de son adoption, pendant que d'autres encore évoquent comment il a été implémenté. Bien que cet article traite quelques uns des aspects de l'adoption de DevOps, son objectif principal est l'application des principes de DevOps à un domaine différent : la direction de l'ingénierie.

Dans cette article, je fais référence à "nous" un peu partout et pour éviter toute confusion, voici une présentation rapide

• Ingrid Franck est le coach Agile de l'équipe d'ingénierie
• Ramon von Alteren est le product owner de l'équipe d'ingénierie
• Mattias Jansson (l'auteur) est le responsable de secteur de l'équipe d'ingénierie, et par paresse parfois appellé team lead, comme je le fais dans cet article.
• l'équipe d'ingénierie constituée de neuf personnes au moment où l'article est écrit.

La culture DevOps à Spotify

Spotify depuis ses tout débuts est imprégné d'une bonne dose de culture DevOps.

Les six premières personnes employées par Spotify étaient des ingénieurs, et l'un d'entre-eux avait un rôle dans l'administration du système (Operations en anglais). Cela remonte à un temps où Spotify était juste une autre startup hébergée dans un appartement. Ce contexte, et la reconnaissance de l'importance des activités d'exploitation dès le tout début de l'histoire de Spotify, a fortement influencé les relations entre Dev et Ops.

Nous avons fait un long chemin depuis. Il y a des centaines d'ingénieurs chez Spotify de nos jours, et ils sont répartis dans quatre villes et sur trois fuseaux horaires. Bien que l'état d'esprit DevOps ne s'infiltre pas dans les coeurs et les âmes de chaque individu dans l'équipe d'ingénierie, et bien que cela ne soit pas réellement nommé, on peut le voir transparaître partout dans l'organisation du travail quotidien ou les conversations à la machine à café.

Beaucoup de startups sont constituées de développeurs et de business guys farfelus. Dans ces entreprises l'ingénieur de production en charge de l'administration du système est embauché une fois que le code a été écrit et qu'il faut quelqu'un pour déployer et maintenir le système en condition opérationnelle. Chee Spotify, il y a une zone de recouvrement des responsabilités, des compétences et des intérêts des deux camps. Nous avons quelques développeurs inhabituellement Ops, et symétriquement beaucoup d'ingénieurs des opérations ont un solide bagage de développeur.
L'avantage de ce recouvrement est immense au jour le jour, car ils résolvent des points bloquants potentiels bien avant qu'ils se produisent.

Les développeurs du backend déploient leur code en production eux-mêmes, avec ou sans les ingénieurs de production pour les accompagner. Ceux-ci en en retour, la plupart du temps, encouragent ces développeurs à réfléchir sérieusement aux problèmes qui préoccupent habituellement seulement les opérations, comme le monitoring, les logs, le packaging et la disponibilité.

Comme nous avons des milliers de serveurs en production, nos ingénieurs de production ne raisonnent plus en termes de serveur isolé mais en termes de cluster de serveurs. Les interventions manuelles exceptionnelles pour corriger des serveurs isolés sont évitées autant que possible. Les ingénieurs privilégient la mise à jour par le code. Ils modifient l'état d'un modèle de données source du backend qui affectera la configuration réelle du systèmre via le gestionnaire de configuration qui s'appuie sur du Puppet.

Les services backend ont deux system owners, un du côté Dev et un du côté Ops. Leurs responsabilités principales reposent sur leurs territoires respectifs, le system owner dev détient le code, le design et l'architecture, tandis que le system owner ops détient le service dès qu'il prend vie quand il est déployé et qu'il sert du trafic. Cependant, ces deux territoires se recouvrent largement et donc les deux system owners font des bilans réguliers pour évoquer la scalabilité, les évolutions de topologie aux alentours, les produits qui vont arriver et qui affecteront le comportement du service, etc.

Un dernier exemple est l'équipe dédiée aux outils et services d'automatisation. Les équipes de développement et de production travaillent côte à côte sur des opérations de plusieurs semaines pour résoudre des problèmes spécifiques, soumis et priorisés par les Ops.

Ceci étant dit, notre organisation a toujours un long chemin à parcourir. Le nombre de clients, serveurs, data centers, services, bureaux et équipes augmente constamment, et donc les solutions d'hier ont une tendance marquée à se dégrader dans le présent. Pour couronner le tout, le ratio de Dev par Ops a évolué de telle sorte qu'il dillue un peu l'état d'esprit DevOps.

Leçons de DevOps

Les leçons que le mouvement DevOps nous a enseignées sont nombreuses, mais une des plus importantes est la valeur de l'alignement des objectifs Dev et Ops. Amenez-les à travailler côte-à-côte, donnez leur un espace pour apprendre les uns des autres. En favorisant une communication régulière, les développeurs auront l'opportunité de comprendre les raisons pour lesquelles les Ops doivent parfois poser une anomalie bloquante. Ils apprendront aussi comment anticiper et rendre leurs évolutions compatibles avec les exigences des environnements de production. De plus, lorsque les Ops commencent à voir leur harware et les services qui tournent dessus comme une structure de données malléable sur laquelle ont peut agir avec du code, le développeur a soudain un pouvoir différent. Il ou elle va pouvoir affecter non plus seulement le code tel qu'il est dans les packages, mais pourra adapter la manière de les appliquer en production.

De même, en injectant de l'état d'esprit opérationnel dans le process de développement, la fréquence des interventions où un ingénieur de la production doit passer du temps sur des opérations d'urgence et de nettoyage se réduit, et le temps épargné peut être affecté a des projets de long terme.

Généralement, les méthodes DevOps ont aidé les deux côtés de l'organisation à envisager le système dans sa globalité, le value-stream, et pas uniquement le composant dont ils ont traditionnellement la responsabilité.

Problèmes au pays du Management

Dans de nombreuses entreprises technologiques modernes, on trouve trois responsabilités distinctes autour d'une équipe d'ingénierie. Dans les entreprises plus petites, et en fait même dans certaines plus grandes, ces responsabilités sont généralement regroupées en un ou deux rôles. Chez Spotify, nous essayons de les séparer pour que trois personnes différentes détiennent ces responsabilités. Alors, quelles sont les responsabilités que ces rôles entraînent ?

• Le Product owner est responsable de la livraison des produits à une ou plusieurs stakeholders dans un temps donné. (PO)

• La mission du Team lead est de soutenir l'équipe pour que ses membres soient d'attaque pour les défis qu'on leur soumet, et il est responsable de la solidité architecturale des composants du produit. (TL)

• Le Coach Agile façonne un environnement propice à la santé et à l'engagement des membres de l'équipe qui progressent continuellement et améliorent leur livraisons de produit et leur travail en équipe. (AC)

Ces trois rôles sont parfois en désaccord les uns avec les autres. Dans la plupart des organisations, les gens qui ont ces rôles ont des missions divergentes et peuvent tirer l'équipe dans différentes directions.

Avez vous déjà vécu un conflit entre un Product Owner, mettant la pression pour une fonction nouvelle essentielle, et le Team Lead, soucieux du découragement de l'équipe face à une montagne de dette technique dans le code existant ?
Ou le Coach Agile qui pense que l'équipe a besoin de s'arrêter et réfléchir plus souvent afin de comprendre comment s'améliorer, mais le Product Owner hésite et semble s'inquiéter du fait que le rythme de l'équipe va être cassé ? Ou quand le Team Lead considère que l'équipe est assez Agile et résiste activement à des tentatives de plus en plus stressées du Coach Agile pour aider l'équipe à s'aider elle-même ?

Les problèmes que nous avons mentionnés plus haut sont par un grand nombre d'aspects similaires aux objectifs conflictuels des groupes Devs et Ops dans les entreprises types.

Les entreprises qui découvrent DevOps rencontrent souvent des obstacles (structurels, sociaux, culturels, etc) dans leur entreprise et cela rend l'adoption difficile. Même les entreprises où DevOps s'est imposé vont trouver beaucoup de points de désaccord. Il arrive souvent que l'étendue du problème évoque deux personnes dans un même lit avec une couverture trop petite pour les couvrir tous les deux. Le résultat est un tas de déplacements et de réarragements de cette couverture pour essayer de couvrir les zones exposées.

Il n'est pas inhabituel de voir des ingénieurs de production de la vieille école qui refusent de voir l'infrastructure comme du code, préférant modifier manuellement les fichiers de configuration sur les machines cibles ; des développeurs qui regardent de haut le travail des Ops, qui considèrent que leur travail est fini une fois que le build se termine et que tout ce qui se passe quand leur code atteint le hardware est le problème de quelqu'un d'autre. Les directions Dev et Ops sont en désaccord les unes avec les autres à cause de missions désalignées (nombre de fonctions livrées versus maintien des interruptions de service au minimum).

Ce qui rend DevOps si attractif, c'est qu'il encourage des développeurs et des ingénieurs de production à parler et apprendre les uns des autres. En définitive, tout repose sur la communication. Sur l'alignement des objectifs. Dès qu'on commence à s'écouter l'un l'autre, le premier pas est fait vers une forme de synergie DevOps.

Et alors ... que se passe-t'il quand vous faites la même chose avec des figures dirigeantes plus proches de l'équipe d'ingénierie ?

Et si on amenait les PO, TL, AC à parler régulièrement de leurs soucis, de leurs objectifs à court et long terme pour l'équipe, et pour s'enseigner les uns les autres les réalités dans lesquelles ils vivent ? Trouverons-nous les mêmes effets de synergie dans ces trois rôles ? Nous éliminerons les conflits entre eux, mais trouverons nous ... plus ?

Potlac

C'est ce que nous avons fait il y a six mois. Nous n'avions jamais travaillé ensemble tous les trois dans cette configuration auparavant, et nous étions partants pour faire des expérimentations importantes. Notre but était d'essayer de minimiser les malentendus et peut être d'obtenir des effets de synergie.

Alors qu'avons-nous fait ? Comment avons-nous appliqué les leçons de DevOps dans notre travail ?

Point de synchronisation hebdomadaire

Chaque semaine pendant une demi-heure, nous évoquions l'état actuel de chacun de nos points de vue. Chacun amenait au moins un sujet à la session, et nous en discutions et nous l'assimilions ensemble. Les sujets abordés incluaient par exemple l'implication accrue du stakeholder, les conférences à venir, ou le thème de la prochaine rétrospective.

Echanges courts en chat et synchronisation avant les réunions clés

Avant chaque réunion clé de l'un d'entre-nous, nous avions un échange rapide en chat avec les autres pour avoir les réactions les plus récentes. On répétait les raisons de la réunion, si le(s) objectif(s) étaient réalistes, ou ce qu'on devait faire pour vraiment obtenir l'implication des participants à la réunion.

Têtes à têtes (one-on-one) réguliers

Chacun d'entre nous avait aussi des réunions en tête-à-tête avec les autres une fois par semaine au bureau, par téléphone dans la soirée ou au déjeuner. En réduisant la discussion à deux personnes, le ton de la conversation et les problèmes évoqués sont devenus plus personnels, tout en gravitant autour de nos objectifs communs.

Réunions à blanc

Si une réunion était spéciale, ou l'ordre du jour expérimental, nous répétions la réunion ensemble, en travaillant les parties compliquées pour identifier les failles dans le raisonnement ou pour découvrir les hypothèses cachées.

Ce sont les quatre types d'échanges les plus évidents. La caractéristique qui a émergé de ce groupe de trois était que chacun a commencé à penser comme ses collègues, et dans un certain sens chacun de nous a commencé à porter les trois casquettes, bien que notre casquette d'origine soit toujours plus large que les deux autres. Cela a renforcé notre groupe, et plus nous discutions plus nous renforcions notre coopération.

Un facteur critique du succès de cette nouvelle organisation est que nous partagions un engagement fort en faveur du fonctionnement de l'équipe et non pas d'un individu. A notre avis, c'est ce qui a permis en grande partie que ça marche ; l'idée partagée que l'équipe vaut plus que que la somme de ses éléments.

Quelques temps plus tard, nous sommes tombés par hasard sur un nom pour notre groupe. J'avais un jour placé des photos de nous sur un tableau, avec les initiales de nos rôles sous les images. Cela donnait "PO", "TL", "AC". Cela semblait prononceable, et quand Ingrid réalisa que Potlac peut se prononcer Potluck, le nom s'est fixé et n'a jamais disparu (comme vous le savez peut-être, un potluck est un repas où chacun apporte quelque chose à manger ou à boire à partager avec les autres. Un potluck réussi requiert une coordination entre les gens qui participent, sinon tout le monde amène des desserts et il n'y a pas de plat principal.)

Avantages du Potlac

Vous devez vous dire "Tout ça est très bien et à l'air sympathique. Mais qu'en tirez vous ?" Eh bien, cela dépend un peu des responsabilités que vous avez. Ci-dessous chacun évalue les avantages inattendus qu'il a tirés de cette expérience.

Mattias : le Team lead

Le management est un travail solitaire. Pendant que les ingénieurs peuvent se regrouper autour d'un problème, je ne peux pas souvent faire ça. Je peux demander à l'équipe de faire beaucoup de choses pour moi, mais certaines ne peuvent tout simplement pas être déléguées ou partagées (je pense aux objectifs de carrière, aux confidences personnelles, aux salaires, etc). Bien que je ne puisse pas non plus partager ces choses avec mes collègues de Potlac, il y a d'autres sujets que je peux partager et je le fais. Par exemple, discuter de façons nouvelles et différentes de résoudre des problèmes conventionnels, ou discuter comment accroître son équipe de manière durable. C'est souvent lors de ces discussions que j'obtiens les pièces du puzzle qui m'aident à résoudre le problème sur lequel je travaille. Depuis que nous avons un dialogue continu en Potlac, nous avons développé une capacité à comprendre les visions des autres et nos points de vue respectifs sur l'état et l'histoire de l'équipe. A travers ces pratiques, en combinant nos différents réseaux (à la fois internes à l'entreprise et externes), j'anticipe les choses bien plus tôt que je ne l'aurais fait sinon. Je peux être prêt à temps, et étouffer beaucoup de problèmes avant qu'ils ne deviennent grand.

Ingrid : le coach Agile

Le Potlac m'a apporté l'occasion et le terrain pour avoir des discussions autour d'Agile. Une scène pour dialoguer sur le servant leadership. Un forum pour trouver un consensus sur ce que ça signifie. Ca a formé une interface qui a permis à la direction d'équipe de se concentrer sur les résultats et se tenir les uns les autres pour responsables. C'était au début un bac à sable où l'on planchait sur la responsabilisation, les obstructions et les conflits. Mais aussi une salle de classe où nous parlions des approches pour les réunions avec le stakeholder, des réunions de planification, des rétrospectives, et des tête-à-têtes. Ca s'est aussi transformé en sessions de coaching où nous avons parlé de nos échecs et de ce que nous avons appris. A la place de trois individus, chacun marchant vers son but respectif, nous sommes devenus une équipe, une équipe dirigeante avec une mission commune d'apporter un soutien à nos ingénieurs.

Ramon : le Product owner

Mettre la pression pour obtenir les livraisons peut être une tâche aussi solitaire que gérer une équipe. En travaillant si intimement avec un Team lead et un coach Agile j'ai gagné une multitude d'avantages. Un des plus importants est la focalisation. Cela m'a permis de me concentrer sur la livraison des améliorations du produit dont je suis responsable car je savais que les deux autres aspects de la direction d'équipe, tout aussi importants, étaient traités par mes deux collègues. Les incidents incompréhensibles du passé comme par exemple un soudain manque d'engagement d'un ingénieur pendant quelques temps sont devenus beaucoup plus limpides avec les informations apportées par Mattias sur la situation personnelle de cet ingénieur. Ingrid a introduit de nouveaux moyens de gérer des problèmes classiques avec l'équipe et cela m'a beaucoup aidé. Un autre avantage majeur est la façon de régler le problème toujours épineux d'éviter (ou rembourser) la dette technique. Une discussion ouverte entre les représentants des différents intérêts en jeu facilite l'approche de ce problème. Sinon, c'est un débat intérieur qui se joue dans la tête d'une seule personne.

Nous avons vu comment nos expérimentations initiales avec Potlac ont amené de nouvelles idées dans la dynamique de travail quotidienne, imprévues, et cependant attendues. Cette manière de nous glisser à la place des autres a élargi nos horizons, et donné à chacun de nous plus de contexte pour étudier un problème.

Au final, tout repose sur le partage du contexte. Contexte sur les raisons pour lesquelles un produit est nécessaire tout de suite et non plus tard ; contexte sur les raisons de fond d'un conflit dans l'équipe ; contexte pour aider à choisir la bonne combinaison de méthodologies Agile pour cette équipe en particulier à ce moment particulier.

DevOps aide les ingénieurs qui l'appliquent à mieux comprendre les points de vue des groupes de gens qui les entourent. Il expose leurs besoins et les exigences qu'ils entraînent. De la même manière, Potlac nous a aidés tous les trois en nous donnant du contexte sur un canal dédié à haut-débit.

Et maintenant ?

Bien que cela ait été un parcours extraordinaire, l'environnement dans lequel nous avons travaillé change.
Et avec ce changement nous allons devoir un peu adapter nos méthodes. L'équipe, qui comportait neuf personnes (en plus de nous) va probablement doubler de taille dans l'année à venir. L'entreprise est, comme d'habitude, en croissance et change d'objectif. Ingrid a été appelée ailleurs comme coach Agile, et Ramon a élargi ses responsabilités de PO. Mattias aura une vague de nouveaux ingénieurs à gérer dans son équipe. Chacun de nous devra former des tout nouveaux groupes Potlac dans son entourage.

Nous nous demandons comment Potlac va s'adapter à la croissance de l'équipe d'ingénierie. Avec un plus grand nombre de personnes dans l'équipe, nous aurons probablement plus de produits à développer et maintenir. Cela implique plus de product owners. Le Team lead ne pourra pas gérer tous ces gens, et des formes de fractionnement de l'équipe pointent à l'horizon. Pour finir, nous pourrions avoir besoin de deux coach Agile, si l'équipe grossit autant. Est ce que Potlac fonctionne si ses membres passent de trois à six ?

Une autre question importante que nous avons envisagée est celle de la difficulté à reproduire ce modèle de leadership. Dans le logiciel, si un hack permet de résoudre un problème immédiat, c'est une bonne chose. Cependant, pour vraiment en tirer de la valeur, il doit être documenté et portable. Potlac est-il portable ?

Il serait pratique d'écrire une recette puppet décrivant comment déployer Potlac dans d'autre équipes. Hélas, puppet ne couvre pas cette fonction particulière et d'ici-là, cet article aidera peut-être à expliquer ce que nous avons fait pour obtenir les résultats que nous décrivons plus haut.

Bon org-hacking !

PS : si vous voulez en savoir plus sur la manière dont nous sommes organisés techniquement, lisez l'article d'Henrik Kniberg et Anders Ivarsson sur Scaling Agile at Spotify.

A propos de l'auteur

Mattias Jansson  est team lead d'une équipe d'ingénierie chez Spotify. Il a enseigné comme maître de conférence à l'université et coordinateur des programmes, ingénieur logiciel, ingénieur de fiabilité des sites, et s'est récemment concentré sur le management. Actuellement Mattias se passionne pour Agile, Servant leadership et les techniques pour combler l'écart entre tech et non-tech. Vous pouvez contacter Mattias via Twitter.