← Tous les articles

Quand le sprint se fait détourner : l'histoire d'une équipe Scrum face aux interruptions en cours de sprint

By XNM Technologies · April 28, 2021 · 3 min read
Quand le sprint se fait détourner : l'histoire d'une équipe Scrum face aux interruptions en cours de sprint

Une équipe produit qui soutenait une plateforme interne revenait sans cesse sur la même plainte en rétrospective : chaque sprint commençait au propre et finissait dans le chaos. Elle s'engageait sur un objectif de sprint le lundi, et dès le mercredi un directeur transférait une demande « urgente », une partie prenante glissait un « petit service » dans la messagerie de quelqu'un, et un backlog de sprint à moitié fait se dispersait. Ce scénario est anonymisé, mais si vous faites du Scrum dans une équipe hybride au sein d'une organisation occupée, vous en avez sans doute vécu une version.

Diagnostiquer le vrai problème

L'équipe a d'abord blâmé les interruptions elles-mêmes. Mais le Guide Scrum fournit déjà les mécanismes pour gérer le changement — le problème était qu'elle avait cessé de les utiliser. Trois choses s'étaient discrètement effondrées :

  • L'objectif de sprint était une liste de tickets, pas un seul objectif cohérent, alors rien ne semblait protégé quand du neuf arrivait.

  • Les demandes parvenaient directement aux développeurs en messages privés, contournant totalement le Product Owner.

  • Il n'y avait aucune compréhension commune que le backlog de sprint appartient aux développeurs et que la portée se négocie, ne se dicte pas.

Autrement dit, les interruptions étaient un symptôme. La cause était que l'équipe avait laissé s'éroder la responsabilité du Product Owner sur le backlog produit, sans aucune façon convenue de décider ce qui était vraiment urgent.

Ce que l'équipe a changé

Elle n'a pas inventé un nouveau processus. Elle est revenue au Scrum tel qu'il est écrit et l'a appliqué avec discipline.

  1. Un seul objectif de sprint, clairement énoncé. L'équipe a façonné chaque sprint autour d'un objectif unique qui donnait de la cohérence au travail. Un vrai objectif rend évident qu'une demande entrante le menace, et donne à l'équipe les mots pour le dire.

  2. Tout faire passer par le Product Owner. Les nouvelles demandes n'atterrissaient plus dans les messageries des développeurs. Elles allaient au Product Owner, responsable de l'ordonnancement du backlog produit, qui décide si une chose en déplace une autre.

  3. Protéger le sprint, négocier la portée. Selon le Guide Scrum, l'objectif de sprint reste fixe, mais la portée peut être renégociée entre le Product Owner et les développeurs à mesure qu'on apprend. Un élément vraiment urgent n'entrait que si un autre de taille équivalente sortait.

  4. Utiliser la mêlée quotidienne pour s'adapter. Plutôt que de traiter un changement en cours de sprint comme une urgence, les développeurs utilisaient la mêlée quotidienne pour replanifier vers l'objectif quand la réalité changeait.

  5. Annuler, pas corrompre. L'équipe a convenu que si une véritable urgence rendait l'objectif de sprint obsolète, le Product Owner pouvait annuler le sprint — un acte rare et délibéré, et non l'habitude hebdomadaire d'y fourrer du travail en douce.

Le résultat et la leçon

En quelques sprints, la dynamique a changé. Le travail vraiment urgent existait encore, mais il passait désormais par un seul point de décision et s'échangeait contre de la portée existante; l'équipe a cessé de terminer ses sprints avec tout à moitié fait. Le directeur qui transférait des demandes « urgentes » a appris à s'attendre à une conversation rapide et honnête sur les compromis plutôt qu'à une obéissance silencieuse.

La leçon plus profonde, c'est que les interruptions en cours de sprint sont rarement un problème de Scrum — ce sont des problèmes de droits de décision. Scrum vous donne les événements et les responsabilités pour gérer le changement sans chaos. La plupart des équipes qui se sentent détournées ont simplement cessé de les utiliser, surtout l'objectif de sprint qui donne à chacun quelque chose qui vaut la peine d'être protégé.

Si vos sprints déraillent sans cesse et que vous voulez de l'aide pour restaurer la discipline qui fait que l'agilité livre vraiment, le conseil en réalisation de programmes et de projets de XNM peut aider vos équipes à protéger leur concentration sans devenir rigides.