Le tableau kanban pour piloter ses activités

Introduction

Objectifs du chapitre :

L’approche Kanban met en avant la collaboration par la communication via les principes et vertus qu’elle porte comme la visualisation, la transparence, etc. N’étant pas prescriptive, elle ne donne pas de règles sur la façon dont doit s’organiser cette communication, par quelles réunions, à quelle fréquence, et encore de quelle façon les mener. La seule contrainte est qu’une communication authentique entre équipiers, entre équipes pratiquant Kanban dans l’organisation, et avec les parties prenantes prenne place périodiquement.

Dans ce chapitre, quelques rituels et pratiques que l’équipe peut mettre en place sont présentés pour profiter au mieux des principes de la démarche Kanban pour le développement de produit intangible. Il peut être utile de mener les ateliers et autres rituels de manière régulière, à une fréquence prédéterminée, mais dans une approche Kanban, ce n’est pas considéré comme une absolue nécessité.

L’équipe aura à cœur de ne pas multiplier...

Planifier en Kanban

La construction traditionnelle d’échéanciers repose sur la croyance que le planificateur possède une connaissance quasi parfaite du futur. Les approches adaptatives, Agile ou basées sur le flux tiré, considèrent au contraire que planifier est une action à rendement rapidement décroissant. Elles constatent que les échéanciers se détériorent rapidement. Pour elles, il ne s’agit pas de ne plus planifier, mais de planifier :

Kanban pour le développement de produit intangible suggère de planifier les travaux de l’équipe en intégrant les quatre préconisations précédentes. Ce contrôle de la production passe d’abord par la planification des nouveaux éléments de travail pour déterminer quand ils entrent dans le flux puis par l’application des politiques de transition pour permettre à certains de franchir les étapes du flux.

Planifier le travail consiste donc, premièrement, à déterminer quand passer un élément de travail du Bac à sable à la première bannette valant engagement (Carnet de commandes par exemple) : la question à laquelle il faut que l’équipe réponde est de savoir quelle est la probabilité que l’élément de travail à lancer dans le procédé respecte le niveau de service attendu....

Traiter les défauts et les anomalies

La règle Ne pas laisser un défaut se propager vers l’aval est on ne peut plus claire. Un défaut doit être corrigé dès qu’il est détecté (mécanisme andon de la démarche Lean).

Gérer les points de blocage

Un élément de travail bloqué est un élément qui ne progresse pas dans le procédé. Il s’oppose à la fluidité recherchée. Pour que le flux soit créé, il faut maîtriser le pourquoi de ces blocages. Pour cela, l’équipe :

Lorsqu’un élément de travail est bloqué, il faut que son état soit visible sur le tableau kanban. Une pastille colorée, un dessin particulier, etc. permet visuellement de signaler cet état à toute l’équipe et autres parties prenantes. Il est contre-indiqué de définir une colonne supplémentaire Bloqué dans laquelle mettre cet élément : un état n’est pas une étape....

Point régulier de synchronisation

Le point régulier de synchronisation (abrégé en PRS) est un point court, le plus souvent quotidien, durant lequel l’équipe se réunit devant le tableau kanban. L’équipe discute de la progression des éléments dans l’en-cours. Elle analyse les éléments bloqués et examine les moyens de les faire avancer dans le flot. Les tickets sont examinés de droite à gauche : l’équipe commence par la dernière étape de son procédé où elle effectue du travail comptant dans le temps de cycle ; il s’agit en général de l’étape en amont de Terminé. Tout équipier peut solliciter l’aide de l’équipe pour faire avancer les tickets qu’il est en train de traiter. L’équipe vérifie que les éléments progressent en accord avec le niveau de service attendu. Cette vérification repose sur les analyses statistiques vues dans le chapitre Analyser le procédé. Le PRS est aussi l’occasion de faire un (très léger) suivi des risques identifiés par l’équipe ou le management. Un atelier spécifique de gestion des risques se charge de les examiner en profondeur à une fréquence plus faible que le PRS.

