Comment Agile et DevOps sont-ils étroitement liés ?

D'un côté, nous avons le Scrum Master certifié, également appelé programmeur de l'extrême par ses amis et LeSS SAFe DAD par ses enfants (jeu de mots faisant référence à l'agilité à grande échelle ou LeSS, au framework Agile à grande échelle ou SAFe et à la livraison Agile disciplinée ou DAD) : j'ai nommé Agile !

À l'opposé, nous avons la culture Lean qui livre constamment ses projets IaC. Les équipes de développement constituent son bras gauche et les équipes opérationnelles, son bras droit : j'ai nommé DevOps !

Bien que j'aie poussé le matraquage à l'extrême, les phrases-chocs sur Agile et DevOps peuvent laisser penser qu'il s'agit de deux concepts très différents. Pour ajouter à la confusion, les deux concepts semblent échapper à toute définition, même s'ils possèdent leur propre jargon et leurs propres slogans. En tant que méthodologie la plus établie, Agile peut sembler moins vague, mais les gens sont souvent frustrés par la myriade de définitions du terme DevOps. L'absence de définition a donné naissance à des amalgames courants.

Personne ne renie le lien historique entre DevOps et Agile. Lorsque Patrick Dubois et Andrew Clay Schafer ont fait connaissance à la conférence Agile de 2008 sur l'« Infrastructure Agile », le lien avec DevOps était né. Bien que Patrick ait inventé le terme « DevOps » par la suite, la conférence Agile continue de faire honneur à ce lien avec les origines de DevOps. Mais allons au-delà de l'aspect historique et voyons les liens pratiques entre Agile et DevOps en étudiant en détail Scrum et la livraison continue.

Dans certaines équipes, Scrum désigne la différence entre des difficultés permanentes, sources de frustration, et un travail d'équipe productif et gratifiant. Dans d'autres, Scrum remplace la politique et l'engagement à outrance par l'objectivité et la concentration. Les équipes peuvent aussi l'adopter tel un dogme. Lorsque les contraintes du business ou du travail en lui-même exigent autre chose, une équipe Agile exploite les principes Scrum sous-jacents, analyse ses pratiques et les adapte pour gagner en efficacité. C'est d'autant plus important lorsque Scrum est appliqué dans un autre contexte que le développement de logiciels.

Dans la communauté DevOps, les équipes qui ont de l'expérience avec Agile reconnaissent que Scrum est utile pour suivre les tâches planifiées. Certaines tâches opérationnelles peuvent être planifiées : la livraison d'un changement système majeur, le basculement entre les data centers ou l'exécution de mises à niveau système. Mais bon nombre des tâches des équipes opérationnelles sont non planifiées : pics de performances, pannes système ou encore failles de sécurité. Ces événements nécessitent une réaction immédiate. Les équipes n'ont pas de temps à perdre à attendre la priorisation des tâches dans un backlog ou la prochaine session de planification de sprint. C'est la raison pour laquelle beaucoup d'équipes ont adopté la mentalité DevOps, pour aller au-delà de Scrum et s'essayer à Kanban. Elles peuvent ainsi suivre les deux types de tâche et comprendre l'interaction entre celles-ci. Sinon, elles adoptent une approche hybride, souvent appelée Scrumban ou Kanplan (Kanban avec un backlog).

À bien des égards, l'absence de pratiques techniques prescrites explique l'adoption étendue de Scrum. Les pratiques de gestion légères de Scrum font souvent une grande différence pour les équipes. Alors que par le passé, les priorités des différentes sources entraient en conflit, les priorités sont désormais regroupées en un seul ensemble dans le backlog. Et, tandis que le travail en cours débordait de tous côtés, nous établissons désormais un plan et nous appliquons des contraintes qu'il est possible de tenir d'un point de vue temps. Combinées, ces pratiques peuvent stimuler la productivité d'une équipe. Mais, l'équipe peut se trouver en difficulté en raison du manque de pratiques techniques, comme les revues de code, les tests d'acceptation automatisés ou encore l'intégration continue.

Les partisans d'autres courants Agile, tels qu'Extreme Programming (XP), ont des opinions très arrêtées sur la façon dont les pratiques techniques soutiennent la capacité de l'équipe à maintenir un rythme durable et à garantir la transparence et la visibilité pour la direction et les parties prenantes. Certaines équipes Scrum se résignent à placer des tâches techniques dans le backlog. Alors que cela reste faisable pour Scrum, les préjugés des responsables produit sur les fonctionnalités posent rapidement problème. Sauf si le responsable produit est un expert, il ou elle peut ne pas disposer des compétences requises pour évaluer le coût/l'avantage des pratiques techniques. Les choses se compliquent encore pour un responsable produit lorsque les tâches techniques incluent les équipes opérationnelles afin de garantir la fiabilité, les performances et la sécurité.

Chez Atlassian, nous avons compris qu'il était utile d'avoir deux rôles différents pour les produits que nous exploitons. Nos Product Owners comprennent bien les fonctionnalités dont les utilisateurs ont besoin, mais ils ont plus de difficultés à les évaluer par rapport à des capacités non fonctionnelles, comme les performances, la fiabilité et la sécurité. C'est pourquoi chez Atlassian, nous nommons des Service Owners pour certains produits SaaS qui sont chargés de prioriser les capacités non fonctionnelles. De temps en temps, les deux propriétaires doivent « marchander » mais la plupart du temps, les différentes tâches peuvent être réalisées par des équipes indépendantes. Il peut y avoir d'autres façons d'amplifier le feedback des équipes opérationnelles, mais cela n'aide pas à surmonter les préjugés bien trop répandus des Product Owners sur les fonctionnalités. Cette approche à deux propriétaires n'est pas la seule méthode pour adopter DevOps. Il est important de considérer ces caractéristiques non fonctionnelles comme des fonctionnalités et d'être capable de les planifier et de les prioriser comme n'importe quelle autre user story fonctionnelle.

Au final, aucune de ces critiques de Scrum ne concerne véritablement Scrum en lui-même. À l'instar de toutes les méthodologies Agile, Scrum dispose d'un mécanisme d'amélioration des processus intégré appelé rétrospectives. Il est donc raisonnable de penser que certaines équipes Scrum s'inspireront de DevOps et utiliseront les rétrospectives Scrum comme une opportunité d'adaptation et d'ajustement en faveur de DevOps. Cependant, la plupart des équipes devront injecter des idées extérieures pour réaliser cela en pratique. Jusqu'à la popularisation de DevOps (voire son enseignement à l'école), DevOps ne sera pas la suite logique de Scrum. Que l'équipe engage un coach Agile ou DevOps n'a pas d'importance, tant que cette personne est rompue à l'automatisation appliquée au développement, aux tests et au déploiement de logiciels.

