Réflexion sur l'étape 1 de Priming Kanban

Parlons sérieusement. Si l'introduction de Priming Kanban est vraiment intéressante, et méritera un poste sur les mythes de Lean / Kanban, la première étape "Visualiser le flux de travail" rentre déjà dans le dur des principes du Lean.

Respirer

Tout d'abord, l'idée même du Lean est la transformation continue et progressive des systèmes. Avant de tout casser, comprenez ! Le terme à la mode cette année était Shu Ha Ri, et c'est finalement bien le concept de fond derrière la démarche globale de Kanban :
Shu est l'apprentissage, Ha est la maîtrise, la remise en question, Ri est le dépassement. Peter Hundermark le rappelle déjà dans son ouvrage "Do Better Scrum" traduit il y a quelques temps. Nous occidentaux pressés voulons atteindre le Ri immédiatement. Non ! Stop ! Calmons nous !

La première étape pourrait finalement s'appeler "Respirer et regarder". Respirer est l'activité la plus importante de notre vie, comme le battement du coeur ou la circulation des liquides et des énergies dans le corps : c'est une primitive de la vie qui une fois acquise est ancré à un tel niveau de profondeur et d'inconscient qu'il est difficile d'en reprendre la main. Il est dit (et c'est une parenthèse un peu longue) que certain maître bouddhiste parviennent à contrôler l'absorption d'éléments toxiques dans leur corps.

Je disais "Respirer". Oui, avant de tout casser dans un processus, un mode de fonctionnement, il est nécessaire (salvateur ?) de prendre du recul, de se recentrer et de s'interroger un instant. "Où suis-je ? Que se passe-t-il ?" Dans une situation de crise, ce pas en arrière est généralement celui qui vous sauve la vie. Si vous êtes coincé dans un immeuble en feu (ce que je ne vous souhaite pas), courir tout droit peut vous mener vite à la mort.

Dès lors, cette phase initiale est la plus importante, et l'oublier ou la passer trop vite déséquilibre l'entiereté de la démarche. C'est dans une démarche systémique ce qu'il ne faut surtout pas faire. Procéder par l'action d'abord est certes tentant ("je bouge donc je suis utile") et revient souvent à allumer un incendie pour éteindre celui que vous voulez éteindre.
C'est néanmoins souvent par ce principe que l'Agile se déploie, et plus encore Scrum ces derniers temps : "Mon projet ne marche pas, j'ai des délais à respecter, vite Scrum !"

Scrum, Kanban et visualisation

Les références à Scrum sont nombreuses dans l'ouvrage de Jesper, et l'usage de Kanban comme catalyseur de Scrum a fait ses preuves, pour lesquelles Laurent Morisseau a construit quelques présentations assez drôles il y a quelques temps déjà.
Reprenons l'idée de visualisation et le rapport à Scrum. Si vous écoutez Jeff Sutherland, en particulier dans sa conférence TedX à Aix, il explique très bien l'usage de la visualisation dès le début de ces recherches. Pour avoir eu la chance de l'avoir en formation Scrum Master il y a quelques années, le découpage actuel d'un Scrum Board en trois étapes est finalement... mythique ! Alistair Cockburn le montre bien sur son "Scrum sur un Post-it" : le Scrum Board n'est pas du "Core Scrum", la visualisation par contre oui !
Ensuite, Scrum part du postulat que votre équipe est autonome et polyvalente, dans le sens où tous les acteurs d'une phase "doing", c'est à dire de la spécification à la mise en production, sont présents.
Dans ce contexte, et en gardant le principe Lean de simplicité, pourquoi découper a priori une étape "doing" en plusieurs morceaux ? Il n'y aurait de ma fenêtre qu'une bonne raison : votre définition, c'est à dire la politique en langage Lean, du "Done" ne permet pas un usage de la fonctionnalité par votre utilisateur...

En résumé, Scrum ou pas Scrum n'est pas la question. Scrumban lorsque Scrum ne marche pas est une application de Kanban décrite dans l'ouvrage pour mettre en lumière ce qui ne va pas. Et avant de trouver des patch / outils / processus compliqués pour faire tourner votre Scrum qui n'atteint pas le x4, une bête visualisation du flux actuel est souvent un bon moyen de comprendre où sont les blocages.