La notion de « Definition Of Done » (DOD) fait partie des éléments constitutifs du cadre Scrum. (Cf. https://www.scrumguides.org/scrum-guide.html#artifact-transparency-done )
La DOD est un élément nécessaire à plusieurs titres pour accroître la transparence du système. En particulier elle permet à l’équipe :
• de calibrer la quantité de travail pour l’itération qui débute
• de comprendre et partager le niveau de qualité du produit attendu et sur lequel l’équipe s’engage
• de comprendre la teneur des différents travaux techniques à entreprendre, en particulier sur les « exigences non fonctionnelles »
De manière générale, on s’attend à ce que la DOD du produit se durcisse avec le temps afin de faire croître la qualité du travail, réduisant ainsi la dette technique et le coût total d’acquisition, ce qui est un gage d’adaptabilité du produit.
En revanche, la « Definition Of Ready » (DOR) n’est pas un élément de Scrum mais une pratique complémentaire fréquemment utilisée par les équipes. Scrum suggère uniquement que l’équipe soit en mesure de déclarer si un item du « Product Backlog » est « prêt », dans le sens qu’il peut être sélectionné pour être réalisé dans un prochain sprint.
Attention, la DOR ne doit JAMAIS être utilisée comme une barrière stricte en recréant des silos entre le PO et l’équipe de développement, mais au contraire la DOR doit être un support pour faciliter une réelle collaboration entre le PO et l’équipe de développement.
Cf. https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog
Dans la pratique, l’équilibre parfait est très subtil à atteindre et encore plus à conserver. Ainsi la DOR d’une équipe va être soit trop laxe soit trop stricte.
Le problème est d’arriver à avoir une mesure objective qui permette à l’équipe de savoir dans quel sens faire évoluer la DOR.
Si la DOR est trop laxe, l’équipe va constater fréquemment que malgré sa bonne volonté à bien vouloir s’attaquer à tout ce qu’on lui demande, elle est souvent bloquée après avoir commencé à implémenter les items du « Sprint Backlog » : l’équipe commence les travaux d’implémentation mais doit s’arrêter fréquemment pour aller chercher des informations importantes manquantes pour poursuivre le développement de l’item en cours.
Chaque arrêt génère un gaspillage de temps, d’énergie et de perte de focalisation important. Un point de mesure simple mais naïf serait par exemple le temps de blocage cumulé pendant le sprint.
Si la DOR est trop stricte, l’équipe va constater qu’elle n’est quasiment jamais bloquée, ce qui semble intéressant. En effet, le temps de blocage cumulé pendant le sprint devrait être proche de zéro. Cela se traduit généralement par une vélocité « importante » car l’équipe n’est jamais bloquée et a l’impression de travailler sans gaspillage de temps, en livrant ainsi fréquemment un logiciel opérationnel (Cf. http://agilemanifesto.org/iso/fr/principles.html principe #3).
Malheureusement, la DOR utilisée ici comme bouclier protecteur pour l’équipe l’empêche alors d’être en mesure de prendre en charge rapidement des nouvelles idées et d’accueillir les changements de besoins, même tard dans le projet (Cf. http://agilemanifesto.org/iso/fr/principles.html principe #2). En effet, ces nouvelles idées devront passer par de nombreux ateliers, avec de nombreux acteurs avant que l’équipe ne considère que l’idée est enfin raisonnablement réalisable dans un prochain sprint.
Nous avons ici un excellent exemple de cas d’une optimisation locale au détriment de l’optimisation globale du système.
Le temps de cycle est une mesure intéressante qui permet à l’équipe d’apporter un niveau élevé de transparence, pour lui permettre d’inspecter l’efficacité de ses outils (tel que la DOR) et de guider les éventuelles adaptations à apporter au système.
Il est également très parlant pour mesurer si l’équipe arrive à accueillir les changements de besoins, indépendamment de sa cadence de livraison.
Enfin, si le temps de cycle englobe l’ensemble des travaux de l’équipe de « développement » et pas seulement les travaux de « codage », il permet bien de mesurer l’efficacité globale de la chaîne de production de valeur, c’est à dire jusqu’à la la création d’un incrément de produit potentiellement livrable en production avant la fin du Sprint.
En synthèse, si la DOR est trop laxe, le temps de cycle sera détérioré par les nombreux blocages et si la DOR est trop stricte, le temps de cycle sera détérioré par des travaux préparatoires trop longs.
Dans tous les cas, la réduction recherchée du temps de cycle ne peut se faire qu’avec un travail collaboratif en équipe et avec le « Product Owner ».
Casser les silos permet de limiter les files d’attente et de lever rapidement les blocages en partageant rapidement l’information entre les différents acteurs.
Pour en savoir plus sur le temps de cycle : http://referentiel.institut-agile.fr/leadtime.html
Scrum on !