Comment gérer le Run en contexte agile ?

À quelles dérives s’expose-t-on vis-à-vis du RUN ?

Dès lors que le produit est rendu disponible pour les utilisateurs, la Scrum Team (dénomination propre au guide Scrum qui désigne l’équipe réalisant le produit) se verra exposée à des imprévus. Dans les cas les plus critiques, ceux-ci viendront impacter le contenu du Sprint en cours et par conséquent la roadmap prévisionnelle du Product Owner.

L’équipe de réalisation détient une idée de ce qu’elle peut réaliser sur chaque Sprint, en fonction de laquelle les User Stories les plus prioritaires du Backlog vont être embarquées. À ce stade, l’équipe de réalisation ne dispose pas d’une marge de manœuvre qui permettrait de gérer un imprévu comme la détection d’une anomalie critique nécessitant d’être corrigée au plus vite. La correction de cette anomalie va donc très probablement remettre en cause le périmètre du Sprint actuel, voire son objectif, du fait qu’elle va mobiliser une ou plusieurs ressources de l’équipe.

Si la détection de bogues (surtout s’ils sont importants) est fréquente, alors le projet peut rapidement tomber dans des dérives. Un exemple est la perte de maîtrise des projections à court terme qui sont mises en visibilité des parties prenantes du projet !

Pallier ces difficultés tout en conservant les principes agiles

Le guide Scrum ne propose pas une méthode de gestion des anomalies ; cela reste la liberté de l’équipe chargée du produit. En revanche, il existe au moins deux possibilités qui, à notre sens, sortent du lot. La plus logique, au regard de ce framework, est de concevoir les anomalies comme des items du Product Backlog, au même titre qu’une User Story, avec une estimation en termes de complexité ainsi qu’une priorisation en comparaison avec les autres items du Backlog. Dès lors qu’une anomalie est détectée, deux choix s’offrent à l’équipe :

1. Cette anomalie est peu critique et n’a donc pas besoin d’être corrigée d’ici la fin du Sprint en cours. Dans ce cas-là, on positionne un ticket « anomalie » dans le backlog, que l’on priorise et qu’il faudra estimer en termes de complexité avant de l’embarquer dans un Sprint. Au même titre que les User Stories font l’objet de sessions d’affinage (le terme « refinement » est souvent utilisé), les anomalies le feront aussi pour voir suffisamment clair sur ce que l’on s’engage à réaliser. Avant embarquement du correctif, il faudra l’estimer en termes de complexité tout comme les User Stories.
2. Cette anomalie est critique et nécessite d’être corrigée au plus vite. La démarche générale est la même que dans le premier cas : identification, intégration dans le backlog, priorisation puis affinage. Mais ces anomalies vont être déroulées immédiatement afin d’embarquer le développement du correctif dans le Sprint en cours ! Dans ce cas-là, la ou les User Stories les moins prioritaires du Sprint seront renvoyées dans le Backlog afin de libérer du temps pour l’équipe.

Le Sprint et plus globalement l’évolution du produit à plus long terme se retrouvent donc impactés. En revanche, ce système de « trade-in / trade-out » est simple et permet une meilleure compréhension de la (dé)priorisation des sujets de la part des parties prenantes qui gravitent autour du projet.

Afin de ne pas générer de frustration, il est bien sûr essentiel que la priorisation du backlog se fasse en concertation avec les parties prenantes. La communication est donc clé, lorsque des modifications de Sprint surviennent.

Une autre façon de gérer le maintien en conditions opérationnelles d’un produit – tout en respectant les principes agiles – est de réserver une partie de la capacité à faire, de l’équipe de chaque Sprint, aux imprévus, à la résorption de la dette technique et à la qualité.

La valeur générée avec une telle organisation peut sembler diminuée aux yeux des parties prenantes. C’est pourquoi il est nécessaire de formuler l’ensemble des items d’un point de vue utilisateur : « si je ne corrige pas cette anomalie, qu’est-ce que mon utilisateur ne pourra plus/pas faire ? ».

L’intérêt de la priorisation de certains items et donc la pertinence d’une capacité dédiée seront plus évidentes ! C’est aussi une organisation qui permet d’affronter les périodes de crise avec de multiples bogues de production en parallèle, et qui met l’accent sur la qualité, chère à la philosophie agile. Dans certains projets, c’est un dispositif qui est adopté ponctuellement « en mode Task force », suite à une mise en production fastidieuse par exemple.

Et hors Scrum ?

Si Scrum présente beaucoup d’avantages (framework éprouvé, cadre assez complet sans être lourd, etc.), d’autres frameworks agiles comme Kanban, négocient mieux la gestion du RUN à notre sens en raison d’un flux de travail tiré et non poussé. Avec le framework Scrum, les User Stories sont « poussées » aux développeurs* au moment du Sprint Planning, notamment par le Product Owner. Les développeurs ont donc un certain nombre de User Stories à traiter durant le Sprint, répondant à un objectif fonctionnel plus général.

Avec le framework Kanban, on ne définit pas un lot de tâches à traiter sur une durée fixée. Chaque membre de l’équipe de réalisation vient piocher (« tirer ») dans le backlog un item à traiter. Dès que ce dernier est terminé, le développeur vient en piocher un second et ainsi de suite. Chaque membre de l’équipe ne s’engage donc que sur un seul item à la fois ; la détection d’une anomalie critique viendra simplement loger un item correctif en haut du backlog, qui sera « tiré » par l’équipe dès que le prochain item sera terminé. Dans ce contexte, la détection d’une anomalie urgente ne vient pas perturber une cadence imposée par le système de Sprint, précisément parce que cette notion de cadence imposée devient caduque sous Kanban.

C’est donc à votre tour de prioriser vos besoins et faire le choix du cadre de travail le plus adapté : réactivité de traitement plutôt que planification amont ? Besoin poussé ou besoin tiré ? Communication amont ou reporting ?

Conclusion

La gestion des anomalies dans un contexte agile est un sujet qui fait souvent débat. Certains l’identifient comme un « point dur » et ne sont pas convaincus par l’efficacité d’un framework comme Scrum au regard de cette problématique. Ceci dit, des solutions respectant les principes agiles existent, et ces anomalies peuvent être traitées avec le fameux prisme de maximisation de valeur. 

Les méthodes Scrum et Agiles, plus généralement, mettent l’accent sur la qualité, au travers de tests fréquents. Si votre projet rencontre régulièrement des difficultés de production, il faut, en plus d’avoir une organisation permettant de les gérer, s’attaquer à la source du problème !

Ces difficultés peuvent être multiples. Elles peuvent trouver leur origine dans la stratégie de tests, ou peut-être d’une Definition Of Done à étoffer, voire même de la mise en place d’une Definition Of Ready, afin de mieux filtrer la maturité des items à embarquer.

Quelle que soit l’origine de ces problèmes, ils peuvent être identifiés et traités avec l’aide du Scrum Master de votre équipe en rétrospective… et même en dehors !

* Les développeurs désignent l’équipe de réalisation qui n’est généralement pas composée uniquement de développeurs, mais aussi de testeurs, d’UX designers, etc.