Pourquoi ne jamais reporter la fin d'un sprint ?

Pourquoi ne jamais reporter la fin d'un sprint ?

Quel coach agile n’a pas entendu cette question : "Euh…​ on arrive à la fin du sprint, et on n’a rien à montrer. Est-ce qu’on peut reporter la date de fin ?"
Pas toujours facile d’y répondre correctement ! Il faut comprendre que cela indique plusieurs problèmes et empêche l’émergence de solutions. Voici quelques armes pour répondre à cette question.


En théorie :

Selon notre cher cadre SCRUM, le sprint possède une durée fixe et il n’est pas envisageable de le rallonger parce qu’on ne va pas le terminer.

La récurrence des divers évenements permet à tous les acteurs de s’y retrouver et d’être prédictibles. Les parties prenantes sauront à quelle date a lieu la Revue, tant que l’équipe existe, et pourront bloquer le point.

Pour l’équipe, cela permet d’avoir le temps de s’inspecter. S’il est posé la question du report de la fin du sprint, il apparait très clairement que l’équipe n’est pas forcément familière avec le droit à l’erreur, mais aussi qu’elle a vraiment besoin de s’inspecter !
Finalement, ne pas avoir de démo à présenter est plutôt une bonne façon de mesurer la qualité de votre revue ! Il viendra peut-être un article sur le sujet prochainement…​


En pratique :

Cet article fait suite à une expérience lors d’un atelier :
Lors de l’animation d’un Minecraft4Scrum (équivalent à Lego4scrum, sur Minecraft), récemment, une réflexion assez pertinente s’est posée devant moi.
La timebox de l’itération était fixée à 45min et j’incitais les étudiants à poser un maximum de questions au PO en sprint planning.

Après 40 minutes de sprint planning, ils commencent ENFIN à produire ! Malheureusement, 5 minutes plus tard le timer de fin de sprint sonne. La décision fut dure à prendre : Dois-je risquer de frustrer tout le monde et arrêter le sprint ?
C’est mon collègue Constantin Guay qui m’a incité à le faire. A vrai dire, c’était plutôt une réussite !

Les participants étaient frustrés, certes, mais la revue a été utilisée pour mettre en évidence les problèmes qui avaient empêché le bon déroulement de la production. La rétrospective a permis d’identifier divers points qui permettraient d’accélérer le sprint planning et de se lancer plus vite dans la production.

Nous sommes repartis sur le 3ème sprint avec un sprint planning très court et nous avons doublé notre vélocité !

Par ailleurs, cela m’a permis d’introduire la notion de droit à l’erreur, plutôt contre-intuitive. Cela ne pose pas de problème de faire des erreurs, si on est capable d’en apprendre et de ne pas les reproduire !


Quelle conclusion en tirer ?

Bien sûr, ça fait peur quand on arrive au bout d’un sprint et qu’on n’est pas prêt pour finir. Mais ce n’est pas si grave !

En tant que coach, il est important de profiter de ces moments pour entrer dans des réflexions profondes et fondamentales.

Etoile Talan
Avatar Martin Scher

Martin Scher

Scrum Master

comments powered by Disqus