Kanban et Scrum - tirer le meilleur des deux

OK, essayons de résumer Scrum et Kanban, chacun en moins de 100 mots.

2-1-1. Scrum en bref▲

2-1-2. Kanban en bref▲

2-2-1. Scrum et Kanban sont tous les deux des outils de processus▲

2-2-2. Comparer les outils pour mieux les comprendre et non pour les juger▲

2-2-3. Aucun outil n'est complet, aucun outil n'est parfait▲

2-2-4. Scrum est plus normatif que Kanban▲

2-2-5. Ne vous limitez pas à l'emploi d'un seul outil !▲

Scrum est basé sur 3 rôles : le Product Owner (qui donne la vision du produit et définit les priorités), l'Équipe (qui développe le produit) et le ScrumMaster (qui supprime les obstacles et guide l'équipe pour le suivi du processus).

Kanban ne prescrit aucun rôle.

Cela ne signifie pas que vous ne pouvez pas ou ne devez pas avoir un rôle de Product Owner dans Kanban ! Cela signifie simplement que vous n'êtes pas obligé. Avec Scrum et Kanban vous êtes libre d'ajouter tous les rôles supplémentaires dont vous avez besoin.

Soyez cependant prudent lorsque vous ajoutez des rôles. Assurez-vous que les rôles supplémentaires apportent effectivement de la valeur et n'entrent pas en conflit avec d'autres éléments du processus. Êtes-vous sûr d'avoir besoin d'un rôle de Chef de Projet ? Dans un grand projet c'est probablement une bonne idée, peut-être que cela aidera les nombreuses équipes et les Product Owners à se synchroniser entre eux. Dans un petit projet, ce rôle pourrait être du gaspillage, ou pire, pourrait conduire à une sous-optimisation et du micro-management.

L'état d'esprit général dans Scrum et Kanban est "maximiser le minimalisme". Donc en cas de doute, commencer avec le minimum.

Dans le reste du livre, j'utiliserai le terme "Product Owner" pour parler de la personne qui fixe les priorités d'une équipe, quel que soit le processus utilisé.

Scrum est basé sur des itérations de durée fixe, appelées sprints. Vous pouvez choisir la durée du sprint, mais l'idée générale est de conserver la même durée sur une période de temps significative et ainsi d'établir un rythme de travail.

• Début de sprint : un backlog de sprint est créé, c'est-à-dire que l'équipe extrait plusieurs éléments spécifiques du backlog de produit, sur la base des priorités fixées par le Product Owner et la quantité d'éléments que l'équipe pense pouvoir traiter dans ce sprint.
• En cours de sprint : l'équipe se concentre sur la réalisation des éléments sur lesquels elle s'est engagée. Le périmètre du sprint est fixe.
• Fin de sprint : l'équipe organise la démonstration du produit pour les parties prenantes concernées, le produit doit être potentiellement livrable (c'est-à-dire testé et prêt à être déployé). L'équipe fait ensuite une rétrospective pour discuter de son processus et l'améliorer.

Ainsi, un sprint Scrum représente un rythme de travail unique de durée fixe et combinant trois activités différentes : la planification, l'amélioration des processus, et (idéalement) la livraison d'une version.

Avec Kanban, les itérations de durée fixe ne sont pas imposées. Vous pouvez choisir à quel moment faire de la planification, de l'amélioration des processus et livrer des versions. Vous pouvez faire ces activités sur une base régulière ("livraison tous les lundis") ou à la demande ("livraison chaque fois que nous avons quelque chose d'utile à livrer").

Équipe n°1 (rythme unique)

"Nous pratiquons des itérations comme les sprints de Scrum."

Équipe n°2 (trois rythmes)

"Nous avons trois rythmes différents. Chaque semaine, nous livrons ce qui est prêt à être livré. Toutes les deux semaines, nous avons une réunion de planification, de mise à jour de nos priorités et des plannings de livraison. Toutes les quatre semaines, nous avons une réunion (rétrospective) pour améliorer nos processus."

Équipe n°3 (rythme essentiellement piloté par les événements)

"Nous déclenchons une réunion de planification chaque fois que nous commençons à ne plus rien avoir à faire. Nous déclenchons la livraison d'une version dès que nous disposons d'un ensemble de MMF ("Minimum Marketable Feature" = "fonctionnalité minimale apportant de la valeur à l'utilisateur"). Nous déclenchons spontanément un cercle de qualité à chaque fois que nous tombons sur un même problème pour la deuxième fois. Nous faisons aussi une rétrospective plus approfondie toutes les quatre semaines."

