la justification pour une durée de Sprint maximale de 30 Jours

Trucs et astuces pour que le travail soit fait… sur PMI Agile CoP blog

Quelle est la justification pour une durée de sprint maximale de 30 jours?

C’était une question posée par quelqu’un sur le groupe LinkedIn des ScrumMasters : LinkedIn Certified ScrumMasters group.

Il y a trois raisons. Deux font explicitement partie de Scrum. L’autre n’est pas mentionnée, mais est une des fondations de Scrum. Les explicites sont le retour d’information rapide et le renforcement de la vue réaliste. La troisième est la suppression des retards.

Retour d’information rapide

30 joursVous voulez un retour d’information rapide. Attendre plus de 30 jours pour ce retour d’information ne vous donne pas assez rapidement ce retour d’information.

Quel genre de retour d’information ? Un retour d’information qui vous permette d’apprendre rapidement. Le retour d’information vient sous bien des formes. Il y a le temps entre la réception d’une demande jusqu’à sa livraison et le temps de commencer une histoire jusqu’à ce qu’elle soit complète. Mais vous n’avez pas à écrire tout le code pour découvrir que le client n’en veut pas. Au lieu de cela, vous voulez écrire un peu de code sur les histoires dont le client a une compréhension claire. Montrer une partie de la fonctionnalité à un client nous permet d’en apprendre davantage sur le reste de ce qu’ils veulent.

J’entends souvent « échouez vite » comme raison. Je préférerais personnellement apprenez vite. Si je dois échouer, je voudrais le faire rapidement. Mais mon objectif est d’apprendre pas d’échouer.

Renforcement de la vue réaliste

Avec « renforcement de la vue réaliste », je veux dire que seule la fin d’un sprint nous dira où nous en sommes de manière objective, non subjective. Si le test n’est pas fini,  sprint n’est pas fini. La raison est probablement un obstacle dans notre processus. Sans dates rigides, fixes, il est facile de rationaliser pourquoi nous n’avons pas accompli ce que nous voulions. Des obstacles usuels sont que les clients peuvent ne pas vouloir vous parler, que les processus de développement sont peut-être inefficaces, que les évaluations et le développement du code sont trop éloignés. En ayant une période déterminée de temps dans laquelle votre travail doit être achevé avec le timeboxing du sprint, ces choses qui travaillent à votre encontre deviendront plus visibles et douloureuses. Ce sont dans les faits des obstacles à votre travail et au lieu de les éviter en rallongeant le sprint, vous devez en réalité raccourcir le sprint pour les mettre encore plus en évidence. Il sera aussi plus difficile de les ignorer : si vous n’avez pas testé votre code à la fin du sprint, ce sera évident et irréfutable.

Ces deux raisons ont en réalité tendance à inciter à des sprints encore plus courts que 30 jours. La plupart des équipes Scrum qui réussissent et que je connaisse utilisent des sprints d’une ou deux semaines. En fait, j’irais jusqu’à dire que des équipes avec des sprints de trois ou quatre semaines indiquent une tendance à ne pas être pas suffisamment engagées dans la résolution de leurs problèmes. Ceci n’est pas toujours vrai, mais c’est assez souvent le cas.

suppression des retards

La troisième raison, qui par beaucoup d’aspects est la plus grande, est d’éliminer les retards.

Depuis 2004, j’ai clamé que Scrum est une faible mise en œuvre des principes Lean. Je dis « faible » parce que Scrum ne se préoccupe pas de l’optimisation de la totalité du processus, Scrum se concentre sur l’équipe de développement et délaisse une grande partie de l’éducation et du management Lean. Mais un des principes clés de Lean est d’éliminer les retards afin que la valeur puisse peut être délivrée rapidement. Ceci est critique parce que chaque délai entre étapes de travail crée littéralement plus de travail.

Note : Pour plus détails, voir sur Net Objectives: Lightning Webinar, The Real Tenets of Lean: Avoid Creating Waste by Eliminating Delays.

Le timeboxing dans Scrum exige que les équipes complètent leur travail rapidement, et encourage aussi à élaguer. Ceci réduit les retards et évite donc de faire un travail qui ne devrait pas être nécessaire.

La combinaison du retour d’information rapide, du renforcement de la vue réaliste et de la suppression des retards nous permet d’avoir des boucles de retour d’information de plus en plus brèves jusqu’à ce que tous les frais généraux du sprint, les « overhead », dépassent la valeur qu’ils sont censés apporter. Pour la plupart des équipes ce sera une ou deux semaines. Quelques équipes découvriront qu’elles n’ont pas besoin de la discipline du timeboxing et l’abandonneront complètement et pour passer sur Kanban.

Une réflexion sur “la justification pour une durée de Sprint maximale de 30 Jours

  1. Ping : Des délais à respecter ? Utilisez les blocs de temps ! par Jeff Ball | DantotsuPM.com

n'hésitez pas à commenter les billets et à partager vos idées.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.