Le développement agile est une exploration. En scrum, le sprint est un espace de temps pendant lequel nous explorons des solutions potentielles à un problème donné. Le résultat de cette exploration n’est pas toujours utilisable. Que faire ?
And in fact I used that phrase today in the talk at the HoA conference. I remembered your phrase at that moment and put in your word "exploration for feedback". :)). cheers
— Alistair Cockburn (@TotherAlistair) May 31, 2018
À la fin d’un sprint, nous levons la tête pour nous rendre compte de ce que sont devenu le produit et l’équipe, mais aussi de ce que nous avons appris.
Scrum n’a *aucune* deadline. #Scrum demande juste de définir des moments réguliers pendant lesquels on regarde ce qui a été fait.
Comment était le produit avant le sprint et comment il est maintenant.
Comment était l’équipe avant le sprint et comment il est maintenant.
— Constantin Guay (@cog_g) June 22, 2018
Que se passe-t-il pour ce que nous venons de réaliser pendant le sprint (l’incrément) ?
1/ L’incrément ne correspond pas au besoin de l’utilisateur
Que faire si ce que nous venons de réaliser n’est pas vraiment ce que l’utilisateur avait en tête, ou que ça correspond bien à ce qui était voulu, mais que la solution, une fois dans les mains de l’utilisateur, ne règle pas son problème ?
2/ L’incrément n’a plus lieu d’être
Il est aussi possible que le temps que la fonctionnalité soit prête, le marché ait changé brutalement et que l’incrément n’ait plus de valeur.
3/ L’incrément correspond au besoin de l’utilisateur, mais…
C’est le meilleurs des cas. Ce que nous venons de réaliser est pertinent.
Pourtant, il se peut que le nouvel incrément rende une autre partie du produit obsolète.
Doit-on dépenser pour jeter ?
Jeter a un coût, mais garder aussi
Nous devons dépenser du temps pendant un sprint pour nous détacher de la partie du produit devenue obsolète et cela peut-être assez difficile dans certains contextes.
On crée alors de la dette technique, qu’il est indispensable de visualiser.
C’est néanmoins essentiel, tant ces bouts de code deviennent contagieux avec le temps qui passe.
Il faut savoir ne pas déployer et jeter une branche, voire revenir à l’état précédent du produit.
Plus le temps passe, plus le coût de la séparation de cette partie du produit devient importante.
L’équipe doit en prendre conscience
Il n’est pas simple pour un artisan de se débarrasser de sa création.
Imaginez-vous dire à un sculpteur, fier de son travail qu’il vous rends : “ça ne me sert plus, j’en veux pas, jette-le”. Quelle sera sa réaction à votre avis ?
Il est donc important de travailler sur cette capacité de l’équipe à se détacher et à comprendre que garder un travail pour le seul principe de “on l’a fait, on ne va pas le jeter”, est néfaste pour le produit et pour l’équipe.
(surtout qu’en développement, jeter n’est pas définitif grâce au versioning)
Dès que l’on se rend compte que ce qu’on fait ou que ce qu’on a fait n’a plus de sens, je recommande de s’en débarrasser rapidement.
Le travail du Scrum Master est de faire passer ce message au plus tôt, surtout aux développeurs les plus juniors.
(Photo by James Pond on Unsplash)