Par rapport au PRS utilisé dans certaines approches Agile qui se basent notamment sur Scrum où chaque équipier répond à la fameuse et ambiguë trilogie « qu’as-tu fait hier pour nous rapprocher de l’objectif de l’itération, que comptes-tu faire aujourd’hui qui nous rapproche de l’objectif de l’itération, qu’est-ce qui te bloque dans l’atteinte de l’objectif de l’itération », le PRS kanban évacue cette focalisation sur chaque équipier qui se transforme souvent en compte-rendu au chef. Tout est sur le tableau kanban...

Atelier de réapprovisionnement

Comment un élément entre-t-il dans le carnet de commandes de l’équipe ? La décision est prise lors de cet atelier. Cet atelier peut être planifié à intervalles réguliers ou à la demande (quand la bannette Carnet de commandes est presque vide, par exemple). Il s’agit de déterminer, parmi les demandes positionnées dans le Bac à sable, celles sur lesquelles l’équipe (ou le convoi) va engager des travaux et s’engager sur l’atteinte du niveau de service attendu. Il est aussi possible de distinguer l’engagement sur l’acceptation par l’équipe du travail à faire (Carnet de commandes) et l’engagement sur le niveau de service (seulement après Affinage de l’élément de travail lorsque cette étape existe).

Les personnes présentes à cet atelier sont :

La fréquence de ce point dépend du débit de l’équipe et du nombre d’éléments dans...

Atelier de planification de déploiement

Kanban propose deux points où un engagement est pris par l’équipe. Le premier est situé dans le procédé lorsque l’équipe décide de passer une demande dans l’étape Carnet de commandes depuis l’étape Bac à sable : ce moment est l’Atelier de réapprovisionnement. Là, l’équipe s’engage à faire telle ou telle demande. Le second point d’engagement dans le procédé proposé par Kanban, celui dont nous parlons ici, est le moment de ce procédé où l’équipe décide d’intégrer la réalisation d’un élément de travail lorsqu’il sera terminé dans un incrément de produit à livrer, et planifie et coordonne les activités de livraison au client. L’équipe s’engage sur une date de livraison au client. Cette livraison peut ne concerner qu’une demande ou bien un lot de demandes. Les éléments de travail sélectionnés dans l’atelier de réapprovisionnement font l’objet d’un engagement concernant le respect du NSA (« Nous avons 85 % de chances de terminer cet élément dans les x unités de temps qui viennent. »). Mais même terminé...

Atelier de revue du service

L’atelier de revue du service a pour objet d’examiner et améliorer en conséquence l’efficacité du service rendu par l’équipe aux clients de l’organisation. Il permet de comparer ce que l’équipe est en mesure de réaliser par rapport aux attentes des clients. Il s’agit donc d’évaluer comment le service fonctionne, en se concentrant sur la performance du flot des éléments de travail et sur la satisfaction des clients.

Cet atelier se tient typiquement deux fois par mois sous l’égide du responsable du service. Il dure moins d’une heure. Participent à cet atelier l’équipe elle-même (ou des représentants du convoi le cas échéant) ainsi que des représentants du métier concerné par le produit développé et toute partie prenante concernée par le développement et la livraison des incréments de produit.

L’atelier examine les points suivants :

Atelier d’amélioration de la façon de faire

Il s’agit pour l’équipe, grâce à cet atelier, d’identifier et de s’accorder sur ce qui doit être mieux fait et de planifier comment accomplir immédiatement cette amélioration. La technique de la rétrospective est la façon dont cet atelier est généralement tenu. La rétrospective suit souvent l’atelier de revue de service en ce que les constats de ce dernier sont des éléments qui concourent à l’identification de besoins éventuels d’améliorations.

