English version published on Scrum.org website.

Il y a quelques jours, j’observais une Sprint Rétrospective. L’équipe Scrum a décidé de travailler sur la définition de “Done” (DoD), identifiée comme le sujet le plus important à adapter pour le prochain sprint. Les discussions étaient ouvertes et animées. Puis, une conversation inattendue a émergé au cours de la session.

Deux nouveaux développeurs ont récemment rejoint la DevTeam, composée de cinq personnes. La croissance de l’équipe a changé la dynamique, ajoutant de la complexité et la nécessité d’une révision de la définition de “Done”.

Le Scrum Master a invité le Product Owner et la DevTeam à générer des idées pour la DoD. Après quelques minutes, de nombreux post-its ont été proposés et partagés dont certains plus détaillés et d’autres moins.  La discussion s’est ensuite figée au niveau la documentation, notamment à des fins de test.

La question qui s’est posée : à quel point la DoD devrait-elle être précise et détaillée ? Devrions-nous être spécifiques, par exemple: “tests de non-régression documentés, validés par un paire, exécutés et le résultat stocké dans le dossier XY”. Devrions-nous simplement nous contenter d’une phrase comme: “tests de non-régression” ?

La réponse à cette question ?  La décision prise par le Product Owner et la DevTeam ensemble est acceptable, améliorée continuellement par l’inspection et l’adaptation.

C’est à ce moment-là qu’une nouvelle discussion s’entame entre les membres de la DevTeam : l’un d’eux arguant que le seul fait d’écrire des “tests de non régression” ne garantirait pas que le collègue effectuait des tests “de qualité” et “assez” significatifs. Il aurait simplement pu faire quelque chose pour se débarrasser du test et passer au suivant.

Un son de cloche sonne alors dans ma tête. Un néon rouge avec les lettres “C O N F I A N C E” commence à clignoter aussi… (oui, des choses étranges se passent, parfois, dans mon cerveau :-))

Partant de l’hypothèse que la DevTeam est un groupe de professionnels qui s’auto-organise pour créer un incrément “Done” à la fin de chaque sprint, s’ils ne parviennent pas à s’entendre sur un DoD et utilisent des expressions du type “comment puis-je savoir si vous avez réellement fait un bon test ?”, le souci repose fort probablement sur la confiance accordée au travail des autres.

J’ai validé mon hypothèse en posant quelques questions ouvertes. Maintenant, je sais que je dois aider la DevTeam à rétablir la confiance pour qu’elle redevienne efficace. Ce qui a commencé comme une simple discussion sur la définition de « Done » a finalement révélé un autre problème : le manque de confiance entre les membres de la DevTeam.

Je suis convaincu que cette équipe surmontera ses difficultés et redeviendra rapidement une DevTeam très performante !

À retenir

• Vérifiez le niveau de confiance, à tout moment. C’est souvent LE problème. Vous pouvez consulter mon article “Un atelier pour découvrir les valeurs Scrum” pour vous donner des idées.
• Les changements dans la composition des équipes peuvent en affecter la productivité, lisez les étapes de développement du groupe de Tuckmanpour en savoir plus.
• Apprenez à cerner le problème, en vérifiant le sujet en question, le comportement des personnes, leur formulation et leur langage corporel.
• Tenez-vous en au Guide Scrumet aux règles du jeu (surtout si vous êtes moins expérimenté) à maintes reprises, c’est le point de départ de mes explications.