La remarque
Récemment, je participais à une rétrospective avec une équipe qui est mature en termes d’auto-organisation et de collaboration. Cependant, alors que j’abordais le sujet de la Définition de terminé, l’un des participants a glissé cette phrase :
« Si on suit notre “définition de terminé” à la lettre… on va tripler nos temps de développement… Je comprends que c’est important, mais nous n’avons pas ce temps à disposition. »
La rétrospective touchait à sa fin et je n’ai pas pu approfondir la question sur le moment. Il me semble cependant important de revenir sur ce sujet qui est fondamental dans Scrum.
Le temps
Oui, effectivement, je pense que le temps de développement sera plus long si la Définition de terminé construite par l’équipe de développement est appliquée consciencieusement pour chaque élément du Sprint Backlog et pour l’incrément lui-même.
- Développer des tests prendra toujours plus de temps que de ne pas en développer.
- Écrire de la documentation prendra toujours plus de temps que de ne pas en écrire.
- Tester systématiquement sur toutes les plateformes prendra toujours plus de temps que seulement en local.
- etc., etc.
Je comprends que cela fasse peur et peut-être décourage certains, car nous sommes des personnes dévouées à notre travail et nous aimerions toujours pouvoir être les plus efficaces et rapides possible en livrant plus de valeur à notre client.
Le calcul
La question rhétorique que je me pose est celle-ci : est-ce vraiment le meilleur calcul? L’efficacité à court terme ne coûte-t-elle pas plus cher au final? Est-ce que revenir incessamment sur une fonctionnalité pendant des semaines, voire des mois, pour corriger des bogues est vraiment gratifiant?
Lors de cette même rétrospective et des précédentes, nous avons parlé de certains sujets récurrents. L’un de ces sujets était : « Comment faciliter l’arrivée d’un nouveau membre dans l’équipe ? » et en parallèle : « Comment travailler de manière constante et homogène sur le même produit avec plusieurs équipes de développement ? »
En réponse à ces questions, une amélioration de la documentation a été imaginée. Amélioration, car une documentation avait été commencée il y a quelques mois et n’avait pas été mise à jour… alors que le point « écrire la documentation » était présent dans la Définition de terminé de l’équipe. L’équipe devait donc à présent reprendre la documentation, lister les pages manquantes et les écrire.
Un autre sujet était « Pourquoi un sprint de stabilisation a-t-il été nécessaire avant de mettre en production ? » Le sprint de stabilisation a consisté à corriger des bogues, effectuer des tests de base sur les différentes plateformes et aussi des tests plus poussés. Pourtant, dans la définition de terminé, il y avait plusieurs points qui parlaient de tests (unitaires, fonctionnels et sur toutes les plateformes et en particulier sur les plateformes mobiles).
Un autre point qu’il ne faut pas oublier : une définition de terminé se travaille, elle s’améliore et se complète au fur et à mesure.
Le pourquoi
Avec ces quelques exemples, je vois de multiples raisons de prendre en compte la définition de terminé immédiatement lors du développement et non pas après coup en rattrapant la dette technique. Les raisons qui me viennent à l’esprit sont les suivantes :
- Qualité technique
- Confiance des clients
- Confiance des parties prenantes
- Transparence sur le travail livré
- Livrer de la valeur plutôt que de corriger des bogues
- Travail moins rébarbatif (plus agréable de faire un peu de docs par-ci par-là que de rattraper la documentation manquante en bloc)
- Sentiment d’aller de l’avant plutôt que de reculer ou ressasser
- Meilleure visibilité du reste à faire
- Meilleur calcul de la vélocité (avec moins de dette technique et une vraie notion de terminé)
N’oublions pas qu’en tant qu’équipes Scrum, nous livrons à chaque fin de sprint un incrément terminé potentiellement livrable en tout temps. C’est le respect de la définition de terminé qui nous permet de garantir cela.
Et vous ? Qu’en pensez-vous ? Voyez-vous d’autres raisons d’appliquer la définition de terminé ?
Pour aller plus loin
Quelques articles du blogue Savoir Agile au sujet de la dette technique, de la transparence et de la vélocité :
Pas de commentaire