Perturbations pendant le sprint

En principe une équipe ne devrait pas être perturbée pendant un sprint par du travail à faire suite à des évènements qui surviennent pendant le sprint. Pas toujours possible...

Quand une équipe Scrum travaille sur un projet qui a déjà produit une release, il arrive que pendant le sprint courant, une anomalie détectée sur la release en production nécessite une correction urgente. Pas possible d'attendre le sprint suivant [1]: il faut faire quelque chose (au moins corriger l'anomalie) pendant le sprint courant. C'est évidemment perturbant pour l'équipe mais inévitable dans certains environnements.

Sachant que ça peut arriver, une solution est de prendre ses précautions. C'est le cas de l'équipe pour laquelle je fais une formation actuellement. Elle prévoit un pourcentage de temps dédié[2] à ces travaux intempestifs[3] et en tient compte dans l'engagement qu'elle prend au début du sprint pour réaliser des éléments du backlog. Il est donc essentiel que le pourcentage alloué ne soit pas dépassé, sinon les engagements n'ont plus de sens et cela ne peut que démoraliser l'équipe. L'inconvénient de cette solution est qu'elle réserve du temps que l'équipe aura tendance à utiliser pour la maintenance en général et pas uniquement pour des choses urgentes. Elle oblige également à compter le temps passé sur ces travaux pour ne pas dépasser le plafond. De plus il n'est jamais sûr que ce plafond ne soit pas inadéquat dans un sprint où il y aura beaucoup d'urgences.

Une autre solution est de gérer un évènement dans le sprint courant de la même façon qu'on gère l'arrivée d'une nouvelle exigence dans le backlog de produit dans le cas d'une release à date fixée :

  • l'équipe ne réserve rien pour les urgences possibles
  • si une demande urgente arrive pendant le sprint, elle est communiquée exclusivement au ScrumMaster[4]
  • celui-ci réunit l'équipe [5] pour qu'elle identifie et estime les tâches liées à la prise en compte de la demande
  • il communique ces estimations au demandeur
  • le demandeur est chargé de négocier avec le directeur produit pour retirer des tâches du backlog de sprint d'un montant équivalent à celles estimées par l'équipe pour prendre en compte la demande urgente
  • le backlog de sprint est remis à jour[6]
  • la vélocité s'en trouvera affectée[7], mais c'est normal car cela permettra de tenir compte de ce phénomène pour la planification de la release

Notes

[1] même avec des itérations très courtes

[2] 40%

[3] pas seulement dus à des anomalies mais aussi induits par des évolutions sur d'autres sous-systèmes

[4] pour qu'il filtre éventuellement

[5] de façon exceptionnelle si c'est particulièrement urgent, sinon il profite du scrum quotidien

[6] si la négociation aboutit...

[7] parce que les tâches retirées contribuaient à des story points

Commentaires

1. Le vendredi 20 avril 2007, 12:02 par sylvek

les pertubations externes surtout dû à des bugs P1 sont fréquentes dans ma boite (editeur de logiciel). Il est vrai que ce n'est pas toujours facile d'équilibrer judicieusement (cf. motivation etc.) les bugs, les évolutions et surtout les ressources disponibles. Le risque à éviter c'est de perturber de trop les ingénieurs juste en se renseignant sur les bugs P1. Mais tout en l'incluant dans la prise de décision concernant le délai et la solution à mettre en place... pas simple!