En janvier 2020, j’avais écrit à propos des « ingénieurs DevOps » autoproclamés :

S’ils associent DevOps à l’agilité, ils ne savent pas vous expliquer ce que DevOps apporte aux cadres agiles antérieurs et à quel point DevOps est compatible avec eux. Or, la question se pose notamment pour le cadre Scrum […]

Je n’avais pas développé ce point à l’époque car la compatibilité entre Scrum et DevOps n’était pas le sujet de l’article. Je vais me rattraper aujourd’hui.

Quel est le problème ?

Les appels d’offre pour le développement de logiciel en « Scrum et DevOps » (« ScrumOps » ?) se font de plus en plus fréquents, suggérant que la combinaison du cadre Scrum et de la philosophie DevOps est naturelle et triviale. Voyons ce qu’il en est.

Les cadres agiles tels que Scrum proposent une approche itérative et incrémentale de la création du logiciel, qui décloisonne les activités de conception, de développement et de test. Ils éliminent ainsi le désastreux effet tunnel et les autres inerties responsables de l’échec de nombreux projets informatiques. Plus personne ne doute aujourd’hui de leur pertinence, mais force est de constater qu’en se focalisant sur l’objectif de l’itération en cours et en se cantonnant à la livraison, ils écartent de facto toutes les activités et priorités relevant de l’exploitation du logiciel.

Or, l’exploitation fait pleinement partie du cycle de vie du logiciel, et pour assurer la disponibilité du service – et donc la correction rapide des anomalies – il est essentiel de fluidifier les interactions et la circulation de l’information entre développeurs et administrateurs (les fameux « ops »). Les pratiques DevOps répondent à cet objectif en intégrant pleinement les activités opérationnelles au cycle de développement et en confiant le tout à une équipe pluridisciplinaire.

Bien que les pratiques DevOps soient perçues comme une globalisation de l’agilité, DevOps et les cadres agiles antérieurs, notamment Scrum dont il est question ici, n’ont ni le même périmètre (inclusion contre exclusion des activités opérationnelles), ni la même priorité (maintien en condition opérationnelle contre objectif d’itération), ni le même rythme (déploiement continu contre cadencement temporel strict et structurant). De ce fait, pris au pied de la lettre, Scrum et DevOps peuvent se révéler contradictoires et mettre l’équipe en défaut vis-à-vis des pratiques requises par l’un ou l’autre.

La priorisation des bogues survenant en production est emblématique de ce conflit entre Scrum et DevOps. La priorité d’une équipe Scrum est le backlog de sprint ; elle doit rester focalisée sur les tâches qui lui ont été assignées pour le sprint en cours. De ce fait, lorsqu’un bogue est signalé en production, l’équipe va, dans la mesure du possible, planifier sa correction dans le sprint suivant. La livraison intervenant en fin de sprint, ce report peut entrainer un délai important entre la détection d’un bogue en production et le déploiement d’un correctif. À contrario, une équipe DevOps a pour priorité la qualité du service et le maintien en condition opérationnelle de l’application. Lorsqu’un bogue survient en production, l’équipe DevOps doit le corriger dans les meilleurs délais et pour y arriver, elle met en pause ses activités courantes. Celles-ci ne seront peut-être pas terminées à la date annoncée, mais c’est un choix assumé. Bien évidemment, cette priorisation connait des exceptions d’un côté comme de l’autre. La correction prioritaire d’un bogue sévère pourra être imposée à une équipe Scrum, tout comme un bogue survenant en production pourra être jugé trop mineur par une équipe DevOps pour être traité en priorité. Mais de manière générale, une équipe travaillant en « Scrum et DevOps » se trouve perpétuellement tiraillée entre l’objectif de sprint et le maintien en condition opérationnelle de l’application.

