Kanban et Scrum - tirer le meilleur des deux

Henrik Kniberg fait partie des rares personnes qui peuvent extraire l'essence d'une situation compliquée, faire le tri entre les idées importantes et celles qui sont accessoires, et fournir une explication limpide étonnamment facile à comprendre. Dans ce livre, Henrik fait un travail brillant pour expliquer les différences entre Scrum et Kanban. Il précise clairement que ce sont seulement des outils alors que ce qui compte vraiment est d'avoir une boîte à outils complète, de comprendre les points forts et les limites de chaque outil et d'acquérir la manière de les utiliser.

Avec ce livre, vous apprendrez ce qu'est Kanban, ses forces et ses limites, et quand l'utiliser. Vous apprendrez également comment Kanban peut améliorer Scrum, ou tout autre outil que vous utilisez, et à quel moment c'est possible. Henrik montre clairement que le plus important n'est pas l'outil avec lequel on commence, mais la façon dont on améliore constamment son utilisation et comment on développe progressivement son ensemble d'outils.

La deuxième partie de ce livre, écrite par Mattias Skarin, rend la lecture encore plus instructive pour le praticien à travers l'application de Scrum et Kanban en situation réelle. Vous y trouverez un exemple montrant la façon dont ces outils ont été mis en place, un par un et ensemble, pour améliorer un processus de développement logiciel. Vous remarquerez qu'il n'y a pas une unique "meilleure" manière de faire les choses ; c'est à vous seul de réfléchir et de découvrir - en fonction de votre contexte - quelle est votre prochaine étape pour améliorer votre processus de développement logiciel.

Mary Poppendieck

Kanban est basé sur une idée très simple : le nombre de travaux à faire (le TAF) dans un processus doit être limité, donc une nouvelle tâche ne peut être ajoutée que si une autre est, au préalable, terminée ou utilisée à la demande d'un processus aval. Le kanban (littéralement la fiche-signal) est un signal visuel produit pour indiquer qu'un nouveau travail peut être entrepris parce que les travaux en cours n'excèdent pas la limite fixée. Cela ne semble pas très révolutionnaire et on ne s'attend pas à ce que cela affecte fortement la performance, la culture, la capacité et la maturité d'une équipe et de son organisation environnante. Ce qui est surprenant c'est que cela arrive ! Kanban ressemble à un petit changement et pourtant il bouleverse l'entreprise.

En fait, Kanban est une approche de gestion du changement. Ce n'est ni un processus de développement ni un cycle de vie d'un logiciel ni une méthodologie de gestion de projet. Vous pouvez commencer à appliquer le principe de Kanban en partant de la façon dont vous travaillez actuellement. Vous commencez par cartographier votre processus avec sa chaîne de valeur puis vous définissez des limites de TAF pour chaque étape de ce processus. Vous pouvez alors lancer le flux de travail en l'entraînant à travers le système lorsque des signaux kanban sont générés.

Kanban s'avère utile aux équipes qui développent du logiciel avec des méthodes agiles, mais il est aussi de plus en plus appliqué par les équipes qui suivent une approche plus traditionnelle. Kanban fait partie du cadre de l'approche Lean, qui a pour but de favoriser l'amélioration continue, en s'adaptant à la culture des organisations.

Parce que le TAF est limité dans un système Kanban, tout ce qui se bloque, pour une raison quelconque, a tendance à engorger le système. Si trop d'éléments de travail se bloquent, tout le processus finit par s'arrêter. Alors toute l'équipe (et l'ensemble de l'organisation) se concentre sur la résolution du problème, le déblocage de l'élément concerné et le rétablissement du flux de travail.

