Daily meeting kanban : Comment favoriser le flux tiré

Dans mes accompagnements, j’ai remarqué que les équipes IT ayant une première expérience Scrum pouvaient rencontrer un certain nombre de problèmes dans la mise en place de systèmes Kanban.

Ceci est dû au fait que Kanban n’impose que très peu de contraintes et laisse énormément de liberté dans son implémentation. Devant autant de liberté, ces équipes ont tendance à emprunter un certain nombre de pratiques inhérentes à Scrum.

Bien que cette approche ne pose pas de problème en soi, il faut tout de même faire attention à l’implémentation qui en est faite. En effet, le contexte et les objectifs d’une équipe travaillant en Kanban sont souvent très différents d’une équipe travaillant en Scrum. Ceci peut limiter l’efficacité des pratiques portées d’une approche à l’autre.

Nous allons en donner un exemple ici en étudiant les différences dans l’implémentation du Daily Meeting.

Le Daily Meeting Scrum

En Scrum, le Daily Meeting est un cérémonial inscrit dans la méthode. Tous les matins, à heure fixe, une équipe Scrum se rassemble autour du tableau d’avancement du sprint en cours. Chacun à son tour, chaque membre de l’équipe va répondre à 3 questions :

• Qu’ai-je fait hier ?
• Que vais-je faire aujourd’hui ?
• Suis-je bloqué, qui peut m’aider ?

Dans ce cas, le Daily Meeting doit permettre la synchronisation de l’équipe sur la tenue des engagements du sprint, tout en favorisant la cohésion de l’équipe. Cela convient bien aux équipes Scrum qui restent centrées sur la réalisation d’un sprint court (entre 1 et 4 semaines – nommé également itération). Mais cette approche est-elle efficace dans le cadre d’une équipe Kanban ?

Différences structurelles entre Scrum et Kanban

Pour répondre à cette question, il est important de mettre le doigt sur quelques différences structurelles que nous allons souvent rencontrer entre Scrum et Kanban.

• L’étendue du processus pris en charge par la méthode
  Là où Scrum se concentre sur la phase de développement, une démarche Kanban englobe un processus beaucoup plus large. Il n’est en effet pas rare de voir des systèmes Kanban intégrer des étapes de recueil du besoin, d’écriture de user stories, de développement, de tests fonctionnels, de recette, de déploiement …

• La structure de l’équipe
  Là où en Scrum on cherche à construire de petites équipes pluridisciplinaires, un projet Kanban est souvent amené à gérer des équipes plus importantes avec des spécialisations plus marquées. Ceci est principalement dû à la couverture plus large des processus mis en jeu.

• La notion de flux et en particulier de flux tiré
  En Scrum la notion de flux continu n’existe pas vraiment. En effet, le processus est entièrement chargé en début de sprint, et réinitialisé à la fin de celui-ci. Le sprint suivant étant complètement indépendant (rien n’oblige le product owner à replacer dans un sprint les user stories non traitées dans l’itération précédente). Par contre, en Kanban, la notion de flux est le centre de la méthode. Tout doit être mis en oeuvre pour limiter le travail en cours en fluidifiant le flux des éléments dans le système. Pour cela, on doit faire le maximum pour favoriser la sortie des éléments. Ceci nous amène à mettre en place un flux tiré (associé à une limitation du travail à faire) dans notre système Kanban.

Impact de ces différences

Une fois ces différences posées, quels sont les risques auxquels une équipe Kanban s’expose si elle applique, stricto sensu, la façon de faire Scrum pour ses Daily Meeting ?