Avec Scrum, le backlog de sprint montre les tâches qui doivent être exécutées au cours de l'itération. Il est généralement concrétisé par des post-it collés sur un mur, que l'on appelle tableau Scrum ou tableau des tâches.

Alors, quelle est la différence entre un tableau Scrum et un tableau Kanban ? Commençons avec un projet très simple pour comparer les deux :

Dans les deux cas, nous suivons la progression d'un groupe d'éléments à travers un workflow. Nous avons défini trois états : "À faire", "En cours", et "Terminé". Vous pouvez définir autant d'états que vous voulez - certaines équipes ajoutent des états tels que "Intégré", "Testé", "Livré", ... N'oubliez cependant pas le principe "maximaliser le minimalisme".

Alors, quelle est la différence entre ces deux exemples de tableaux ? Ouaip - le petit 2 dans la colonne du milieu sur le tableau Kanban. C'est tout. Ce chiffre 2 signifie qcolonne à un instant donné".

Avec Scrum, il n'existe pas de règle empêchant l'équipe de mettre tous les éléments dans la colonne "En cours" en même temps ! Toutefois, la limite est implicite puisque le périmètre du sprint est figé. Dans ce cas, la limite implicite est de 4, car il y a seulement 4 éléments dans l'ensemble du tableau. Donc Scrum limite le TAF indirectement, alors que Kanban limite le TAF directement.

La plupart des équipes Scrum finissent par apprendre que c'est une mauvaise idée d'avoir un trop grand nombre d'éléments en cours, et développent une culture visant à terminer les éléments commencés avant d'en démarrer de nouveaux. Certaines ont même décidé de limiter explicitement le nombre d'éléments autorisés dans la colonne "En cours" et donc - tadaaa ! - le tableau Scrum est devenu un tableau Kanban !

Ainsi, Scrum et Kanban limitent tous les deux le TAF, mais de manière différente. Les équipes Scrum mesurent habituellement une vélocité - le nombre d'éléments (ou unités correspondantes telles que les "story points") réalisés par sprint. Une fois que l'équipe connaît sa vélocité, cela devient sa limite de TAF (ou tout au moins une indication). La plupart du temps, une équipe qui a une vélocité moyenne de 10 ne traitera pas plus de 10 éléments (ou "story points") au cours d'un sprint.

Ainsi, avec Scrum, le TAF est limité par unité de temps. Avec Kanban, le TAF est limité par étape du workflow.

Dans l'exemple Kanban ci-dessus, 2 éléments au plus peuvent être dans l'état "En cours" à un moment donné, indépendamment de toute durée. Vous avez besoin de définir la limite à appliquer à chaque état du workflow, sachant que l'idée générale est de limiter le TAF de tous les états, en commençant le plus tôt possible et en terminant le plus tard possible dans le flux de valeur. Donc dans l'exemple ci-dessus, nous devrions ajouter une limite TAF à l'état "À faire" (ou tout autre nom que vous donnez à votre file d'entrée). Une fois que nous avons défini nos limites de TAF, nous pouvons commencer à mesurer et estimer le temps de cycle, c'est-à-dire le temps qu'il faut à un élément, en moyenne, pour traverser tout le tableau. Disposer de temps de cycle prédictibles nous permet de nous engager sur des niveaux de service (en anglais SLA : Service Level Agreement) et de planifier de façon réaliste les livraisons.workflow, sachan

Si la taille des éléments varie de façon spectaculaire alors il est possible d'envisager de définir les limites de TAF en story points, ou tout autre unité de taille que vous utilisez. Certaines équipes préfèrent investir du temps à re-découper en éléments d'à peu près la même taille ce qui permet d'éviter ce type de considération et réduit le temps passé à estimer les choses (vous pourriez même considérer que passer du temps à estimer est un gaspillage). Il est plus facile de créer un système fluide si les éléments sont à peu près de la même taille.

Imaginez qu'il y ait des boutons sur ces compteurs, et que vous puissiez configurer votre processus en tournant simplement ces boutons. "Je veux une haute capacité, un temps de cycle faible, une qualité et une prédictibilité élevées. Je vais donc tourner les boutons sur 10, 1, 10 et 10, respectivement."

