Accueil Nos publications Blog [Scrum Day 2013] OMG ! Mon équipe fait son haka en kanban style !
Agilité Evénement
15/04/2013 5 min

[Scrum Day 2013] OMG ! Mon équipe fait son haka en kanban style !

Lors de ce Scrum Day 2013, alors que je regardais le planning des sessions, j’ai été interpellé par le titre de la session de Laurent Morisseau, “OMG ! Mon équipe fait son haka en kanban style !”. Tiens, ça parle de kanban, dans un salon axé sur Scrum, mon incroyable esprit de déduction en a conclu que l’on allait très certainement parler de Scrumban. Le sujet me semblait donc très intéressant, tout comme l’orateur, il n’en fallait pas plus pour me décider à franchir les portes de la salle afin d’assister à cette session qui répond à la question : Comment Kanban peut améliorer Scrum ?

Scrumban, ou comment kanban peut améliorer scrum

Durant cette session, Laurent nous a parlé des Scrum Smells, ces antipatterns Scrum qui, bien que problématiques , sont avant tout des opportunités pour s’améliorer. Il n’y a pas de recette miracle ni de manière unique d’y répondre,  mais l’idée de cette présentation est de donner une trousse à outils pour adapter Scrum et éliminer ces antipatterns. Trois de ces Scrum Smells, ces “scènes de crime”, ont été mis en lumière :

Un dev = Une story

Le problème : lorsque chaque story est assignée à un unique développeur du début à la fin, le Daily Scrum Meeting ressemble plus à du reporting, avec une somme de travaux individualistes, et il n’y a pas d’opportunité pour revoir comment on va travailler ensemble. Le burndown est ok, le total de story points à faire diminue en suivant plus ou moins la courbe idéale. Mais qu’en est-il du burn-up ? Pour rappel, le burn-up chart est une courbe en escalier montrant l’évolution du nombre total de story points livrés depuis le début du projet. Il permet de déduire la vitesse à laquelle les fonctionnalités sont implémentées, suivant un axe temporel. L’avantage par rapport au burndown est qu’il montre l’évolution du périmètre et le débit .

Chuck Norris Style Burn Up Chuck Norris Burn Up ![/caption]

Le risque !

Le risque, dans ce Scrum smell, est de ne pas tenir le périmètre de sprint , ainsi que la diminution du débit . Le projet prend donc du retard, même si le burndown nous dit que tout va bien ! Le burnup chart en revanche va mettre tout ce petit bazar en évidence. Le second risque est tout simplement de faire du travail individuel et non en équipe, avec des spécialisations abusives et un non-partage de la connaissance.

La solution ?

  • avoir un Sprint Burnup, avec une courbe représentant le travail réalisé, et une courbe représentant le travail en attente de démo
  • mettre en place un WIP limit (Work-In-Progress Limit) sur le nombre de stories en cours

Laurent nous fait remarquer que la notion de limite est déjà présente dans Scrum avec la vélocité . Le but de cette solution est bien évidemment de se rapprocher du burn-up idéal, afin de diminuer le risque sur le sprint.

Concepts Kanban associés

  • Tableau à deux niveaux, 
  • WIP Limit, 
  • Lisser la création valeur, 
  • Contraindre processus pour plus de collaboration

Goulet d’étranglement

Seconde scène de crime, le goulet d’étranglement apparait lorsque le Burndown n’est pas validé sur la fin car on n’a pas eu le temps de passer les Tests d’acception des User Stories. Tant pis, on démontre même si c’est pas fini. Et là, c’est le drame. La démo est calamiteuse. Notre belle méthode Scrum devient un mini cycle en V, les user stories non finies sont démontrées par l’équipe, puis démontées par le Product Owner / les clients. On note également le manque flagrant de discipline sur la qualité.

Le risque ! 

Ici, les risques sont d’accumuler considérablement et rapidement de la dette technique, de perdre la confiance du management, du Product Owner, de prendre du retard sur le projet.

La solution ?

  • Personnaliser son Scrum board et rajouter par exemple des colonnes Tests à faire / Tests en cours après les colonnes To do/Doing/Done du développement.
  • WIP limit sur ces nouvelles colonnes (limite haute, limite basse)

On connait surtout la limite haute à ne pas dépasser. Il existe également la limite basse , qui est un déclencheur; activé à la première story arrivant dans la colonne “A Tester”, elle permet de créer un buffer de tâches , alimenté ensuite en permanence. L’effet attendu est de se rapprocher du burndown/up ideal.

Concepts kanban associés

  • Voir le processus terrain
  • Rendre visible le goulet d’étranglement
  • Limiter en amont de la contrainte d’abord
  • Protéger la contrainte par limite basse
  • Voir ou mettre l’effort au bon endroit et au bon moment

Un PO dépassé

Dernière scène de crime abordée, voici le cas où le Product Owner est dépassé. Il met beaucoup de temps pour faire le product backlog, celui-ci est trop exhaustif (un des spectateurs a mentionné un backlog de 800 stories !), ou à l’extrême inverse en flux trop tendu (3 – 4 stories à faire). Il faut donc armer le PO pour faire face à ces difficultés.

Le risque !

Les risques sont d’avoir un Product Backlog se transformant en un document de spécifications fonctionnelles détaillées , un backlog pas prêt pour le sprint planning, des stories pas prêtes dans le sprint, et aucun pilotage de version .

La solution ?

Comment doser l’effort du PO ? Si la contrainte est du côté de l’équipe, le Product Owner doit travailler en flux tiré . Laurent nous a montré un exemple de tableau Kanban pour le PO configuré comme suit :

On pourra utiliser les limites basses et hautes sur les stories prêtes pour voir sur un ou deux sprints suivants (cela permet de mieux planifier les sprints). En résumé, c’est tout simplement une vue du product backlog . Les effets attendus sont de pouvoir gérer son backlog en flux tiré , avoir son bon nombre de stories prêtes, avoir une meilleure visibilité du cycle de vie d’une story.

Concepts kanban associés

  • Gérer un système en flux tiré
  • Gérer le flux de valeur

Conclusion

Alors flux ou sprint ? La cible du Kanban est bien du flux, mais Kanban est avant tout une approche pour améliorer un processus existant . Plutôt que d’imposer un travail en flux, on cherche d’abord à fluidifier le travail. Scrumban apporte ainsi la possibilité de faire du meilleur Scrum, un travail plus fluide et moins variable. Laurent conclut en rappelant que tout ceci sert à relancer la dynamique d’amélioration continue , et qu’il faut sortir l’équipe de sa zone de confort, pour aller expérimenter et personnaliser ses processus, ce qui fait partie du rôle du Scrum master.

Cette session s’achève avec un rappel sur le principe japonais du Shuhari. On apprend les règles, les processus (Shu), on les casse (Ha) et on s’adapte on créé selon notre contexte (Ri). Pour finir, une belle citation du légendaire samurai japonais Miyamoto Musashi mais dont je ne me rappelle plus…

Pour ma part, cette session fut très enrichissante, Laurent nous a exposé avec simplicité et humour trois scènes de crime, antipatterns que l’on rencontre souvent mais sans forcément le savoir ! J’ai pu y voir des exemples concrets pour booster Scrum à l’aide d’outils simples et puissants issus des concepts de Kanban. Savoir quoi utiliser et surtout comment et dans quel contexte, tel est le rôle de tout bon coach qui se respecte !

Liens

Rédigé par :

Olivier Le Lan