La rétrospective [43, ¶141] est donc une des techniques utilisées pour que l’équipe passe en revue sa façon de faire et pour déclencher des actions d’amélioration. Lors de ce rituel, la façon dont le travail de l’équipe a été accompli naguère est passée en revue par l’équipe elle-même afin d’identifier d’éventuels points positifs qu’il conviendrait de diffuser à l’organisation, ainsi que d’éventuels points à améliorer. Ces derniers doivent faire l’objet d’un plan d’amélioration défini par l’équipe elle-même. Ce plan est immédiatement mis en œuvre.

En pratique, les participants sont les équipiers, sans le management. Ce dernier peut être invité le cas échéant....

Atelier de revue des risques

Le guide ISO 73-2009 (Management du risque - Vocabulaire) définit le risque comme l’effet de l’incertitude sur les objectifs. Ce guide définit l’incertitude comme l’état, même partiel, de défaut d’information concernant la compréhension ou la connaissance d’un événement, de ses conséquences ou de sa vraisemblance. Or, l’existence de l’incertitude est bien une caractéristique du développement de produit (notamment logiciel). Toute initiative de développement de produits est naturellement soumise à des risques dont l’éventuelle survenue impacte⁶⁹ ses objectifs et ceux de l’organisation.

Organisation comme équipe de développement, chacune à son niveau d’influence, doivent donc gérer proactivement les risques pour prémunir les initiatives qui sont sous leur responsabilité des conséquences éventuelles négatives (ou les renforcer dans le cas de conséquences positives). La finalité de la gestion des risques est la création et la préservation de la valeur potentielle attachée au produit ou service que l’équipe développe. Pour cela, il faut identifier les risques, les analyser, les évaluer, puis agir en conséquence. Il ne s’agit pas d’éviter le risque, mais d’augmenter la chance qu’il ne se transforme pas en problème (s’il s’agit de risque pur) !

La gestion des risques est le parent pauvre des activités de développement de produit : mal comprise, voire ignorée par l’organisation qui confond trop souvent risque et problème, il m’a semblé qu’il n’était pas inutile de rappeler ici quelques principes autour de cette notion et des avantages à ce qu’elle fasse l’objet de l’attention de l’équipe comme de l’organisation.

Déploiement continuel

Raccourcir le délai de commercialisation (time to market) est le but ultime du système Toyota de production. Nous abordons dans le chapitre Kanban dans un cadre manufacturier comment Kanban présente une solution à cet objectif dans le cadre d’origine de cette démarche, à savoir la production industrielle. Sans dévoiler ce qui est dit dans ce chapitre-là, le lecteur, au fil des chapitres qu’il a déjà parcourus, aura retenu que la constitution d’inventaires entre les étapes du procédé est un obstacle à la fluidité nécessaire à la réalisation de l’objectif. Dans la présente section, nous nous focalisons sur l’inventaire en bout de procédé, là où est constitué le lot des travaux terminés qui vont être livrés au client. Si minimiser l’inventaire entre étapes est un moyen de fluidifier le procédé, qu’en est-il de l’inventaire qui suit la dernière étape de ce procédé ?

En résumé

Une des complaintes les plus entendues à propos d’une démarche Agile de développement concerne le nombre, la durée et la fréquence de leurs rituels. La raison d’être de ces rituels est, en partie, de compenser la volonté de remplacer la communication documentaire exhaustive par l’échange face à face. Ce dernier est certes plus efficace, mais elle ne laisse pas de traces auxquelles se référer (verba volent scriba manent). On objectera, avec raison, que rien dans le Manifeste pour le développement Agile de produit n’oblige l’équipe à tenir tous ces rituels et à la cadence effrénée qui est celle parfois observée dans certaines organisations ou équipes. Malheureusement, la nature tayloriste des organisations ayant horreur du vide, celle-ci leur fait oublier les principes Agile pour leur faire appliquer les bonnes vieilles pratiques du management « commande et contrôle ». Et c’est ainsi que le PRS (re)devient un compte-rendu au chef. On peut également identifier comme coupables certains coaches et autres X Master (ⱯX) dont la seule compétence est de faire appliquer telle ou telle « méthode » Agile à la lettre à défaut d’en maîtriser l’esprit.

Dans l’approche...