Ce serait géant, n'est-ce pas ? Malheureusement, il n'y a pas de boutons de contrôle de ce type. Aucun que je connaisse du moins. Faites-moi savoir si vous en trouvez.

Au lieu de cela, ce que nous avons, c'est un tas de boutons de contrôle indirect.

Scrum et Kanban sont tous les deux empiriques dans le sens où vous expérimentez le processus puis vous l'adaptez à votre environnement de travail. En fait, vous devez l'expérimenter. Scrum et Kanban ne sont prévus pour vous fournir toutes les réponses - ils vous donnent juste un ensemble de contraintes pour piloter votre propre amélioration de processus.

• Scrum explique que vous devez disposer d'équipes multidisciplinaires. Donc, qui devrait être dans quelle équipe ? Si vous ne savez pas, expérimentez-le.
• Scrum avance que c'est l'équipe qui choisit la quantité de travail à réaliser dans un sprint. Donc, quelle quantité de travail peut-elle faire ? Si vous ne savez pas, expérimentez-le.
• Kanban dit que vous devez limiter le TAF. Donc, quelle doit être cette limite ? Si vous ne savez pas, expérimentez-le.

Comme je l'ai mentionné plus haut, Kanban vous impose moins de contraintes que Scrum. Ce qui signifie que vous devez penser à ajuster plus de paramètres, tourner plus de boutons. Cela peut être un désavantage ou un avantage, en fonction de votre contexte. Lorsque vous ouvrez l'interface de configuration d'un logiciel, préférez-vous avoir 3 options ou 100 options de paramétrage ? Probablement quelque part entre les deux. Cela dépend de ce que vous souhaitez paramétrer et de la compréhension que vous avez de l'outil.

Alors, disons que nous allons réduire la limite de TAF, en se basant sur l'hypothèse que cela améliorera notre processus. On observe ensuite comment les choses telles que la capacité, le temps de cycle, la qualité et la prédictibilité évoluent. À partir des résultats, nous en tirons des conclusions, puis nous changeons encore d'autres choses, améliorant constamment notre processus.

Il y a plusieurs noms pour cela. Kaizen (amélioration continue dans le langage Lean), Inspection et Adaptation (dans le langage Scrum), Processus de Contrôle Empirique, ou pourquoi pas La Méthode Scientifique.

L'élément le plus critique est le feedback. Changer quelque chose => Découvrez comment cela s'est passé => Tirez-en des leçons => Changez encore quelque chose. D'une manière générale, le feedback doit être le plus rapide possible, afin que vous puissiez adapter votre processus rapidement.

Avec Scrum, le feedback est rythmé par le sprint. Il y a plus court, cependant, surtout si vous combinez avec XP (eXtreme Programming) :

Lorsqu'il est correctement appliqué, le couple Scrum + XP vous offre de nombreuses possibilités de feedback à forte valeur ajoutée.

Le feedback interne - la programmation en binôme permet un feedback en quelques secondes. Les anomalies sont détectées et résolues dans les secondes qui suivent leur apparition ("Hé, cette variable n'est pas censée valoir 3 ?"). Autrement dit, il s'agit d'un feedback pour la question "Sommes-nous en train de bien construire le produit ?".

La feedback externe - le sprint permet un feedback en quelques semaines. Autrement dit, il s'agit d'un feedback à la question "Sommes-nous en train de construire le bon produit ?".

Mais qu'en est-il de Kanban ? Eh bien, tout d'abord vous pouvez (et probablement vous devriez) utiliser tous les types de feedback mentionnés ci-dessus dans votre processus que vous utilisiez Kanban ou non. Ce que Kanban vous offre en plus, ce sont des mesures temps réel très utiles.

• Temps de cycle moyen. Mis à jour chaque fois qu'un élément atteint l'état "Fini" (ou le nom que vous donnez à votre colonne la plus à droite).
• Les goulets d'étranglement. Un symptôme connu apparait lorsque la colonne "X" est bourré d'items tandis que la colonne "X+1" est vide. Recherchez dans ce cas des "bulles d'air" dans votre tableau.

Ce qui est intéressant, concernant les mesures temps réel, c'est que vous pouvez choisir la durée de votre feedback, basée sur la fréquence à laquelle vous êtes prêt à analyser les mesures et à apporter des modifications. Un feedback trop long signifie que votre amélioration du processus se fera lentement. Un feedback trop rapide fait que votre processus n'aura peut être pas le temps de se stabiliser entre chaque changement, ce qui peut causer du gaspillage.

