La vie de la story selon Elodie

Après Jimmy, c"est Élodie qui a commenté mon billet la vie de la story. Elle me fait des remarques très intéressantes, j'y réponds en dessous, dans un ordre revu.

Élodie :

J'imagine que c'est une simplification, un workflow idéal... mais il donne impression que toute idée aboutira... je serais plus à l'aise avec quelques "portes de sortie" pour prendre en compte les depriorisations, les risques, les imprévus...

Dans une autre vie, il y a plus de 15 ans, j'ai fait de la modélisation de processus en UML ou BPMN, il y avait plein de branches et de boucles… L'agilité m'a appris à simplifier. La finalité du modèle à 5 états que je propose est sa représentation, puis son utilisation sous forme de bacs (ou colonnes). Le management visuel (kanban) pousse à représenter tout process de façon linéaire, de la gauche vers la droite. C'est donc comme tout modèle, une simplification de la réalité. Mais…

Je verrais bien une sortie vers la poubelle au niveau de l'affinage. Oui, je pense qu'il faut savoir renoncer ^^

Bien sûr. Lors de ma présentation à LeanKanbanFrance 2015, j'avais montré ce slide —avec poubelle :

Options et engagement

C'est le rôle du PO de faire en sorte que des options soient explorées, puis abandonnées si elles apportent peu d'impact. Il est donc normal de jeter à la poubelle des stories à partir du bac à sable, ou qui sont en affinage, voire même, exceptionnellement, qui sont prêtes.

Du coup, plus de boucle ?

Dans une approche flux Kanban, la boucle est embêtante, elle peut conduire à violer une limite. On évite de revenir en arrière, de remonter le flux.

Imaginons une story "done", mais qui n'est pas acceptée à la démo (quelle qu'en soit la raison). Quel serait alors son état ?

Le guide Scrum est très clair au sujet de la revue : • L’Équipe de Développement fait la démonstration du travail qui est « Fini ». Il ne s'agit pas d'une revue formelle où une autorité accepte ou pas. Le cas que tu imagines n'arrive pas.

Personne d'extérieur à l'équipe n'a le droit de considérer ce que l'équipe considère fini comme pas fini. Seule l'équipe peut reconnaitre s'être trompée, c'est pourquoi dans iceScrum il y a bien longtemps, nous avions prévu de pouvoir repasser une story finie à en cours tant que le sprint n'est pas clos. C'est une boucle alors cela doit rester exceptionnel.

Ou alors la notion de "fini" inclus l'acceptation par le PO ?

Oui. À mettre de façon explicite dans la définition de fini si ce n'est pas implicite dans l'équipe.

Et si on n'arrive pas à la finir ? Je verrais bien aussi une flèche de la réalisation à l'affinage si on ne n'arrive pas atteindre le Done.

C'est pas fini, et en général reporté au prochain sprint. La story reste en cours.

Et si on considère que l'acceptation n'est pas dans la DoD et se joue en demo il faudrait une étape supplémentaire ça ferait donc 1 étape et 1 état en plus...

Cela ne peut pas arriver car :

  1. on ne montre que ce qui est fini à la démo
  2. fini inclut l'acceptation (qui est là pour confirmer que la story est finie, un des 3C)

Et la revue n'est pas prévue pour ça.

Merci Élodie.

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 :

Arrêter Scrum pour le flux, mmmmh !

Parmi les raisons évoquées par ceux qui disent "on arrête Scrum pour passer au flux", certaines m'apparaissent très discutables :

  • les réunions prennent trop de temps,
  • le sprint est un carcan qui met la pression sur les équipes,
  • on déploie à un rythme différent du sprint, alors pourquoi le garder ?

Lire la suite...

Pourquoi kanbaniser du Scrum ?

Dans mes trois présentations d'automne (à Paris pour Lean Kanban France, à Toulouse et bientôt à Agile Grenoble), je montre comment une équipe qui pratique déjà Scrum avec succès peut s'appuyer sur Kanban, comme méthode d'amélioration de son existant.

Mais dans quel but ? Rien de tel qu'une carte des impacts pour résumer la vision de ce Scrum kanbanisé.

Lire la suite...

Lean Kanban en France

Le flux arrive en octobre.

Lire la suite...

Quelles colonnes à la une ?

Ce n'est pas en ajoutant des colonnes à un tableau que le système sera plus fluide.

Lire la suite...