Kanban emploie un mécanisme de contrôle visuel pour suivre le flux de travail qui circule à travers les différentes étapes de la chaîne de valeur. On utilise typiquement un tableau blanc avec des post-its ou un système électronique mural. La meilleure pratique est probablement de combiner les deux. La transparence générée contribue aussi au changement de culture. Les méthodes agiles apportent des bénéfices en favorisant la transparence sur l'avancement des travaux en cours et terminés et en produisant de nouveaux indicateurs, comme la vélocité (la quantité de travail réalisée dans une itération). Toutefois, Kanban va un peu plus loin et assure la transparence dans le processus et son flux. Kanban expose les goulets d'étranglement, les files d'attente, la variabilité et le gaspillage. Toutes ces choses qui influent sur la performance de l'organisation en termes de mesure des éléments à valeur ajoutée produits et de temps de cycle nécessaire pour les produire. Aux membres de l'équipe et aux intervenants externes, Kanban offre la visibilité sur l'effet de leurs actions (ou inactions). Ainsi, les premières études de cas ont montré que Kanban modifie les comportements et encourage une plus grande collaboration au sein des organisations. La visibilité sur les goulets d'étranglement, les gaspillages et le manque de régularité, ainsi que leur impact, encourage aussi les débats sur les progrès possibles et les équipes commencent rapidement à mettre en oeuvre des tâches d'amélioration de leurs processus.

En conséquence, Kanban encourage l'évolution progressive des processus existants et cette évolution correspond globalement aux valeurs de l'Agilité et du Lean. Kanban n'exige pas de révolutionner de fond en comble la façon dont les gens travaillent, il encourage plutôt un changement progressif. Le changement est compris et adopté par consensus parmi les employés et leurs collaborateurs.

Kanban, basé sur un système à flux tiré, encourage également un engagement au plus tard, à la fois sur la priorisation du travail et la livraison du travail en cours. Typiquement, les équipes vont convenir d'une fréquence pour rencontrer les parties prenantes et décider sur quoi travailler dans la suite. Ces réunions peuvent être tenues régulièrement parce qu'elles sont généralement très courtes. On peut y aborder une question très simple, quelque chose comme : "Depuis notre dernière réunion, deux créneaux de travail se sont libérés. Notre temps de cycle actuel jusqu'à la livraison est de 6 semaines. Quelles sont les 2 choses que vous aimeriez voir livrées dans 6 semaines ?". Cela a une double incidence. Poser une question simple se traduit généralement par une réponse de bonne qualité obtenue rapidement et permettant de maintenir une réunion courte. La nature de cette question signifie que l'engagement de sur quoi travailler est retardé jusqu'au dernier instant. Cela améliore l'agilité en gérant les exigences, en raccourcissant les temps de cycle entre l'engagement et la livraison, et en éliminant le travail de remise à niveau puisque le risque d'un changement dans les priorités sera minimisé.

Un dernier mot sur Kanban : l'effet de limiter le TAF assure la prédictibilité du temps de cycle et produit des livrables de meilleure qualité. L'approche "Arrêter la chaîne" lorsque des obstacles et des bugs sont détectés semble aussi encourager un haut niveau de qualité et une baisse rapide du retravail.

Bien que tout cela apparaisse évident avec les explications merveilleusement claires fournies dans ce livre, comment nous en sommes arrivés là reste obscur. Kanban n'a pas été conçu en un seul après-midi par quelque démonstration stupéfiante . Au lieu de cela, il est apparu sur plusieurs années. Un grand nombre de ses grands impacts psychologiques et sociologiques sur la culture, la capacité et la maturité des organisations n'avaient pas été imaginés. Ils ont plutôt été découverts. Bon nombre des résultats obtenus avec Kanban sont contre-intuitifs. Ce qui semble être une approche très mécanique - limiter le TAF et tirer le flux de travail - a effectivement eu des effets profonds sur les gens et sur la façon dont ils interagissent et collaborent entre eux. Je n'avais pas prévu cela, ni d'ailleurs qui que ce soit aux premiers jours de son implication dans Kanban.

