Definition Of Ready : outil indispensable ou anti pattern Agile ?

Bien que la Definition of Ready (DoR) ne soit pas un artefact standard de Scrum, cela reste une pratique répandue et voir recommandée par de nombreux agilistes. Parlons-en !

Le principe de la DoR ?

Lister tous les éléments nécessaires pour que la « dev team » puisse travailler de façon fluide et efficace durant le sprint. Rester focus sur son objectif est une des valeurs de Scrum.

La DoR dans les équipes

Les équipes qui débutent dans l’agilité n’ont généralement pas de DoR, tout simplement car ce n’est pas évoqué dans le Scrum. Cela reste le framework le plus répandu notamment chez les équipes qui découvrent l’agilité.

En revanche, lorsque ces équipes gagnent en maturité, elles ont tendance à simplement créer une DoR basique ; ce qui leur permet de lister ce qui leur a manqué dans les itérations précédentes et qui de fait, a ralenti leur productivité.

Dans chaque équipe, les éléments qui composent la DoR peuvent être très différents. Un exemple qui est pour moi parlant : les maquettes.

Pour certaines équipes, les maquettes des IHMs à développer sont un élément nécessaire attendu avant de pouvoir commencer le développement. Pour d’autres, les maquettes sont des éléments qui font parties de la solution. Le fait de les fournir au démarrage, va limiter la créativité et orienter la solution. Par conséquent brider la créativité !

Au fur et à mesure des problèmes et des freins rencontrés, l’équipe va avoir tendance à enrichir sa DoR, jusqu’à obtenir une liste à rallonge…qui reprend alors tous les éléments qui leur a manqué.

Les contraintes

Plusieurs patterns apparaissent alors souvent :

La DoR n’est plus suivi puisqu’une partie importante des éléments qui la compose ne fait de sens qu’à une minorité des US. Nous avons ici la même réaction qu’avec des tests qui bagotent, nous ne tenons plus réellement compte de ce qui est affiché, c’est « rouge », mais c’est normal…

Deuxième pattern fréquent, vous avez un product owner particulièrement consciencieux qui va se démener pour respecter cette liste à chaque US, quitte à mettre plusieurs semaines, voire mois pour tous les rassembler, sans se soucier de leur pertinence ou de leur importance. Résultat, nous avons effectivement optimisé le cycle time mais le lead time a tendance à exploser, hors c’est bien cela qui est le plus important !

Les fondements

Revenons un peu aux fondements de l’agilité, dans le manifeste, il est écrit qu’il est préférable de valoriser « Les individus et leurs interactions plus que les processus et les outils ». Hors c’est bien ici que se situe le travers évoqué. La DoR utilisée comme outil vient se substituer aux échanges nécessaires entre l’équipe et le PO pour définir clarifier et partager le besoin.

L’étape de la conversation issue des 3 C de Ron Jeffries est indispensable à la fluidité du travail dans une équipe agile et ne peut en aucun cas être remplacée par un outil.

Pour travailler de façon fluide, l’équipe et le PO doivent partager les réponses à 3 questions :

• « Pourquoi ? », qu’est ce que l’utilisateur essaye de faire, quel est son objectif ? Dans quel contexte il essaye de faire cela ? Quelle est la valeur ajoutée pour lui ?
• « Quoi ? », comment est-ce que nous voulons répondre à ce besoin ? Quels sont les critères qui nous permettent de nous assurer que la user story réalisée a atteint l’objectif ?
• « Comment », quelle solution allons-nous implémenter ? Est-ce que cela va être compliqué ? Est-ce que nous pouvons redécouper en plusieurs US ? Quelles sont les contraintes techniques ?

Si nous sommes en mesure de répondre à ces 3 questions à l’issue de la conversation et que les réponses sont partagées et validées par l’ensemble de l’équipe ;  est-ce que la DoR nous apporte encore de la valeur ? Est-ce que cette conversation ne serait pas plus efficiente que la validation d’une liste d’éléments standardisés parfois sans valeur ajoutée ?

Ce qu’il fait retenir

Pour conclure, la DoR qui peut s’avérer nécessaire pour de nombreuses équipes n’est au final peut-être qu’un symptôme d’un manque de maturité. Elle n’est pas obligatoire, elle s’avére utile comme support de discussion entre l’équipe et le PO pour clarifier les user stories. Il faut garder en tête qu’elle peut entrainer des travers importants si nous essayons de la substituer aux échanges entre l’équipe et le product owner.

Et vous, parlez-nous de votre DoR ?

Léonard