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é :

Billet précédent

User Story Mapping, Trello et autres outils pour organiser son mariage

Billet suivant

Le temps juste (tempo giusto)

Sabrina Ferlisi

En 2014, après un master d’ingénieur en informatique et des années dans le développement logiciel et la gestion de projet, Sabrina tombe dans la marmite de l’Agilité en tant que Scrum Master et découvre un nouveau monde. Depuis, elle est passionnée par tout ce qui touche aux interactions humaines, à la communication et à l’amélioration continue.

Énergique, intuitive et organisée, elle met son savoir-faire au service des équipes et des organisations en donnant à la fois un cadre et de la souplesse aux environnements complexes.

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.