Kanban & PO

Je vais tenter de répondre aux questions relatives au Kanban et au rôle de Product Owner.

Dans KanBan comment tu gère le "Product Owner" ? Il peut y en avoir plusieurs ?Il valide le passage de colonnes ou bien tout à la fin ?

Tout d'abord Kanban ne prescrit aucun rôle. Ce n'est pas une méthode de gestion de projet mais avant tout un moteur d'amélioration continue d'un processus.

Partons d'une équipe Scrum avec un Product Owner. Quel est son rôle?

Porter la vision du produit, constituer et maintenir le Product Backlog (valeur métier et priorisation), pilotage de la version. Dans le cas d'un projet multi équipes, il doit également coordonner les activités des équipes pour gérer les dépendances. Le rôle du Product Owner en chef est également d'arbitrer lorsque l'on a une équipe de Product Owners.

Une partie des activités du Product Owner  est nécessaire quelque soit le processus choisit: vision, définition du besoin, pilotage, arbitrage... Pour le reste, une approche Kanban permet de réduire une partie des activités:

D'abord les estimations: Les story points qui servent à calculer la vélocité de l'équipe, c'est l'outil de pilotage du Product Owner avec le burndown de version; Et la valeur métier (ROI, ...) qui avec les story points permettent de prioriser les user stories : Valeur métier / Story points en première approximation.

Le pilotage avec le Kanban s'appuie sur le nombre d'éléments de travail et leur délai moyen de réalisation (Cycle Time) ou mieux le Lead Time. La mécanique du Kanban avec les limites aux états permet de réguler le processus. On peut affiner le dispositif avec les classes de services mais c'est une autre histoire.

Sur cette base là, plus besoin de vélocité, seul le nombre et le type compte, donc plus d'estimation en story points, ce qui représente un temps non négligeable en Scrum, mais permet un partage d'informations entre le métier et l'équipe.

Le besoin en priorisation est moins important également puisque les batchs sont moins longs. Les coûts fixes des cérémonies Scrum (Sprint planning meeting, démo, revue de sprint et rétrospective) font qu'il est rare de passer en dessous de 2 semaines pour un sprint. On est plutôt autour de 3 semaines en moyenne. Le Product Owner doit donc avoir un Product Backlog prêt (estimé et priorisé) pour au moins 1 à 2 sprints soit 4 à 6 semaines de travail.

Avec le Kanban, on peut avoir une planification à une semaine ou mieux au besoin. Nous n'avons pas les mêmes coûts fixes car le sprint planning meeting est réduit à un choix simple: quels sont les X éléments de travail sur lesquels nous allons travailler cette semaine? Pas d'estimation des taches techniques. Pas de revue de Sprint. Les démo et rétrospectives sont déclenchées au besoin. En tout cas peuvent être découplées de la planification et donc être moins fréquentes.

Moins de stock, moins de priorisation et de rework pour le Product Owner. On est plus sur une notion d'option réelle que de priorisation.

Pour les équipes plus importantes, Kanban a une meilleure scalabilité. La ou Scrum préconise des équipes de 7 personnes (dont un Product Owner), Kanban permet des équipes plus importantes. personnellement avec ma première équipe Kanban en 2009, nous sommes montés à 18, bien qu'il ait fallu quelques rétrospectives pour trouver les bons formats. On réduit de fait les coûts de coordination des équipes, la gestion des dépendances, les réunions de Scrum de Scrums.

En conclusion, avec le Kanban, on va réduire le volume de travail lié à la maintenance du Product Backlog (donc naturellement la densité de Product Owners par projet). On se rend compte qu'une partie du travail du Product Owner n'apporte pas de valeur lorsque l'on passe à un système régulé en flux.

Cependant, on n'y arrive pas du jour au lendemain...

Pour ce qui est de la validation au passage des colonnes, on reste dans la même philosophie que la définition de fait de Scrum: Une checklist de passage pour chaque colonne, explicite, partagée par toute l'équipe. La ou Scrum propose d'avoir 3 niveaux de DoD (user story, sprint, version), on peut en avoir pour chaque état avec le Kanban. En revenant au rôle de Product Owner qui valide les user stories à la fin du sprint lors de la revue, Kanban ne spécifie rien. Rappelons que l'objectif est de se mettre d'accord sur la vélocité réelle de l'équipe, qui n'a plus lieu d'être avec du flux. Par contre, c'est une caractéristique qui risque d'augmenter le cycle time du processus si le Product Owner doit valider le passage d'un élément de travail à chaque colonne.

Cas d'école de Bruno

Imaginons qu'on a un tableau KanBan avec 10 colonnes, chacune étant un travail à réaliser par un département. Disons que le colonne n°3 correspond au travail de l'équipe de développement(+test)A la fin des 10 colonnes le projet (ou la user story) est terminé.
Après le développement et le test, certaines colonnes ne sont pas nécessairement liées... Ex: Il y a une colonne "écrire des procédures pour le customer care" et une colonne "réaliser le training pour les commerciaux"
Pour ces colonnes: J'ai un manager qui me dit: je ne veux pas que l'on passe d'une colonne à l'autre mais qu'on fasse les choses en parallèle histoire de gagner du temps
Que pourrais-je répondre à ce manager qui se voit bien mettre un project manager qui coordonnera toutes les colonnes ?

Avec du Kanban, on ne cherche pas coûte que coûte à rendre séquentiel le flux de travail. C'est une des dérives que l'on voit avec l'approche tableau. D'autres expérimentent des représentations visuelles non séquentielles (Lire ou voir les sessions de Karl Scotland par exemple).  
Pour revenir au cas précédent, les deux colonnes n'étant pas nécessairement liées et le travail pouvant être parallélisé, le tableau peut être revu pour mieux coller au flux du travail:

• Soit par une parallélisation des tâches avec une WIP limite sur les tâches parallélisées: Découper le tableau en 2 lignes à ce niveau là
• Soit avec une colonne (Formation/Procédure) avec la granularité MMF (plutot que user story dans cet exemple) dont les taches pourraient être :
• Ecrire les procédures pour le customer care
• Réaliser le training pour les commerciaux

N'hésitez pas si vous avez des questions sur le Kanban, je m'efforcerais d'y répondre par le biais du blog.