J'ai appliqué ce qui est devenu Kanban comme une approche du changement provoquant une résistance minimale. C'était clair pour moi dès 2003. Je l'ai aussi mis en oeuvre pour ses bénéfices mécaniques. À la même époque, j'étais en train de découvrir les applications des techniques Lean et, si la gestion du TAF avait un sens, le limiter en avait encore plus. Ainsi en 2004, j'ai décidé d'essayer de mettre en oeuvre un système à flux tiré à partir des premiers principes. J'en ai eu l'opportunité lorsqu'un directeur de Microsoft m'approcha et me demanda de l'aider à changer son équipe en charge des mises à jour de maintenance sur les applications informatiques internes. La première mise en oeuvre était basée sur la Théorie des Contraintes d'un système à flux tiré connue sous le nom de Drum-Buffer-Rope. Ça a été un énorme succès : le temps de cycle a chuté de 92%, le débit a été multiplié au moins par 3 et la prédictibilité (respect de la date d'échéance) affichait un très acceptable 98%.

En 2005, Donald Reinertsen m'a convaincu de mettre en oeuvre un système Kanban à plus grande échelle. J'en ai eu l'occasion en 2006 lorsque j'ai pris en charge le Département d'ingénierie logiciel chez Corbis à Seattle. En 2007, j'ai commencé à communiquer sur les résultats. La première présentation a été faite au New Product Development Summit à Chicago en Mai 2007. J'ai poursuivi avec un Open Space lors de l'Agile 2007 à Washington DC en août. 25 personnes étaient présentes. 3 d'entre elles étaient de Yahoo! Aaron Sanders, Karl Scotland et Joe Arnold. Ils rentrèrent en Californie, en Inde et au Royaume-Uni pour mettre en oeuvre Kanban avec leurs équipes, qui étaient déjà aux prises avec Scrum. Ils ont également lancé un groupe de discussion Yahoo! qui, au moment où j'écris, est constitué de presque 800 membres. Kanban commençait à se propager et les premiers praticiens partageaient leurs retours d'expérience.

Aujourd'hui, en 2009, Kanban est de plus en plus adopté et de nombreux retours remontent du terrain. Nous avons beaucoup appris sur Kanban dans les 5 années passées et nous continuons tous à apprendre chaque jour davantage. J'ai consacré mes propres travaux à la pratique de Kanban, à écrire sur Kanban, à parler de Kanban et à réfléchir sur Kanban afin de mieux le comprendre et l'expliquer aux autres. J'ai volontairement laissé de côté le fait de comparer Kanban avec les méthodes agiles existantes, même si, en 2008, certains de mes efforts ont été consacrés à expliquer pourquoi Kanban méritait d'être considéré comme une approche agile.

J'ai laissé à d'autres, qui avaient une expérience plus large, le soin de répondre à des questions comme "Comment Kanban se compare-t-il à Scrum ?" Je suis très heureux qu'Henrik Kniberg et Mattias Skarin aient émergé comme des leaders dans ce domaine. Vous, les praticiens, avez besoin d'informations afin de prendre des décisions éclairées et d'avancer dans votre travail. Henrik et Mattias sont au service de vos besoins, et d'une manière que je n'aurais jamais pu mettre en oeuvre. Je suis particulièrement impressionné par l'approche réfléchie d'Henrik en matière de comparaison et de livrable factuel et neutre. Ses dessins et illustrations sont particulièrement perspicaces et vous permettent souvent d'économiser beaucoup de temps de lecture. L'étude de cas faite sur le terrain par Mattias est importante car elle démontre que Kanban est beaucoup plus qu'une théorie : il vous montre par l'exemple comment Kanban pourrait vous être utile dans votre organisation.

J'espère que vous apprécierez ce livre comparant Kanban avec Scrum et qu'il vous donnera un meilleur aperçu sur l'Agilité en général et sur Kanban et Scrum en particulier. Si vous voulez en savoir plus sur Kanban, je vous invite à visiter notre site web communautaire, The Limited WIP Society, http://www.limitedwipsociety.org/

David J. Anderson

Sequim, Washington, Etats-Unis
8 Juillet 2009