On observe dans la dernière révision du guide Scrum, publiée en novembre 2020, un glissement doctrinal au travers de phrases telles que « un Increment peut être livré aux parties prenantes avant la fin du Sprint. La Sprint Review ne doit jamais être considérée comme le seul moment pour délivrer de la valeur ». Il reflète sans doute une prise en compte tardive des exigences opérationnelles. Mais même lorsque l’équipe Scrum a automatisé la livraison des artéfacts et lorsque les opérationnels y ont accès, la mise en production (i.e. « le déploiement ») n’est ni la mission, ni le souci de l’équipe Scrum. J’attire d’ailleurs votre attention sur l’ambiguïté du sigle « CD » en anglais, qui peut signifier, selon le contexte, « Continuous Delivery » ou « Continuous Deployment », et laisser croire aux profanes que les équipes Scrum et DevOps sont adeptes des mêmes chaines « CI/CD », alors qu’il y a un monde entre la livraison et le déploiement continus.

J’ai évoqué plus haut le caractère pluridisciplinaire d’une équipe DevOps. Cette équipe devant prendre en charge des activités bien plus variées que celles menées par une équipe Scrum, elle nécessite une somme de compétences supérieure, qu’une seule personne cumule rarement. Pour pouvoir adresser toutes les tâches, une équipe DevOps doit donc être composée de profils complémentaires, avec pour effet de bord une spécialisation accrue des membres de l’équipe et un recouvrement plus faible des compétences. Lorsqu’on applique le cadre Scrum à une équipe DevOps, il s’avère difficile de ne pas pré-attribuer les User Stories aux membres de l’équipe en fonction de leur aptitude à les réaliser et de ne pas prendre en compte la charge individuelle de chacun dans la constitution du backlog de sprint. Voilà une assertion qui doit heurter plus d’un Scrum Master, puisque la doctrine agile veut que le Product Owner ne pilote les activités qu’en fonction de la valeur ajoutée des User Stories et que les membres de l’équipe technique ne sélectionnent les User Stories se trouvant dans le backlog qu’en fonction de leur priorité. Pourtant, le projet réalisé en « Scrum et DevOps » dans lequel je suis impliqué depuis un an et demi est la parfaite illustration de la réalité que je viens de décrire. Comment pourrait-il en aller autrement dans une équipe qui doit développer des outils pointus, les intégrer avec une panoplie de composants tiers dans un environnement complexe, et automatiser leur déploiement et celui de leur plateforme d’accueil dans les nuages, en s’assurant du bon fonctionnement du service et du respect des exigences de sécurité et de qualité ?

Le changement de périmètre affecte aussi le Product Owner, qui doit en théorie se soucier de la production, puisqu’on lui a confié un projet DevOps, mais qui a bien d’autres chats à fouetter, même lorsqu’il est affecté à temps plein sur le projet. Le PO ne tarde pas à s’interroger sur la nécessité réelle de tout valider lui-même, notamment la correction des anomalies qui surviennent en production. N’ayant pas forcément la disponibilité requise à chaque instant, il peut être tenté de décider que ces corrections et d’autres modifications peuvent être déployées sans qu’il les valide. Ce pragmatisme ne me choque pas, mais il convient alors de s’entendre sur ce qui requiert ou non sa validation, afin que l’équipe ne soit pas taxée de ne pas respecter les fondamentaux de Scrum.

Enfin, d’après mon expérience personnelle et celle d’amis baignant dans de tels projets, la dette technique n’est pas vécue de la même manière dans les contextes Scrum et DevOps. Bien que le manifeste agile prône l’amélioration continue, chacun sait que dans la pratique, la plupart des Product Owners ont du mal à accepter les actions de réduction de dette technique, dont ils ne perçoivent pas la valeur ajoutée dont ils sont garants envers les utilisateurs (qui attendent leur ration à chaque revue de sprint). Lorsqu’on confie un projet DevOps à un PO Scrum qui n’a jamais eu à se soucier d’exploitation, il éprouve la même réticence envers les activités qui touchent à celle-ci : supervision, sauvegarde, sécurité… Au début du projet, la mise en œuvre de ces outils lui semble franchement accessoire et c’est seulement lorsqu’il en perçoit lui-même le manque que le PO accepte de planifier rapidement les US correspondantes. Anecdote symptomatique de cette difficulté, les User Stories à teneur technique, ne présentant aucune valeur ajoutée perceptible par les utilisateurs, sont parfois appelées Technical Stories. Cette distinction démontre à elle seule que la dette technique est une épine dans le pied d’une équipe Scrum et non une activité coulant de source. A contrario, l’exploitation entrant dans le périmètre d’un projet DevOps, toute dette technique susceptible de gripper la machine (i.e. entachant la capacité de l’équipe à réaliser rapidement un développement ou un déploiement) est perçue comme un frein au bon fonctionnement du projet, auquel il faut remédier rapidement.

