Appliquer Kanban sur Scrum

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

Je rebondis sur le billet de Laurent Morisseau "Kanban contre le flux continu" pour dire, avec lui, que Scrum et Kanban peuvent cohabiter. C'est le sujet de ce nouveau chapitre.

En introduction du chapitre, je donne les impacts souhaités sur les rôles Scrum, qui rencontrent des problèmes dans certaines situations :

Kanban appliqué à Scrum (cliquer pour agrandir)

Quelques pratiques qu'on peut plus ou moins rattacher à Kanban sont présentées dans d'autres chapitres :

  • l'essaimage dans "Planifier le sprint",
  • la représentation du backlog avec des bacs (basée sur le workflow de la story en Scrum) dans les chapitres "Structurer le backlog" et "Affiner le backlog",
  • la définition de prêt, qui pousse à avoir une file d'attente (le bac de départ) pour désynchroniser l'affinage et la réalisation de la story.

Dans ce nouveau chapitre "Appliquer Kanban sur Scrum", je tente d'apporter une réponse à une demande fréquente, qui est d'injecter des changements à un rythme plus rapide que le sprint. Pour le dire autrement, sortir élégamment du dogme du périmètre fixe pour un sprint. Je n'attends pas ce chapitre pour le remettre en question, car je déconseille l'engagement sur une liste de stories pour un sprint, lors de sa planification. L'élégance vient de la limite Kanban posée, ici, sur le sprint (on peut aussi en mettre ailleurs).

Appliquer Kanban sur Scrum, car ça reste du Scrum. Cela s'adresse aux équipes déjà expérimentées en Scrum. Sinon, il y a le risque que j'évoquais dans le billet "Arrêter Scrum pour le flux, mmmmh"

À noter que dans Xanpan, que je viens de lire (et que je conseille), Allan Kelly conserve la notion de sprint. Xanpan est un mélange de XP et Kanban (il n'y a pas Scrum dans le titre, car pour lui XP c'est Scrum plus les pratiques d'ingénierie, mais il en parle beaucoup). Xanpan se positionne aussi sur cette demande d'injecter des changements à un rythme plus rapide que le sprint.

En écho à la discussion sur l'idéal du one piece flow, je rappelle dans ce nouveau chapitre qu'il vaut mieux mettre des limites sur les gros morceaux que sur les tout petits. Limiter les tâches ne sert pas à grand chose, il vaut mieux limiter les stories. C'est encore mieux de commencer par limiter les features. Et ce serait encore mieux au niveau de l'impact ("outcome"), pour ceux qui font de l'impact mapping. Mais pour en arriver là, il faut avoir ses ★★★ de fluency agile.

Commentaires

1. Le mardi 01 septembre 2015, 18:21 par Laurent Morisseau

Salut Claude,
content de lire qu'un chapitre de la prochaine édition est consacré à kanban pour Scrum. J'ai hâte de le lire :o)
J'aime bien ton approche pas à pas qui permet de respecter le cadre et l'esprit de Scrum en utilisant des idées d'autres approches.
Laurent