Quand « Terminé » ne veut rien dire : redonner du mordant à une Definition of Done faible
Sur le papier, presque toutes les équipes Scrum ont une Definition of Done. En pratique, beaucoup moins en ont une qui signifie réellement quelque chose. Le Scrum Guide est clair sur son importance : la Definition of Done est l'engagement commun et formel de l'équipe envers la qualité. Lorsqu'un Increment la respecte, il est livrable. Sinon, le travail n'est pas Terminé — il retourne tout simplement dans le Product Backlog. Le problème, c'est que beaucoup d'équipes traitent la Definition of Done comme une affiche au mur plutôt que comme la barrière qu'elle devrait être.
Le coût d'une définition faible est rarement visible en un seul Sprint. Il apparaît plus tard — sous forme d'un arriéré de fonctionnalités « terminées » qui restent à tester, d'une dette d'intégration qui surgit lors d'une livraison, ou d'un Product Owner qui cesse discrètement de croire à la Sprint Review. Après dix-huit mois de chaînes d'approvisionnement perturbées et d'équipes à moitié à distance, bien des organisations traînaient exactement ce genre de retouches cachées, et ne l'ont remarqué qu'au moment de livrer.
Comment une Definition of Done se ramollit
Elle décrit des activités, pas des résultats. « Code écrit, tests écrits » indique ce que les gens ont fait, pas si le résultat fonctionne. Une entrée utile est vérifiable : « les tests automatisés réussissent dans l'environnement d'intégration », pas « nous avons écrit des tests ».
Elle est idéaliste plutôt qu'honnête. Les équipes énumèrent ce qu'elles aimeraient faire — régression complète, analyse de sécurité, documentation — puis en sautent discrètement la moitié sous la pression des délais. Une Definition of Done que l'on enfreint régulièrement vaut moins qu'une courte que l'on respecte vraiment.
Elle n'existe que dans la tête des Developers. Si le Product Owner et les parties prenantes ne peuvent pas dire ce que Terminé signifie, la Sprint Review devient une négociation sur le caractère réellement achevé d'un élément. Ce débat aurait dû être réglé avant le début du travail.
Elle s'arrête à la frontière de l'équipe. Quand le déploiement, l'accessibilité ou la migration des données reviennent à « quelqu'un d'autre », l'Increment n'est pas vraiment livrable. Les équipes hybrides et distribuées le ressentent le plus, car les transferts restent invisibles jusqu'à ce qu'ils échouent.
Elle ne change jamais. Une Definition of Done fixée il y a un an, avant une nouvelle règle de conformité ou une nouvelle plateforme, est discrètement périmée. Elle devrait évoluer avec la capacité et le contexte de l'équipe.
Lui redonner du mordant
La solution n'est pas un document plus long. C'est un document plus court et plus juste, que toute l'équipe applique réellement. Commencez par rédiger chaque élément de façon que n'importe qui puisse le vérifier sans débat — réussi ou échoué, sans interprétation. Puis confrontez la liste à la réalité : lors des trois derniers Sprints, chaque Increment que vous avez déclaré Terminé respectait-il vraiment chaque ligne ? Sinon, changez le comportement ou changez la ligne, mais comblez l'écart.
Rendez chaque critère observable et binaire — il est respecté ou non, sans « presque ».
Couvrez tout le chemin vers le livrable, y compris les étapes actuellement portées par des personnes hors de l'équipe.
Revoyez la Definition of Done en Rétrospective, pas seulement quand quelque chose casse.
Considérez tout travail qui la rate comme non Terminé — renvoyez-le au Product Backlog plutôt que de contourner la règle.
Gardez-la visible et partagée, pour que le Product Owner applique la même exigence que les Developers.
Une Definition of Done avec du mordant change le ton d'une Sprint Review. Au lieu de débattre du caractère achevé d'une fonctionnalité, l'équipe démontre un Increment auquel tout le monde se fie déjà. Cette confiance est le véritable livrable : elle permet au Product Owner de prévoir honnêtement et aux parties prenantes de planifier autour de quelque chose de solide. Pour les organisations qui démêlent encore les arriérés de la pandémie, cette fiabilité vaut plus qu'un nouvel élan de production.
Si vos équipes livrent un travail qui revient sans cesse, le conseil en réalisation de programmes et de projets de XNM peut vous aider à rebâtir une norme de qualité à laquelle toute votre organisation se fiera vraiment.