Agile et DevOps : amis ou ennemis ?

DevOps consiste à appliquer les principes Agile en dehors de l'équipe de développement. Mais la véritable question reste de déterminer le vainqueur du match.

Ian Buchanan Ian Buchanan

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). 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. DevOps !

Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.

Agile ne se limite pas à Scrum

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.

Planification des tâches non planifiées

In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).

In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviewsautomated acceptance tests, and continuous integration.

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é.

Responsables produit et responsables de service

Chez Atlassian, nous avons compris qu'il était utile d'avoir deux rôles différents pour les produits que nous exploitons. Nos responsables produit 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 responsables de service pour certains produits SaaS qui sont chargés de prioriser les capacités non fonctionnelles. De temps en temps, les deux responsables 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 responsables produit sur les fonctionnalités. Cette approche à deux responsables 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.

DevOps ne se limite pas à la livraison continue

When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.

The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).

The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.

Les Trois Voies

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 Première Voie Pensée systémique emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.
La Deuxième Voie Amplifiez les boucles de feedback créer les boucles de feedback de droite à gauche. La plupart des initiatives d'amélioration des processus ont pour objectif de raccourcir et d'amplifier les boucles de feedback afin que les corrections nécessaires puissent être appliquées en continu.
La Troisième Voie Culture de l'expérimentation continue et de l'apprentissage crée une culture qui favorise deux aspects : d'un côté, l'expérimentation continue, la prise de risques et l'apprentissage des erreurs ; de l'autre, comprendre que répétition et pratique sont nécessaires pour maîtriser une tâche.

 

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.

The Second Way is characterized by the practice, "Devs wear pagers too."  Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.

The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.

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.

DevOps consiste à appliquer les principes Agile en dehors de l'équipe de développement.

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

Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.

Up Next
Tutoriels