En fait, vous pouvez également expérimenter la durée du feedback ... un peu comme un méta-feedback. Bon, je n'irai pas plus loin sur ce sujet.

Exemple : expérimentez les limites de TAF avec Kanban

L'un des moyens typiques d'ajustement de Kanban est la limite du TAF. Mais comment pouvons-nous savoir si l'on a vu juste ?

Supposons que nous avons une équipe de 4 personnes, et que nous décidons de commencer par une limite de TAF à 1.

Chaque fois que nous commençons à travailler sur un élément, nous ne pouvons pas démarrer un nouvel élément tant que le premier n'est pas Fini. Donc, cela va très vite.

Super ! Mais il s'avère que c'est le plus souvent impossible pour 4 personnes de travailler sur le même élément (dans cet exemple), donc nous aurons des gens inactifs. Si cela ne se produit qu'une fois ce n'est pas un problème, mais si cela se produit régulièrement, le temps de cycle moyen va augmenter. Fondamentalement, un TAF de 1 signifie que les éléments vont rapidement traverser l'état "En cours", par contre ils vont rester coincés dans l'état "À faire" plus longtemps que nécessaire, de sorte que le temps de cycle total (= temps de traversée du workflow complet) sera inutilement élevé.

Alors, si un TAF de 1 est trop faible, qu'est-ce-que cela donne avec un TAF de 8 ?

Cela fonctionne mieux pendant un temps. Nous constatons que le travail en binôme est plus rapide en moyenne. Ainsi avec une équipe de 4 personnes, nous avons habituellement 2 éléments dans l'état "En cours" à un moment donné. Un TAF de 8 est juste une limite haute, donc si on le baisse c'est mieux !

Supposez maintenant que nous avons un problème avec le serveur d'intégration, donc nous ne pouvons pas finir de traiter les éléments (notre définition de "Fini" comprend l'intégration). Ce genre de problème arrive parfois, non ?

Puisque nous ne pouvons pas terminer les éléments D et E, nous commençons à travailler sur l'élément F. Nous ne pouvons pas non plus intégrer celui-ci, donc nous traitons un nouvel élément G. Au bout d'un moment, nous atteignons notre limite Kanban - 8 éléments dans "En cours".

À ce stade, nous ne pouvons plus ajouter d'éléments. Eh, nous ferions mieux de régler ce problème de serveur d'intégration ! La limite de TAF nous a invités à réagir et à éliminer le goulet d'étranglement au lieu d'empiler du travail non fini.

C'est pas mal. Mais si la limite de TAF était de 4, nous aurions réagi beaucoup plus tôt, nous donnant ainsi un meilleur temps de cycle moyen. Donc c'est un équilibre à trouver. Nous mesurons le temps de cycle moyen et essayons d'ajuster constamment nos limites de TAF pour optimiser le temps de cycle.

Au bout d'un moment, on peut constater que des éléments s'entassent dans l'état "À faire". Peut-être serait-il temps d'ajouter une limite de TAF à cet endroit également.

D'ailleurs pourquoi avons-nous besoin d'une colonne "À faire" ? Eh bien, si le client était toujours disponible pour dire à l'équipe quoi faire la fois suivante, alors la colonne "À faire" ne serait pas nécessaire. Mais dans notre cas, le client n'est pas toujours disponible, de sorte que la colonne "À faire" donne à l'équipe un petit buffer de travail.

Expérimentez ! Ou, comme les Scrumologistes le disent : Inspectez et Adaptez !

Disons que notre tableau Scrum ressemble à cela :

Que se passe-t-il si quelqu'un se présente et souhaite ajouter l'élément E au tableau ?

Une équipe Scrum répondra typiquement quelque chose comme "Non, désolé, nous nous sommes engagés sur le périmètre A+B+C+D pour ce sprint. Mais n'hésitez pas à ajouter l'élément E au backlog du produit. Si le Product Owner estime que c'est un élément de forte priorité, nous le traiterons dans le sprint suivant." Des sprints de bonne durée donnent à l'équipe tout juste assez de temps pour obtenir une version du produit, tout en permettant au Product Owner de gérer et mettre régulièrement à jour les priorités.

Et que dirait l'équipe Kanban ?

