Un sprint sans véritable incrément n'est qu'une réunion d'avancement
Scrum fait une promesse simple : à la fin de chaque sprint, l'équipe produit un incrément utilisable du produit. Pas la démonstration d'une fonction à moitié branchée, pas une diapositive qui affiche « terminé à 90 % » — un morceau de produit fonctionnel qui respecte la définition de terminé et qui pourrait être livré. Après les perturbations des deux dernières années, avec des équipes dispersées dans leurs bureaux à domicile et des échéanciers bouleversés par les problèmes d'approvisionnement, cette promesse compte davantage, pas moins. Un véritable incrément est le seul signal honnête auquel une partie prenante peut se fier quand personne n'est dans la même pièce.
Pourtant, l'incrément est la partie de Scrum la plus discrètement abandonnée. Les équipes conservent les cérémonies — la mêlée quotidienne, la revue, la rétrospective — mais l'objet que ces cérémonies servent à protéger s'évapore. Voici la différence entre un incrément qui mérite ce nom et un autre qui ne fait que prétendre l'être.
À quoi ressemble un véritable incrément
Un incrément sain est assez concret pour qu'un propriétaire de produit puisse le livrer sur-le-champ. Le Guide Scrum est catégorique : un travail n'appartient à un incrément que s'il respecte la définition de terminé. Tout le reste est du travail inachevé, et le travail inachevé n'est pas un progrès — c'est un risque que vous n'avez pas encore payé.
Il est intégré au produit, et non posé sur une branche secondaire en attente d'une fusion que personne n'a planifiée.
Il est testé selon la définition de terminé de l'équipe — pas « ça marche sur ma machine », mais vérifié selon la norme que toute l'équipe a acceptée.
Il s'ajoute à la valeur des incréments précédents; le produit fonctionne toujours comme un tout, et pas seulement la nouvelle tranche.
Il peut être présenté comme un logiciel en fonctionnement lors de la revue de sprint, sans clause du genre « imaginez que cette partie fonctionne ».
Une partie prenante qui assiste à la revue peut prendre une vraie décision, parce que ce qu'elle voit correspond à ce qu'elle obtiendrait.
Ce que les équipes acceptent à la place
Quand l'incrément échappe à l'équipe, ce n'est presque jamais un échec bruyant. Il s'érode par de petits compromis qui semblent raisonnables et qui, additionnés, donnent un sprint sans rien de livrable à la fin.
L'habitude du report. « C'est pratiquement terminé, il ne reste qu'à tester au prochain sprint. » Tester fait partie de « terminé ». Un travail qui atterrit toujours au sprint suivant est un travail qui n'est jamais réellement achevé, et l'arriéré d'éléments « presque terminés » devient discrètement le véritable état du projet.
Le théâtre de la démo. La revue montre un prototype soigné ou un enregistrement plutôt que le produit en fonctionnement. Les parties prenantes applaudissent quelque chose qui ne peut pas être déployé, et l'écart entre la perception et la réalité se creuse d'un sprint de plus.
La définition de terminé qui dérive. Sous la pression des échéances, « terminé » perd discrètement une étape — la revue de code ici, le contrôle d'accessibilité là. Chaque coupe paraît minime; ensemble, elles font que l'incrément n'est plus fiable et que la prochaine livraison devient une course au travail reporté.
La dette d'intégration. Le travail de chaque développeur passe isolément, mais les morceaux ne sont rassemblés que lors d'un pénible « sprint d'intégration » plus tard. Une équipe à distance y est particulièrement exposée, car il est facile de remettre à plus tard la friction de la fusion quand on n'est pas assis côte à côte.
La solution n'est pas l'héroïsme; c'est l'honnêteté à propos de la définition de terminé et la discipline de maintenir le seuil là où l'équipe l'a fixé. Découpez le travail assez finement pour qu'un élément réellement achevable tienne dans un seul sprint. Intégrez en continu plutôt qu'à la fin. Et traitez la revue de sprint comme une inspection d'un produit réel, non comme un spectacle — car dès que la revue devient du théâtre, tous les autres événements Scrum perdent le signal qu'ils étaient censés fournir.
Si vos sprints se terminent sans cesse sans rien que vous puissiez réellement livrer, le conseil en réalisation de programmes et de projets de XNM peut vous aider à resserrer votre définition de terminé et à rétablir un rythme de livraison auquel les parties prenantes font confiance.