• En donnant la parole aux membres de l’équipe les uns après les autres, sans ordre particulier, le daily Scrum est centré sur les activités de l’équipe, pas sur les éléments dans le système. On ne parle que des éléments sur lesquels quelqu’un travaille, ou va travailler dans la journée. Des éléments en attente dans le système peuvent donc être facilement oubliés si personne ne les traite au moment du daily. Ceci n’est pas en accord avec une bonne pratique Kanban, qui est de limiter le travail en cours dans le système. Le flux tiré n’est pas géré naturellement.
• La structure de l’équipe étant en général moins homogène en Kanban qu’en Scrum. Le fait que chacun parle à son tour peut manquer de cohérence. Ceci peut entrainer certains membres de l’équipe à se désintéresser de ce qui est dit.
• Dans le cas d’équipes importantes, le daily peut trainer en longueur.
• Le management visuel n’est pas utilisé de façon efficiente, surtout dans le cadre de processus complexes. Chacun parlant de son tour, sans forcement prendre en compte l’état global du système présenté sur le tableau Kanban.

Pour tenter de répondre à ces problèmes, il convient d’adopter une structure différente pour le Daily Meeting en Kanban.

Proposition d’organisation du Daily Meeting Kanban

Plutôt que de faire parler tous les membres de l’équipe un par un, nous allons utiliser le management visuel pour guider le daily. Toute la réunion sera organisée autour des éléments visibles sur le tableau Kanban. Les différents intervenants ne parleront plus chacun leur tour, mais à chaque fois qu’ils peuvent apporter leur aide sur le point en cours de discussion.

1ere étape

Avant le daily, l’animateur s’assure que le management visuel est bien à jour:

• Les user stories sont dans le bon état
• Les règles sont bien respectées
• Les blocages sont visibles

2eme étape

L’équipe passe en revue les problèmes déjà identifiés (fiches kaizen) et en cours de traitement. On vérifie que les actions prévues sont bien menées et qu’elles portent bien leurs fruits. A ce sujet je vous recommande de lire l’article suivant : Il était une fois un projet IT en Kanban (Episode 5 – Partie I) : Gérer les obstacles – La fiche kaizen.

3eme étape

L’équipe passe en revue les points de blocage présents sur le tableau Kanban. Elle essaie de voir si une solution peut être apportée rapidement. Si aucune solution rapide n’est identifiée, une fiche kaizen est rédigée par l’animateur de la réunion et est placée dans le processus de résolution des problèmes. Ceci seront traités par des instances ad hoc hors du Daily Meeting.

4eme étape

En partant de la fin du processus (les colonnes les plus à droite du tableau Kanban) l’équipe doit discuter de tous les éléments dans le système (pour des raisons d’efficacité, il est tout de même possible de traiter certaines fiches par lot). L’objectif de la discussion doit être de voir comment il est possible de faire avancer les éléments discutés. Lors de cette analyse du système, les membres de l’équipe interviennent en fonction de leur spécialité et de leur capacité à faire avancer les activités. C’est lors de cette phase que le travail de la journée est distribué au sein de l’équipe. 

5eme étape

Pour conclure la réunion, l’organisateur demande si tout de monde sait ce qu’il a à faire aujourd’hui, et si quelqu’un a quelque chose à ajouter.  

Difficulté d’implémentation

La principale difficulté que l’on peut rencontrer dans l’application de cette façon de faire, est la longueur du Daily Meeting. Si cela vous arrive, la 1ere question à se poser est de savoir si vous n’avez pas trop de travaux en cours dans votre système. Ceci peut être symptomatique d’une gestion en flux poussé plutôt qu’en flux tiré. La mise en place d’un daily, favorisant le flux tiré, peut alors progressivement résorber le problème. Si ce n’est pas le cas, pas de panique, comme les sujets sont traités par ordre de priorité (Problèmes > sortie du système > entrée dans le système) il est tout à fait possible de time boxer la réunion et d’arrêter le point avant que tous les sujets n’aient été complètement traités.

Conclusion

Je pense que cette approche est plus en accord avec les objectifs attendus d’un système Kanban. Elle a permis de rendre les Daily Meeting plus dynamiques et plus efficaces sur de nombreux projets que j’ai eu l’occasion d’accompagner.