Qu’est ce que le canal du midi a à voir avec l’agilité?
Ce sont les écluses, qui régulent le trafic. Comme les sprints d’une release.
Entre deux écluses, pas plus de bateaux que la capacité possible.
Vous allez me dire, sans écluses plus de fluidité. Dans certain cas, oui, mais elle ne serait plus contrôlée, et l’on arriverait vite à saturation.
Je vous renvoie à la métaphore de
l’autoroute par Alexandre Boutin : à 80% de capacité, l’autoroute est saturée, les bouchons commencent à se former, et le cycle est en accordéon.
Il est souvent difficile de choisir la taille d’un sprint, de 2 à 4 semaines.
J’ai même fait des sprints d’une semaine, sur des projets en phase de correction de bugs.
Lorsque l’équipe est trop grande, plus de 6 personnes, et les sprints trop longs, 4 semaines, il est difficile d’effectuer un planning meeting sur 1 journée seulement. Il y trop de user stories à étudier et donc trop de tâches à identifier, détailler et chiffrer. La visibilité d’un sprint est liée à la capacité et la taille du sprint.
Un sprint de
4 semaines avec une équipe de 10 personnes, soit 10 * 20 * 8h = 1600h.
A 4,5h (entre 1 et 8) en moyenne par tâche, Il faut donc identifier
355 tâches. C’est trop pour notre petit cerveau.
Je privilégie maintenant des sprints de 2 semaines.
Un sprint de
2 semaines et des équipes plus petites permettent de répartir la vélocité dans le temps. D’avoir une capacité ayant un niveau d’appréhension plus aisée. Cela facilité le calcul du reste à faire et permet de réellement bloquer le contenu d’un sprint, sans trop retarder la prise en compte des changements ou des « urgences ».
1 équipe de 5 en 2 semaines : 5 * 10 * 8 = 400h, soit
88 tâches. Beaucoup plus tangible.
Le nombre de tâche par sprint peut s’apparenter à la sensibilité qu'a notre cerveau à appréhender, comprendre, assimiler et visualiser dans le temps.
La sensibilité d’un sprint est le nombre de tâches qu’une équipe peut « comprendre ». Elle est la dérivée de la vélocité sur le sprint.
