Cet article est le deuxième d’une série destinée aux gestionnaires qui désirent mieux comprendre les méthodes agiles. Fort de sa pratique, notre collaborateur et expert Samuel Tremblay nous explique comment les intégrer efficacement au quotidien. Après le scrum, voici la méthode kanban.

Cela peut paraître surprenant, mais à l’origine, la méthode kanban servait à optimiser la gestion des conteneurs qui entreposent les pièces requises par une chaîne de montage. Provenant de l’industrie manufacturière japonaise des années 1950 (et plus précisément des usines Toyota), elle consistait en l’utilisation d’une étiquette kanban – en japonais, ce mot signifie «étiquette» ou «carte» – servant d’avertissement, lorsqu’un conteneur de pièces était vide, qu’il fallait en commander de nouveau.

Il faudra attendre 2005 avant que David Anderson, alors à l’emploi de Microsoft, réussisse à l’appliquer dans un contexte de développement logiciel. Ayant en son cœur la gestion du flux de travail (ou, en anglais, workflow), la méthode kanban s’articule aujourd’hui autour de trois axes : la mesure de ce flux, sa définition et sa visualisation.

Contrôler le flux de travail grâce à la loi de Little

C’est de la théorie des files d’attente qu’est apparue la loi de Little, permettant de lier ensemble trois paramètres ou mesures de toute file de ce genre :

À cet effet, considérons le carnet de produit d’une équipe kanban fictive comme une file d’attente :

- Débit (ou throughput). Il s’agit du nombre d’éléments que l’équipe peut traiter selon une unité de temps définie. Le traitement de 6 éléments du carnet de produit par semaine représenterait ainsi un débit. À noter qu’ici, «traité» veut dire «complété», selon le barème de qualité défini par l’équipe.

- Travaux en cours (ou work in progress [WIP]). Il s’agit de la quantité totale d’éléments en cours de traitement par l’équipe. Si chaque équipier travaille en moyenne sur 2 éléments au sein d’une équipe de 3 personnes, le WIP sera donc de 6.

- Temps de cycle (ou cycle time). Il s’agit du temps moyen qu’un élément prend pour être traité par l’équipe. En appliquant la loi de Little pour trouver ce paramètre, il est possible de calculer un temps de cycle moyen d’une semaine, soit 5 jours de travail.

Nous aurons alors compris toute la puissance de cette équation : en réduisant le WIP à 3 – chaque personne travaille donc sur seulement 1 élément en même temps –, le temps de cycle est lui aussi réduit de moitié, à 2 jours et demi! En pratique, le débit sera bien souvent fixe, car représentatif de l’efficacité et de la taille de l’équipe, sans investissement supplémentaire. Voilà pourquoi les meilleures pratiques kanban consistent plutôt à limiter le WIP.

Les meilleures pratiques à implanter dans une équipe kanban

Outre la limitation du WIP expliquée dans la section précédente, d’autres meilleures pratiques se doivent d’être listées, selon le guide kanban :

- Définir le flux de travail. C’est dans la définition qu’on trouvera ce que représente un élément; à quel niveau de qualité celui-ci est jugé «complété»; ses différents états; ainsi que les règles de passage d’un état à un autre. Par exemple, une équipe pourrait vouloir définir un état «à tester», qui représenterait un élément dont le travail a été effectué, mais pas encore examiné par un pair.

- Visualiser le flux de travail. Le visuel permettant de rendre visibles les éléments d’un flux (c’est-à-dire les états dans lesquels ils se trouvent, de même que la limite du WIP d’un état donné) s’intitule, tout simplement, le tableau kanban. Ce dernier est d’ailleurs l’outil le plus fréquemment utilisé par les équipes qui se servent d'une méthode agile pour inspecter quotidiennement leur progression

- Gérer activement les éléments dans le flux de travail. Tout en s’assurant du respect du WIP déterminé par l’équipe, gérer activement les éléments signifie de les empêcher de «vieillir» dans le flux (sauf si cela est requis, bien sûr) et veut donc dire, par le fait même, de débloquer tout élément «coincé».

- Offrir un niveau de service. De l’anglais Service Level Expectation (SLE), cette pratique représente en quelque sorte la cible à atteindre, par opposition au temps de cycle, lequel est mesuré empiriquement. Ainsi, la SLE de notre équipe fictive pourrait être : «avoir complété 80 % de nos éléments en 4 jours ou moins».

Kanban et Scrum, des méthodes mutuellement exclusives?

L’utilisation par une équipe Scrum d’un tableau kanban a été brièvement évoquée, mais qu’en est-il de ces deux méthodes? Faut-il choisir l’une au détriment de l’autre? Comment effectuer ce choix en tant que gestionnaire?

Il faut se rappeler ici que le manifeste agile impose à l’équipe une totale autonomie, laquelle ira jusqu’à la sélection du cadre de développement par ce groupe. Cela étant dit, dans un contexte de pénurie de main-d'œuvre qui facilite le changement fréquent d’emploi, l’atteinte d’une maturité d’équipe permettant cette prise de décision peut se révéler ardue. Il convient alors de se poser la question suivante : Quelle est la nature du travail que l’équipe aura à accomplir?

En effet, dans des projets hautement complexes de transformation numérique à l’intérieur desquels un découpage exhaustif des fonctionnalités à accomplir a été réalisé, la méthode Scrum serait retenue : le travail est connu d’avance et facilement planifiable sprint par sprint. Dans le contexte de projets caractérisés à la fois par une quantité colossale de tâches relativement similaires à effectuer et par des priorités parfois changeantes, la méthode kanban s’avérerait alors plus appropriée : le travail, défini par des morceaux de tailles semblables, s’ajoute facilement au flux de travail dès que le WIP le permet.

En conclusion, il convient de souligner que de nombreuses équipes choisissent des éléments de chacun des cadres de développement. En ce sens, rien n’empêche un chef de mêlée de s’impliquer à temps plein dans une équipe kanban; il pourrait même se voir confier la responsabilité d’appliquer les meilleures pratiques définies à la section précédente! Le principe est le même pour les cérémonies, puisque les besoins d’inspecter sa progression fréquemment (mêlées quotidiennes), d’adapter ses manières de faire (rétrospective) et d’aller chercher la rétroaction de ses parties prenantes (démonstration à fréquence fixe) demeurent et sont efficacement comblés par les cérémonies Scrum. C’est d’ailleurs dans cet esprit qu’a été rédigé le document The Kanban Guide for Scrum Teams.