Lorsqu'elle est pratiquée de la bonne manière, la livraison continue (CD) contribue à limiter le travail en cours, pendant que l'automatisation du déploiement rehausse les contraintes. Ainsi, la CD permet à une équipe de développement de livrer plus fréquemment et dans une qualité supérieure, sans avoir à choisir entre les deux. Mais, tout comme les équipes qui ne se concentrent que sur Scrum peuvent occulter le contexte général d'Agile, les équipes qui portent leur attention sur la seule CD peuvent ignorer le contexte DevOps.

La CD ne résout pas directement les problèmes de communication entre l'entreprise et une équipe de développement. Si l'entreprise applique un cycle de planification d'un an basé sur le budget, une équipe livrant chaque commit en production peut avoir à attendre plusieurs mois avant que l'entreprise ne puisse réagir. Bien souvent, ces réactions se manifestent sous forme échelonnée, comme l'annulation du projet ou le dédoublement de l'équipe de projet (car un afflux important de nouveaux employés est source de perturbation).

Le modèle Agile Fluency indique comme premier enjeu « Focus on Value », où les équipes se concentrent sur la transparence et l'alignement. Sans cet enjeu, la CD peut facilement devenir un cycle infini d'améliorations techniques qui n'apportent aucune valeur ajoutée au business. Une équipe peut maîtriser la livraison rapide et de qualité, mais pour un produit qui apporte une faible valeur ajoutée aux utilisateurs finaux ou au business. Même lorsque de nombreux utilisateurs ne disent que du bien du produit, l'évaluation de cette faible valeur ajoutée peut s'avérer uniquement possible à l'échelle d'un portefeuille business plus large. Sans cet enjeu important, difficile d'évaluer les pratiques techniques par rapport aux fonctionnalités. Cet aspect est essentiel pour une équipe qui dispose d'une base de code existante, n'a peut-être pas mis en place de tests automatisés ou un design adapté au déploiement fréquent. Dans une infrastructure existante, la transformation CD peut nécessiter plusieurs années. Il est donc d'autant plus important de pouvoir démontrer les avantages business.

