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 :

Scrum 3.0

Doug Shimp et Dan Rawsthorne sont les auteurs du livre Exploring Scrum. À mon avis, ce livre est le meilleur qui existe sur Scrum en anglais, le plus fouillé et le plus innovant tout en restant dans l'essence de la méthode.

C'est pourquoi je porte une grande attention à l'article Scrum3.0 qu'ils viennent de publier.

On y retrouve l'approfondissement de quelques sujets déjà abordés dans leur livre.

Parmi leurs propositions :

  • le rôle de Product Owner qui est séparé en 2 : le Business Owner et le Capitaine. Cela permet de réintégrer dans Scrum un pattern fréquemment rencontré, celui du PO Proxy
  • le sprint en flux continu. J'ai présenté cette notion lors d'une session à LeanKanbanFrance 2015 et j'en parle dans l'édition 4 de mon livre, chapitre Appliquer Kanban sur Scrum, § 20.3.
  • le backlog structuré en Deliverable Results Backlog (ce que j'appelle le tableau de features) et Work Backlog (le backlog de stories) lui-même organisé avec le sous-ensemble des stories prêtes

Bienvenue au Scrum3.0 !

Al tablèu

Version especiala per Occitània.

Venètz aprener lo manejar visual en tornant bastir los sitis bèls de la region nòva.

Lire la suite...

Accompagnement Scrum

Il y a des coachs agiles qui sont à plein temps chez leur client. Parfois même, ce sont des armées de coachs à plein temps qui restent pendant une longue période au sein d'une organisation.
Je suppose que c’est pour des transformations agiles aussi massives que délicates.

Ce n’est pas la forme d’accompagnement que je pratique. En général, j’accompagne mes clients de façon discontinue et sur une période limitée.

Un bon exemple de ce que je fais, bien que ce ne soit jamais pareil, a été montré dans le retour d’expérience d’Intel à Agile tour Toulouse (il avait aussi été présenté au ScrumDay à Paris en avril).

Chronologie accompagnement Intel

Voici la chronologie du Scrum chez Intel Toulouse, service Telephony, dans la bonne humeur, telle que présentée par Christophe et Cyril.

Dans cette histoire de transformation du service, j’étais le « coach agile », voici les faits saillants de mon intervention.

Cadrage

Une question essentielle est comment démarrer. Dans ce cas d’organisation par silo d'activités, il s’agissait de se mettre d’accord entre le sponsor et ses managers sur l’opportunité de constituer une équipe pluridisciplinaire, en connaissant les implications de Scrum. Comme le contexte est plutôt difficile, un pilote a été lancé assez longtemps après la séance de cadrage que j’ai prodiguée.

Formation initiale

J’ai d’abord donné une formation (on the job training) qui consiste à prendre l’équipe Scrum juste constituée à cette occasion et son vrai projet et à appliquer Scrum dessus. On démarre le sprint zéro ensemble lors de cette formation (4 jours). On pratique sur l’essentiel. On constitue le backlog initial, on prépare le premier sprint. Ensuite ils continuent tout seuls.

Accompagnement d’équipes

Ensuite, j’ai accompagné cette équipe, plutôt légèrement, en participant à des événements de leur sprint : affinage (ils disaient grooming), mêlée, revue, rétro. Légèrement mais suffisamment, parce que l’équipe se débrouillait bien toute seule. Quelques mois plus tard, une deuxième équipe a démarré. Une équipe que j’ai formée de la même façon. Mais une plus difficile à faire adhérer au cadre Scrum. J’aurais dû, je pense, les accompagner plus que ce que je n’ai fait.

Évaluation

Finalement je suis revenu pour une évaluation de ces 2 équipes. J’ai fait cela en interviewant individuellement des membres des équipes, ainsi qu’en animant une rétrospective pour chaque équipe. Le résultat de mon évaluation a permis de mieux aligner les 2 équipes et le management. Un exemple qui me revient est sur l’usage de la vélocité : les équipes avaient le sentiment que le management mettait la pression sur la vélocité, alors que le management voulait juste avoir de la visibilité. Ma restitution les a orientés vers un engagement sur l'objectif de sprint.

Accompagnement de l’organisation

Finalement, un déploiement plus général, de type scrum de scrums, s’est opéré mais sans que j’intervienne pour lancer l’initiative.

J'ai peut-être eu un impact quand même, car l’envoi de 5 personnes du service au premier Raid Agile a sûrement contribué à renforcer le mouvement.

Je suis revenu pour accompagner cette transformation incluant tout le service, avec des actions ciblées sur : la mise en place de Kanban avec l’équipe pour laquelle c’était adapté, des compléments avancés pour les PO, des séances de travail avec le staff sur des sujets comme la planification de release et l’impact mapping et la consolidation de l’approche globale.

En tout, cela a représenté un peu plus d’une vingtaine de jours sur presque 2 ans.

Arrêter Scrum pour le flux, un début d’expérience

Suite à ma présentation à Lean Kanban France, j'ai reçu un message de Sophie. Elle accompagne une équipe confrontée à des difficultés avec Scrum qu'elle a aiguillée vers Kanban.

Son expérience est intéressante et elle la raconte bien, alors nous avons décidé de la publier.

Il s'agit donc d'un billet invité, autrement dit de guest blogging.

Lire la suite...

Les slides de ma prez à #LKFR15

Début septembre, suite à une discussion à propos de Scrum et Kanban, j'avais publié ce billet. Les organisateurs de Lean Kanban France, en particulier DImitri que je remercie chaleureusement, m'avaient alors dit que ce sujet pourrait être intéressant pour la conférence, qui a eu lieu hier et aujourd'hui.

J'aime beaucoup cette conférence et j'ai eu plaisir à y participer. Voici les slides que j'ai présentés hier : Appliquer Kanban sur Scrum, LKFR nov. 2015.

Beaucoup de choses abordées : story, affinage, essaimage, bacs, #noEstimates, impact mapping et bien sûr les limites Kanban sur les tâches, stories, features. Je n'ai pas laissé de temps pour le feedback hier, le vôtre est le bienvenu. Je crois qu'il y a eu une vidéo (à confirmer) et le sujet est traité dans le chapitre 20 de l'édition 4 de mon livre.

Participation à Lean Kanban France

Appliqué sur Scrum, Kanban permet d'éviter les débordements pendant un sprint.

Eviter les débordements

(dessin de Patrice Courtiade)

Lire la suite...

Appliquer Kanban sur Scrum

C'est le titre d'un nouveau chapitre de mon livre, pour l'édition 4 qui sort dans un mois.

Lire la suite...

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

Préface de Kanban pour l'IT

Je publie à nouveau la préface de la deuxième édition du livre de Laurent Morisseau Kanban pour l'IT, en essayant de rendre sa lecture plus fluide (c'est du flux).

Lire la suite...

- page 1 de 7