Ce que « fini » veut dire.

Introduction 

Vous vous êtes peut être retrouvé dans une situation similaire à celle qui suit:

En bref, vous vous rendez certainement compte que dire qu’une tâche est terminée ou “done” ne signifie pas forcément la même chose pour tout le monde. 

Ici, nous pouvons parler de problème de transparence car ce que l’on dit au sujet de l’incrément ne correspond pas à ce qui est livré. 

La transparence, un des 3 piliers de Scrum, est une notion essentielle qui, si elle n’existe pas au sein de votre projet, vous empêchera de tirer un quelconque bénéfice de Scrum (ou de toute autre méthode/framework/pratique par ailleurs). 

Sans transparence, pas d’Inspection ou d’Adaptation possible.

La “Definition of Done” (DoD) ou “Définition de fini” participe à l’engagement de transparence que prend l’équipe. Nous allons parcourir ce qu’elle est et à quoi elle sert concrètement.

La DoD : un standard de qualité

La DoD doit tout d’abord être vue comme un standard “minimal” de qualité à respecter obligatoirement. Autrement dit, si un morceau de code ne respecte pas ce qui a été défini dans la DoD, il ne pourra pas faire parti de l’incrément, ne pourra pas être livré, ni présenté à la Sprint Review, on dit alors qu’il ne sera pas “done” (fini).

Bien que l’incrément aura tendance à grossir au fur et à mesure des sprints, agrégeant toujours plus de fonctionnalités, la DoD, elle, restera constante, à n’importe quel moment du projet, quelque soit les personnes intervenant sur le projet. On pourra même parler de normalisation de la qualité au sein du projet.

La forme et le niveau de détail

Quelle forme doit prendre la DoD ? Il n’y a rien de spécifié dans le scrum guide, la seule exigence étant que tout le monde doit comprendre la même chose.

En règle générale, il s’agit d’une liste des choses à faire, de points à vérifier avant de considérer une fonctionnalité comme finie.

La compréhension de la DoD doit être partagée, et pour que cela soit le cas, en règle générale plus une équipe sera jeune, plus la DoD sera exhaustive. A contrario, les équipes expérimentées, dont les membres ont l’habitude de travailler ensemble, auront tendance à utiliser des termes plus généraux. 

Définition de la DoD

Le process de production de la DoD

Comment faire en sorte qu’un PO qui est fonctionnel et une équipe de développement qui est technique se comprennent.

Le Scrum Master va d’abord expliquer la théorie et accompagner l’équipe en expliquant ce qu’est la DoD et son intérêt. En somme, il va “vendre” la DoD à l’équipe.

Le PO va expliquer ce qu’il attend, à savoir le niveau de qualité et l’état de l’incrément lorsque l’équipe de développement dira “on a fini”. Souvent, le PO décrira les problèmes rencontrés dans le passé et demandera aux développeurs de s’assurer d’une phase empêchant ces soucis de se reproduire.

Les développeurs décident des tâches à effectuer pour atteindre ce niveau de qualité et la matérialisent en une liste compréhensible, la DoD.

Évidemment, plus le standard de qualité demandé sera haut, plus il y aura de contrôles à faire ou des tâches à effectuer, plus cela prendra du temps, et donc, de l’argent. Il faudra que l’équipe trouve le bon équilibre entre qualité, coût et rapidité de livraison, souvent en automatisation les tests dès que cela est possible.

La discussion autour de la DoD devra se poursuivre jusqu’à ce que l’équipe dans son intégralité la comprenne et l’accepte.

En somme:

• Le Scrum Master enseigne l’intérêt de la DoD, il peut suggérer quelques bonnes pratiques 
• Le PO explique ses besoins de qualité vis à vis de son client/ses utilisateurs
• Les développeurs produisent la DoD et se plient à toutes les actions nécessaires pour la respecter et produire un incrément de qualité

La DoD représente alors un contrat entre les Développeurs et le PO

Le PO faisant confiance à la DoD certifiée par les développeurs, il pourra (et devrait) utiliser cette DoD comme gage de la qualité livrée

Quand définit-on la DoD?

Le plus tôt possible dans le projet, à savoir, dès que le périmètre du projet est expliqué et compris, et que les outils et les technologies ont été sélectionnés.

Attendre trop longtemps avant de produire la DoD représente un risque quant à la qualité produite pendant cette période, en y ajoutant que ce qui sera produit pendant cette période représentera une dette technique à rembourser.

La DoD au cours du projet

Une fois comprise, l’utilisation de la DoD au cours du projet est alors très simple et directe. Nous avons 2 cas:

Le premier cas, le cas idéal, dans lequel l’équipe de développement produit une fonctionnalité qui passe les contrôles imposés par la DoD. La fonctionnalité peut alors être considérée comme “done”. Un nouvel incrément est créé qui pourra être présenté à la Sprint Review. Il est possible d’aller plus loin bien sûr en livrant en production par exemple, mais on sort alors du cadre imposé par Scrum.

Dans le 2ème cas, la fonctionnalité ne passe pas la DoD. Scrum est assez direct dans ce cas, l’élément retourne dans le backlog et ne pourra pas être présenté à la Sprint Review. Ce qui est tout à fait légitime à la fin du Sprint. Cela dit, si le Sprint est toujours en cours, il sera plus logique de le renvoyer à l’équipe de développement pour entamer les corrections nécessaires.

Modification de la DoD

