Sprints synchronisés façon puzzle

Dans l'atelier Puzzle grand Scrum dont je parlais dans mon dernier billet, il y a donc 3 équipes qui concourent à la réalisation du puzzle. Le format du jeu pousse les équipes à se caler sur le même rythme.

C'est à dire que toutes les équipes commencent et finissent le sprint en même temps.

Avec les mises en œuvre de Scrum multi-équipes que j'accompagne, c'est ainsi que ça se passe, je pense notamment à Intel et Airbus.

Au cours de la quinzaine d'ateliers "puzzle" que j'ai animés, jamais personne n'a émis une proposition différente, des sprints décalés, qui serait par exemple : l'équipe bleue commence puis au bout du tiers du sprint, l'équipe verte commence, et aux deux tiers l'équipe rouge commence.

Dans mon livre édition 4, chapitre 21 "Développer des produits à plusieurs équipes", je ne présente pas d'alternative à la synchronisation des sprints pour du Scrum multi-équipes (§21.2.1). Je mets en avant l'intérêt de l'intégration fréquente entre les équipes pour cette approche.

Une discussion avec Pablo[1] lors du dernier Raid Agile m'a fait percevoir que cet argument n'était pas décisif : on peut aussi intégrer régulièrement si les sprints ne sont pas synchronisés.

Un intérêt plus évident est que cela facilite la tenue des événements du sprint[2]. Il est bien mis en évidence par l'atelier, en particulier pour l'organisation de la revue avec les parties prenantes. L'affinage multi-équipes cadencé est aussi facilité par la synchronisation des sprints.

Dans le chapitre 15 de Scrum et XP depuis les tranchées, Henrik Kniberg raconte qu'il avait d'abord expérimenté les sprints désynchronisés, avant d'être convaincu par Ken Schwaber de les synchroniser.

En plus des arguments évoqués, Kniberg évoque aussi la réorganisation des équipes, faisable en cas de sprints synchronisés, mais qu'il est probablement plus raisonnable de repousser en fin de release.

Notes

[1] Pablo, un partisan revendiqué des sprints multi-équipes désynchronisés.

[2] Dans mon livre, je fournis un tableau récapitulatif des événements du sprint à plusieurs équipes, page 277.

Glossaire R-S

couverture Scrum éd.4

Dans l'édition 4 de mon livre, j'ai ajouté un glossaire. C'est une des nombreuses nouveautés.

Lire la suite...

Jour de fin de sprint

Résultat de mon enquête sur votre jour de la semaine pour finir un sprint.

Lire la suite...

Durée des sprints en 2015

Une majorité — relative — d'entre vous effectue des sprints de 2 semaines.

Lire la suite...

Les événements du sprint

Les événements du sprint

Bien sûr, il faut ajouter un événement à ceux de ce schéma : le scrum quotidien.

Lire la suite...

Engagement de sprint à l'usage des honnêtes gens

L'engagement est une valeur de Scrum. L'équipe est invitée à s'engager lors de la planification de sprint. Je constate que cette notion reste souvent mal comprise.

Voici quelques éclaircissements, qui s'appuient sur ma dernière lecture.

Lire la suite...

Limiter le bac de sprint

Lors de la planification de sprint, l'équipe se met d'accord avec le Product Owner sur une liste de stories. Elle identifie le travail à faire pour réaliser ces stories, travail qui est enregistré sous forme de tâches.

Cela présente l'avantage de permettre à l'équipe de connaitre l'ensemble des travaux attendus pour le sprint. Mais cela ne facilite pas la prise en compte des changements pendant le sprint. Il est parfois nécessaire, sans changer le but du sprint, de prendre en compte des travaux non prévus au début du sprint.

Lire la suite...

Chapitre sept

Dans la série Suppléments en ligne de mon livre Scrum, voici la réunion de planification de sprint, qui constitue le chapitre 7.

Ce chapitre fait partie de ceux que j'ai réécrits pour l'édition 3.

Lire la suite...

Scrum Guide 2013 et pablotages

Ken Schwaber et Jeff Sutherland, les fondateurs de Scrum, ont mis à jour le Scrum Guide. Pablo en a fait son décodage.

Lire la suite...

Chapitre deux

Des sprints pour une release.

Lire la suite...

- page 1 de 5