Flux dans le sprint et engagement

Suite à la lecture de mon billet Scrum3.0, Eric se demande, à propos du sprint en flux continu :

Le flux continu remet en cause le principe "pas de changement pendant un sprint". Comment permettre à l'équipe de s'engager dans ce mode de fonctionnement ? Au jour le jour ? Ou est-ce que ce mode de fonctionnement est réservé à des équipes qui ont dépassé le stade de la nécessité de s'engager ?

Je réponds à Eric :

  • l'engagement de l'équipe porte sur l'objectif du sprint
  • le flux continu ne remet pas en question l'engagement sur cet objectif
  • l'objectif est défini lors de la planification de sprint
  • ce mode de fonctionnement en flux continu est compatible avec un engagement librement consenti
  • on ne revoit pas cet objectif tous les jours au moindre changement, évidemment, car il reste du mou par rapport à la capacité de l'équipe. Il est remis en question seulement si, de façon exceptionnelle, un événement imprévu survient (as usual).
  • on peut donc accepter de nouvelles stories pendant le sprint sans remettre en question l'objectif du sprint sur lequel on s'est engagé, tant que cela n'exclut pas une story indispensable pour l'attente de cet objectif


Lire aussi :

Les 6 activités de planification du sprint

La planification du sprint (en anglais Sprint Planning) est un événement Scrum qui se déroule à chaque début de sprint.

L’objectif de la planification est de mettre l’équipe en situation de réussir le sprint en se focalisant sur un objectif et s’accordant sur des stories.

Voici les activités qu'on y mène :

6 activités de planification du sprint

Voici un enchainement possible des activités :

L’équipe embrasse le contexte du sprint. Pour chaque story prête, en commençant par la première, l’équipe confirme avec le PO sa confiance pour la finir dans le sprint.

Pour faciliter la réalisation de la story, on prépare la tactique d’essaimage et on procède à l’identification des tâches.

Avec cette connaissance du travail à faire, l’équipe s’engage sur l’objectif du sprint. Le sprint est alors lancé et chacun, aligné sur l'objectif et la tactique collective, part réaliser une tâche.

Lectures en compléments :

Planifier pour réussir le sprint

En parcourant mon livre à la recherche du 6e D, je m'arrête par hasard sur les pages 108 et 109. Et là, je constate que les titres des paragraphes 9.1 et 9.2 sont quasiment identiques, à l'article près. Évidemment ce n'est pas ce que j'ai voulu. C'est un bug.

Je mène l'enquête et découvre rapidement que le bon titre du §9.1 est "Planifier pour réussir le sprint". D'ailleurs ce titre était déjà présent dans l'édition 3 et il apparaît dans les fichiers que j'ai conservés pour la fabrication de l'édition 4.

En fait, lors de ma dernière relecture juste avant mise en production, j'ai demandé à ce qu'on ajoute "Les" devant le titre du §9.2, par souci de cohérence. Voici un extrait du fichier markdown que j'ai utilisé pour communiquer mes retours de lecture :

Capture_d_e_cran_2017-01-31_a__06.23.36.png

L'éditrice de réalisation s'est trompée en l'appliquant au §9.1. Je ne m'en suis pas rendu compte avant la publication et je m'en excuse auprès de mes lecteurs. Je l'ajoute immédiatement aux quelques errata de cette édition. Voici ce que cela aurait dû donner :

Capture_d_e_cran_2017-01-31_a__05.52.59.png

J'en profite pour mettre en évidence le titre du § "C'est la story qui sprinte". Oui, l'idée que ce soit l'équipe qui sprinte pose problème, c'est pourquoi je préfère appliquer cette notion de sprint à la story.

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...

- page 1 de 6