Le choc des cultures est donc inévitable lorsqu’on décide de réaliser un projet en « Scrum et DevOps » et que l’on fait travailler ensemble des personnes venant des deux mondes. Ce choc, il convient de l’anticiper en réfléchissant dès la contractualisation, à la conciliation de Scrum et DevOps, et en proposant une stratégie soutenable.

Conciliation du cadre Scrum et des pratiques DevOps

Différentes stratégies permettent de résoudre les antagonismes entre Scrum et DevOps.

La première consiste simplement à demander à l’équipe Scrum de prendre en charge au fil de l’eau des tâches de « vie courante » (correction d’un bogue, amélioration d’un processus automatisé, résolution d’un problème opérationnel), comme le ferait une équipe strictement DevOps.

  • Avantage : La simplicité.

  • Inconvénient : Le caractère souvent impromptu et non quantifiable de ces tâches perturbe le travail de l’équipe Scrum et peut l’empêcher d’atteindre son objectif de sprint. La vélocité peut devenir chaotique d’un sprint à l’autre, et l’équipe peut perdre toute référence consistante.

La seconde stratégie consiste à créer pour chaque tâche de « vie courante » une User Story dédiée dans le backlog de produit. En fonction de sa criticité, cette User Story sera traitée lors du sprint suivant ou ceux d’après.

  • Avantage : Le sprint courant n’est pas perturbé, l’équipe reste focalisée. Les tâches de « vie courante » se fondent dans le moule Scrum.

  • Inconvénient : Les tâches de « vie courante » s’accumulent dans l’attente de leur traitement. Les problèmes survenant en production sont corrigés avec beaucoup de retard et le projet s’écarte franchement de la philosophie DevOps pour préserver le cadre Scrum.

La troisième stratégie consiste à confier les tâches de « vie courante » à un « équipier de quart », dédié à cette mission et non comptabilisé dans l’équipe Scrum. Dans l’intérêt du projet, il convient que cette charge soit confiée à tour de rôle aux membres de l’équipe technique Scrum (le rythme de rotation pouvant par exemple être d’une semaine ou d’un sprint s’il n’est pas trop long). En l’absence de tâches de « vie courante », l’équipier de quart se saisit de l’une des User Stories en attente dans le backlog de sprint.

  • Avantage : L’équipe Scrum a une taille fixe et reste focalisée sur les objectifs de sprint. Sa vélocité est stable. On alloue une ressource aux tâches courantes, tout en bornant volontairement l’effort qui leur est consacré (une personne). Chacun prenant le quart à tour de rôle, les membres de l’équipe sont amenés à s’intéresser aux différents aspects du projet et ils en améliorent leur connaissance globale, ce qui sécurise le développement.

  • Inconvénient : D’un côté, l’équipe Scrum est amputée d’un membre et de l’autre, la capacité de traitement des tâches de « vie courante » est limitée (les autres membres de l’équipe n’étant pas mobilisables sur ces tâches). Le retard peut s’accumuler.

La première et la seconde stratégies font trop peu de cas à mon gout de l’un ou l’autre des cadres Scrum et DevOps. Elles ne me semblent ni soutenables, ni souhaitables pour l’ensemble des acteurs. Je leur préfère donc largement la troisième et c’est celle que je préconise à mes clients.

Conclusion

Il est possible de réaliser un projet en appliquant le cadre Scrum et les pratiques DevOps, et malheureusement, votre engagement à le faire sera bien souvent tout ce que retiendra votre client de votre réponse à appel d’offre. Mais nous l’avons vu, le « Scrum et DevOps » ne peut s’envisager qu’au prix de quelques aménagements et d’arbitrages raisonnés. Vous devez être très clair à ce sujet dans votre réponse à appel d’offre et présenter une stratégie de conciliation soutenable pour que votre équipe vive sereinement cette expérience et en tire le meilleur.