DevOps va au-delà de la simple automatisation du pipeline de déploiement. Pour citer John Allspaw, DevOps fait référence à des « équipes opérationnelles qui pensent comme des développeurs, et vice-versa ». En partant de cette idée, Gene Kim explique ses Trois Voies comme des principes DevOps :

La livraison continue (CD) se concentre sur la Troisième Voie : automatiser le flux entre les équipes de développement et les équipes opérationnelles. L'automatisation joue un rôle évident dans l'accélération d'un système de déploiement. Mais la pensée systémique ne se limite pas à l'automatisation.

La Deuxième Voie est caractérisée par la pratique suivante : « Les développeurs portent eux aussi des pagers ». Bien que l'utilisation de pagers ne soit pas forcément nécessaire, les développeurs devront participer à la résolution des tickets opérationnels. Ils pourront ainsi comprendre les conséquences de leurs choix de développement. Par exemple, les développeurs pourront placer les messages de journal à de meilleurs endroits et les rendre plus pertinents. Il n'est pas simplement question de sensibilisation. La compréhension interne du système dont disposent les développeurs peut être exploitée durant le dépannage, afin de trouver une solution et de l'implémenter plus rapidement.

La Troisième Voie consiste à faire des expériences incrémentielles dans le système global, et non à apporter des changements à l'application qui progresse dans le pipeline. En d'autres termes, il est relativement facile de déterminer le temps nécessaire pour l'automatisation et d'exploiter l'infrastructure de plus en plus puissante pour procéder à des améliorations continues. Il est plus difficile de comprendre comment le système de transfert entre les rôles ou les départements induit des retards. Cela signifie que les équipes procèdent à des « inspections et des adaptations » dans tout le workflow de livraison, et recherchent des opportunités d'amélioration de la collaboration humaine. Dans ce contexte, la CD nécessite d'être rompu à l'adaptation et à l'amélioration. Si l'équipe ne réfléchit pas à la façon de gagner en efficacité, mais qu'elle adapte ses comportements pour tout le reste, la CD ne va pas se développer et se populariser. L'équipe doit se sentir investie d'une mission : résoudre ses propres problèmes.

Dans Scrum, chaque rétrospective est une occasion d'améliorer les pratiques et les outils. Mais si l'équipe ne saisit pas ces occasions pour résoudre les problèmes techniques à court et long terme, elles se contenteront d'attendre que le responsable produit place les tâches de CD dans le backlog, ce qui n'arrivera jamais.

Scrum applique le principe Agile suivant : « Tout changement, même tardif, des exigences pendant le développement est bienvenu. Les processus Agile transforment le changement en avantage concurrentiel pour le client. »

La livraison continue applique le principe Agile suivant : « Notre priorité absolue est de satisfaire le client en livrant au plus tôt et de manière constante des logiciels de qualité. »

Cela signifie qu'Agile consiste davantage à adopter les changements entrants et sortants qu'à organiser des cérémonies, comme des stand-ups et des réunions de planification de sprint. Dans les faits, le manifeste Agile regroupe 10 autres principes. Plutôt que d'essayer de faire un choix parmi les principes, vous devriez les considérer comme un tout. Ensemble, ces principes reflètent un état d'esprit face au changement qui est commun aux équipes Agile et DevOps.

Les équipes s'efforcent d'exécuter des systèmes fragiles, mais stratégiques pour le business. C'est pourquoi ces systèmes requièrent les changements les plus urgents. En tant que tel, le principe Agile qui consiste à accepter le changement ne veut pas dire « appliquer aveuglément les changements ». Il est question de tenir les équipes de développement responsables de la qualité de leurs changements, tout en améliorant la capacité globale à apporter une valeur métier. L'accent mis sur la valeur métier est un autre point commun entre Agile et DevOps

Au final, ni Agile ni DevOps ne constituent un objectif métier en soi. Il s'agit de mouvements culturels qui peuvent inspirer à votre organisation de meilleures méthodes pour atteindre vos objectifs. Agile et DevOps se complètent plus qu'ils ne s'excluent mutuellement. L'astuce pour éviter tout conflit entre ces deux idées consiste à comprendre les valeurs et principes sous-jacents sur lesquels elles reposent. Les définitions rapides mais étroites donnent lieu à une réflexion cloisonnée. Maintenant que vous savez qu'Agile ne se limite pas à Scrum et que DevOps ne se limite pas à la CD, vous êtes prêt à découvrir la puissance d'Agile combiné à DevOps.