Au cours d’un projet, il sera peut être nécessaire, au vu de ce qui est observé, de modifier la DoD. Bien qu’il ne soit pas obligatoire d’attendre la rétrospective pour modifier la DoD, s’agissant de l’événement centré sur la manière de travailler de l’équipe, la qualité et l’efficacité de celle-ci, elle est le moment privilégié pour le faire.

Comme vu précédemment, la DoD est fixe, hors il s’agit ici d’être agile, et si le besoin se fait sentir de la modifier, on devra la modifier. Peut être que la liste définie n’est pas suffisante, ou au contraire que l’on se rend compte que certains points sont superflus et handicapent la capacité de l’équipe à délivrer de la valeur, d’autres n’ont plus d’intérêt… Il se peut aussi que la DoD soit mal comprise d’où la nécessité de sa revue.

Quelque soit les modifications apportées à la DoD, l’équipe devra désormais respecter cette dernière version. 

La modification de la DoD ne pose pas vraiment de problème en soi, mais elle peut avoir des répercussions loin d’être anodines.

Dans le cas de la suppression d’un élément dans la liste, l’équipe ne devra plus se soumettre à ce point sans autre conséquence.

Dans le cas d’un ajout par contre, cela aura une incidence bien plus importante. Comme dit précédemment, la DoD est un standard de qualité constant et cela sous-entend que tout ce qui a déjà été livré doit aussi respecter ce standard. On pourra alors considérer que tout le travail fourni jusque là n’est plus “done”.

L’exemple le plus simple est la documentation des fonctionnalités. Si jusque-là, la documentation ne faisait pas partie du standard, le fait qu’elle le devienne obligera l’équipe à écrire la documentation pour toutes ces fonctionnalités livrées… pas simple !

Pratiques pour suivre la DoD

Comment faire pour que l’engagement de l’équipe à suivre la DOD se maintienne dans le temps?

A l’époque ou le présentiel était la norme, on pouvait mettre en place des actions simples comme:

• imprimer la DoD et l’afficher à la vue de tous
• Remettre le focus en demandant si la DoD était toujours respectée et pertinente

Autant il est encore possible de faire ces actions, il est moins acceptable d’afficher la DoD dans son salon. Il faut donc s’adapter aux nouvelles contraintes et mettre en place des pratiques à distance.

Mon conseil serait de suivre les pratiques de Kanban en général et la visualisation du flux de travail (workflow) en particulier: comme chaque tâche spécifiée dans la DoD est une étape à compléter il est tout à fait logique de refléter votre DoD dans un tableau (Jira ou autre); il sera difficile d’oublier quelque chose affiché devant vos yeux.

Ce sont ici des exemples mais d’autres pratiques sont possibles.

L’équipe choisit de ne pas respecter la DoD

A partir du moment où l’équipe de développement définit sa propre DoD et choisit de ne pas la suivre, le Scrum Master aura certainement une action à entreprendre, je vous propose d’ailleurs cela en tant qu’ atelier à mener au sein de votre équipe/entreprise

En reprenant la théorie citée précédemment, demandez quels seraient les effets entre les différentes personnes intervenant au sein du projet, cela pouvant inclure les membres de l’équipe Scrum, le client, les utilisateurs, les sponsors, managers et autres parties prenantes.

Former des groupes de 4 personnes et lancer un 1-2-4-All (vous pouvez bien évidemment adapter les temps au besoin ou plus simplement former des groupes de discussion)

• Chaque personne réfléchit à la question pendant 1 minute
• Des paires se forment et chacun échange ses idées avec l’autre pendant 2 minutes
• Les paires se regroupent pour faire des groupes de 4 afin de partager et d’établir une hiérarchie des idées ayant le plus d’intérêt.
• Un débrief général est fait et chaque groupe partage ses idées.

Une petite idée de ce que cela peut produire avec le schéma ci-dessous: 

C’est une pente très glissante car un scénario comme celui-ci montre que l’équipe ne s’est pas appropriée les valeurs de Scrum, en particulier, de courage, d’engagement et de respect. La transparence n’étant pas au rendez-vous,  la confiance entre les parties prenantes sera immédiatement entachée… Avec toutes les conséquences possibles que vous pourrez discuter.

N’hésitez pas à challenger les participants sur le pourquoi du non respect de la DoD, par exemple:

• Qu’est ce que cela apporte ou détruit 
• Qui pousse à aller dans ce sens
• Que cherche t’on à faire au sein du projet 

et décider des actions à mettre en place si besoin.

Conclusion

La DoD est un outil puissant pour mettre en place une responsabilisation de l’équipe de développement, qui s’engage elle-même dans une démarche de qualité. 

Respecter la DoD est une preuve de sérieux de l’équipe qui mérite qu’on lui fasse confiance. 

Il arrive que l’on modifie la DoD, si besoin est, mais on essaiera de ne pas le faire au vue des conséquences que cela peut engendrer.

En revanche, écrire une DoD et ne pas la suivre est le pire que l’on puisse faire dans l’équipe, car dans ce cas on fait clairement preuve de malhonnêteté intellectuelle vis-à- vis du PO et du client.

N’hésitez pas à vous saisir de ce sujet, discutez-en et voyez ce que cela peut apporter dans votre équipe, votre organisation.

Remarques

Le Scrum guide fait référence aux  “developers” et non pas à une équipe de développement. 

Certaines références ont été volontairement modifiées afin de coller à des situations concrètes et de  se focaliser uniquement sur la Definition of Done.

Envie d’en savoir plus?

Contactez-moi pour en savoir plus.