Une équipe Kanban répondrait : "N'hésitez pas à ajouter l'élément E dans la colonne "À faire". Mais la limite est de 2 pour cette colonne, donc vous devrez dans ce cas retirer C ou D. Nous travaillons en ce moment sur A et B et, dès que nous en aurons la capacité, nous dépilerons un élément de la colonne "À faire".

Ainsi, le temps de réponse (le temps qu'il faut pour répondre à un changement de priorité) d'une équipe Kanban correspond au temps pour retrouver de la capacité à traiter, suivant le principe général de "un élément qui sort = un élément qui rentre" (pilotage par les limites du TAF).

Le temps de réponse d'une équipe Scrum est en moyenne équivalent à la moitié d'un sprint.

Avec Scrum, le Product Owner ne peut pas toucher au tableau Scrum puisque l'équipe s'est engagée sur un ensemble spécifique d'éléments dans le sprint. Avec Kanban, vous définissez vos propres règles de base précisant qui est autorisé à changer quoi sur le tableau. Typiquement, on attribue au Product Owner une colonne "À faire" ou "Prêt" ou "Backlog" ou "Proposé" à l'extrême gauche où il peut apporter des changements quand il le veut.

Ces deux approches ne sont cependant pas exclusives. Une équipe Scrum peut décider d'autoriser un Product Owner à changer les priorités au milieu d'un sprint (même si c'est normalement considéré comme une exception). Et une équipe Kanban peut décider d'ajouter des restrictions sur le moment où les priorités peuvent être changées. Une équipe Kanban peut même décider de s'engager sur des itérations de durée fixe avec un périmètre fixé, tout comme en Scrum.

Un tableau Scrum ressemble généralement à quelque chose de ce genre au cours des différents moments d'un sprint.

Lorsque le sprint est fini, le tableau est effacé et tous les éléments sont enlevés. Un nouveau sprint est lancé et après la réunion de planification du sprint suivant, nous avons un nouveau tableau Scrum, avec de nouveaux éléments dans la colonne la plus à gauche. Techniquement, il s'agit d'un gaspillage mais pour des équipes Scrum expérimentées, cela ne prend généralement pas trop de temps, et le processus de réinitialisation du tableau peut apporter un sentiment agréable d'accomplissement et de fin officielle. Un peu comme laver la vaisselle après le dîner - le faire est une épreuve, mais c'est agréable une fois que c'est fini.

Avec Kanban, le tableau est généralement persistant : vous n'avez donc pas besoin de le réinitialiser et de démarrer avec autre chose.

Un tableau Scrum est détenu par une et une seule équipe Scrum. Une équipe Scrum est multidisciplinaire, elle possède toutes les compétences nécessaires pour mener à bien tous les éléments du sprint. Un tableau Scrum est généralement visible de toute personne intéressée, mais seule l'équipe Scrum peut le modifier : c'est l'outil qui lui permet de maîtriser ses engagements sur le sprint en cours.

Avec Kanban, les équipes multidisciplinaires sont facultatives, et un tableau peut ne pas être détenu par une équipe spécifique. Un tableau est lié à un workflow unique, pas nécessairement à une seule équipe.

Voici deux exemples :

Exemple 1 : l'ensemble du tableau est géré par une équipe multidisciplinaire. Comme en Scrum.

Exemple 2 : le Product Owner définit les priorités dans la colonne 1. Une équipe de développeurs multidisciplinaire développe le produit (colonne 2) et le teste (colonne 3). La livraison (colonne 4) est assurée par une équipe de spécialistes. Il y a un léger chevauchement de compétences, donc si l'équipe de livraison devient un goulet d'étranglement, l'un des développeurs va les aider.

Avec Kanban, vous devez donc établir des règles de base pour définir qui utilise le tableau et de quelle façon, puis vous expérimentez les règles pour optimiser le flux.

Scrum et Kanban sont tous les deux basés sur le développement incrémental, c'est-à-dire la division du travail.

Une équipe Scrum s'engagera uniquement sur des éléments qu'elle pense pouvoir traiter dans un sprint (en ayant préalablement défini le "Fini"). Si un élément est trop gros pour tenir dans un sprint, l'équipe et le Product Owner essayeront de trouver des moyens de diviser cet élément en plusieurs éléments plus petits jusqu'à ce que cela tienne dans un sprint. Si les éléments sont tous globalement gros, les sprint seront plus longs (mais généralement pas plus de 4 semaines).

Les équipes Kanban essayent de minimiser le temps de cycle moyen et de maximiser le flux, ce qui incite indirectement à diviser les éléments en plus petits éléments. Mais il n'y a pas de règle explicite indiquant que les éléments doivent être suffisamment petits pour correspondre à une durée fixe. Dans le même tableau nous pourrions avoir un élément qui prend 1 mois à traiter et un autre élément qui prend 1 jour.

En Scrum, les équipes sont censées évaluer la taille relative (= quantité de travail) de chaque élément sur lequel elles s'engagent. En additionnant la taille de chaque élément terminé à la fin de chaque sprint, nous obtenons la vélocité. La vélocité est une mesure qui sert à estimer la capacité : la quantité d'éléments que nous pouvons livrer par sprint. Voici un exemple d'équipe avec une vélocité moyenne de 8.

Sachant que la vélocité moyenne est de 8, nous pouvons alors prévoir une capacité de 8 pour les éléments que nous pourrons traiter dans les prochains sprints, et donc planifier de façon réaliste les livraisons.

En Kanban, l'estimation n'est pas imposée. Si vous souhaitez vous engager vous devez décider de la manière de prévoir les choses.

Certaines équipes choisissent de faire des estimations et de mesurer la vélocité, tout comme en Scrum. D'autres équipes choisissent de ne pas faire d'estimation, mais essayent de diviser les choses à faire en éléments d'à peu près de la même taille : ils peuvent alors mesurer la vélocité en terme de nombre d'éléments traités par unité de temps (par exemple, nombre de fonctionnalités par semaine). Certaines équipes groupent les éléments pour obtenir un ensemble de MMF (Minimal Marketable Feature), mesurent le temps de cycle moyen par MMF, et l'utilisent pour établir des SLA (Service Level Agreements). Exemple de SLA : "quand nous nous engageons sur uneous nous engageons sur une MMF, elle sera toujours livrée dans les 15 jours".

Il y a toutes sortes de techniques intéressantes pour la planification de release et la gestion des engagements dans le style Kanban, mais aucune technique spécifique n'est prescrite ; alors allez-y, essayez différentes techniques jusqu'à ce que vous en trouviez une qui convient à votre contexte. Vous verrez probablement émerger des bonnes pratiques au fil du temps.

En Scrum, le "Backlog de produit" est un nom plutôt regrettable, car il implique que tous les éléments doivent concerner le même produit. Voici deux produits, vert et jaune, chacun avec son propre backlog de produit et sa propre équipe :

Que faire si vous n'avez qu'une seule équipe ? Eh bien, envisagez que le Backlog de produit devienne le Backlog d'équipe. Il liste les priorités pour les prochains sprints d'une équipe (ou un ensemble d'équipes). Si cette équipe maintient plusieurs produits, fusionnez donc les deux produits dans une seule liste. Cela oblige à établir des priorités entre les deux produits, ce qui est utile dans certains cas. Il existe plusieurs façons de le faire dans la pratique :

Une stratégie serait d'avoir l'équipe dédiée à un seul produit par sprint :

Une autre stratégie serait que l'équipe travaille sur les fonctionnalités des deux produits pendant chaque sprint :

C'est la même chose en Kanban. Nous pouvons avoir plusieurs produits circulant à travers le même tacartes de différentes couleurs :

... ou en ajoutant des "lignes de nage" :

Je ne vais pas reprendre ici la Pensée Lean ni le Manifeste Agile, mais d'une manière générale, Scrum et Kanban reposent tous les deux sur les mêmes valeurs et principes. Par exemple :

• Scrum et Kanban sont orientés Juste à temps (JIT = Just In Time) qui est un principe Lean. Cela signifie que l'équipe choisit le moment et la quantité de travail sur laquelle s'engager, et "tire" le travail quand elle est prête, plutôt que de voir ce travail "poussé" de l'extérieur. Exactement comme une imprimante qui tire la page suivante uniquement au moment où elle est prête à l'imprimer (même s'il n'y a qu'un petit stock limité de papier qu'elle peut utiliser).
• Scrum et Kanban sont basés sur une optimisation continue et empirique des processus, qui correspond au principe Kaizen du Lean.
• Scrum et Kanban mettent l'accent sur la réactivité aux changements plutôt qu'au suivi d'un planning (même si Kanban donne en général une réponse plus rapide que Scrum), l'une des quatre valeurs du Manifeste Agile.

... et plus encore.

D'un autre côté, Scrum n'est pas aussi Lean que cela, car il prévoit de grouper la réalisation des éléments dans des itérations à durée fixe. Mais cela dépend de la durée de votre sprint et de ce que vous comparez. Par rapport à un processus traditionnel où l'on intègre et livre 2 à 4 fois par an, une équipe Scrum développant un produit potentiellement livrable toutes les 2 semaines est très Lean.

Si vous continuez avec des sprints de plus en plus courts, vous vous rapprochez de Kanban. Lorsque vous commencez à parler de durée inférieure à 1 semaine, vous pouvez envisager de laisser entièrement tomber le principe de l'itération à durée fixe.

Je l'ai déjà dit et je le dis encore : expérimentez jusqu'à ce que vous trouviez ce qui fonctionne pour vous ! Ensuite, continuez encore à expérimenter :-)

Voici quelques différences qui semblent moins importantes que celles mentionnées précédemment. Il vaut mieux en prendre conscience tout de même.

2-14-1. Scrum recommande un backlog produitpriorisé▲

2-14-2. Scrum impose des points quotidiens▲

2-14-3. Scrum recommande des burndown charts▲

En Scrum, le backlog de sprint ne représente qu'une partie de la vue complète - la partie qui montre ce que l'équipe est en train de faire au cours du sprint. L'autre partie est le backlog de produit - la liste des choses que le Product Owner veut avoir dans les prochains sprints.

Le Product Owner peut consulter mais ne peut pas toucher au backlog de sprint. Il peut changer le backlog de produit autant de fois qu'il veut, mais les modifications ne prennent effet (c'est-à-dire affectent le travail en cours) que dans les sprints suivants.

Lorsque le sprint est terminé, l'équipe "fournit une version potentiellement livrable" au Product Owner. En fait l'équipe termine le sprint, fait une revue de sprint, et montre fièrement les fonctionnalités A, B, C et D au Product Owner. Le Product Owner peut alors décider s'il convient ou non de livrer cette version du produit. La dernière partie - la livraison réelle du produit - n'est habituellement pas incluse dans le sprint, et n'est donc pas visible dans le backlog du sprint.

Dans ce scénario, un tableau Kanban pourrait plutôt ressembler à quelque chose de ce genre :

L'ensemble du workflow est représenté sur le même tableau : nous ne sommes pas simplement en train de regarder ce qu'une équipe Scrum est en train de faire dans une itération.

Dans l'exemple ci-dessus, la colonne "Backlog" est juste une liste de souhaits, sans ordre particulier. La colonne "Selected" contient les éléments de priorité haute, avec une limite Kanban à 2. Il peut donc y avoir seulement 2 éléments de priorité haute à un moment donné. Lorsque l'équipe est prête pour commencer à travailler sur un nouvel élément, elle dépile l'élément de plus haute priorité dans la colonne "Selected". Le Product Owner peut apporter des modifications aux colonnes "Backlog" et "Selected" à tout moment, mais pas aux autres colonnes.

La colonne "Dev" (scindée en deux sous-colonnes) montre ce qui est actuellement en cours de développement, avec une limite Kanban à 3. En termes réseau, la limite Kanban correspond à "la bande passante" et le temps de cycle correspond au "ping" (ou temps de réponse).

Pourquoi avons-nous scindé la colonne "Dev" en deux sous-colonnes "En cours" et "Fini" ? C'est pour donner à l'équipe de production la visibilité sur les éléments qu'ils peuvent mettre en production.

La limite "Dev" à 3 est partagée entre les deux sous-colonnes. Pourquoi ? Supposons qu'il y ait 2 éléments dans la colonne "Fini" :

Cela signifie qu'il ne peut y avoir qu'un seul élément dans la colonne "En cours". Cela implique qu'il y aura une capacité excédentaire, des développeurs qui pourraient commencer un nouvel élément, mais qui n'y sont pas autorisés à cause de la limite Kanban. Cela les incite donc fortement à aider à livrer des choses en production, afin de vider la colonne "Fini" et à maximiser le flux. Cet effet est positif et progressif - plus il y a de choses dans la colonne "Fini", moins il peut y avoir de choses dans la colonne "En coconcentrer sur de bonnes choses.

2-15-1. Flux à une pièce▲

2-15-2. Un jour au pays de Kanban▲

2-15-3. Est-ce que le tableau Kanban doit ressembler à ça ?▲

2-16-1. Ressemblances▲

2-16-2. Différences▲