Kanban et Scrum - tirer le meilleur des deux

Si vous avez déjà été d'astreinte 24h/24 et 7j/7, vous avez une bonne idée de ce que l'on ressent lorsqu'il faut gérer un environnement de production. On attend de vous d'être capable de régler un problème au milieu de la nuit, que vous soyez ou non à son origine. Personne ne sait quoi faire, c'est pourquoi on vous appelle. C'est un sacré défi puisque ce n'est pas vous qui avez construit le matériel, les drivers, le système d'exploitation ou les logiciels spécifiques. Vos possibilités se limitent le plus souvent à confiner le problème en limitant ses impacts et à conserver les traces nécessaires, en espérant que la personne responsable du problème dont vous avez été le témoin soit capable de le reproduire et de le résoudre.

La réactivité et la capacité à résoudre les problèmes sont fondamentales, ceci avec rapidité et précision.

En 2008, l'un de nos clients, une société scandinave de développement de jeux, est passé par toute une série d'améliorations de ses processus. L'une de ces améliorations concernait le déploiement de Scrum au sein de l'organisation et l'élimination progressive des problèmes freinant l'équipe dans la livraison du logiciel. Lorsque la livraison du logiciel a commencé à devenir plus fluide et que la performance s'est accrue, la pression a commencé à monter en aval du côté du pôle exploitation. Auparavant, les équipes d'exploitation ne se sentaient pas vraiment concernées, aujourd'hui elles sont de plus en plus impliquées et jouent un rôle actif dans le processus de développement.

Se contenter d'aider les équipes de développement n'était pas suffisant. Si nous avions continué à nous concentrer uniquement sur les équipes de développement, cela aurait pu provoquer des retards dans l'amélioration, indispensable, de l'infrastructure, menée par les équipes d'exploitation. L'amélioration était donc nécessaire dans les deux domaines.L'amélioration était donc nécessaire dans les deux domai

En outre, les progrès réalisés dans les équipes de développement faisaient que les managers étaient de plus en plus sollicités pour aider à analyser les (nouvelles) idées et en donner leur feedback. Ils avaient donc de moins en moins de temps pour la priorisation des tâches au fil de l'eau et la résolution des problèmes. L'équipe de management a donc réalisé qu'elle devait réagir avant que la situation devienne complètement ingérable.

Un bon point de départ a été de questionner les équipes de développement, qui sont les clients du service exploitation.

3-3-1. Vision de l'exploitation par les développeurs▲

3-3-2. Vision du développement par l'exploitation▲

"Pourquoi n'utilisez-vous pas les avantages de la plate-forme existante ?"
"Faites des versions beaucoup plus simples à livrer !"
"Nous ne comprenons pas que vous produisiez du logiciel de mauvaise qualité !"

"Ils doivent changer" a été le leitmotiv utilisé d'un côté comme de l'autre. Il est évident que l'état d'esprit devait changer pour essayer de régler les problèmes communs. Un point positif : "Très compétent quand il s'agit de l'infrastructure" (qui indique une confiance dans les compétences de base de l'exploitant) m'a laissé penser que l'on pouvait dépasser la mentalité "nous contre eux" si l'on créait les bonnes conditions de travail. Éliminer la surcharge de travail et se concentrer sur la qualité devenait maintenant un scénario viable.

3-3-3. Pour s'y mettre▲

Comment mettre les équipes en ordre de bataille ? Il n'y avait pas de manuel pour cela. S'y prendre mal dès le départ constituait un gros risque. Mis à part le risque de se planter sur les axes d'amélioration, les personnes de la plate-forme d'exploitation à qui nous avions affaire étaient hautement spécialisées et qualifiées, difficiles à remplacer. Se passer d'eux était une trèèès mauvaise idée.

• Devions-nous simplement nous lancer ? ET assumer les conséquences au fur et à mesure ?
• Ou mener un atelier avant ?

Il était évident pour nous de démarrer par l'atelier, mais comment ? C'était un défi d'obtenir la participation de toute l'équipe d'exploitation à un atelier (qui répond si quelqu'un appelle ?). Finalement, nous avons décidé de faire un atelier d'une demi-journée, simple et basé sur des mises en situation.

3-4-1. L'atelier▲

Un des avantages de l'atelier était de faire remonter très tôt nos problèmes à la surface. C'était également l'occasion de proposer en toute confiance une séance de travail, pendant laquelle les implications pourraient être discutées directement avec les membres de l'équipe. Soyons clair : tout le monde n'était pas vraiment enthousiaste à l'idée de modifier les méthodes de travail actuelles mais la plupart des membres de l'équipe étaient prêts à essayer. Nous avons donc réalisé un atelier démontrant les principes les plus importants de Kanban avec une simulation à petite échelle.

À la fin de l'atelier, nous avons fait un vote à main levée (sur le principe du "Fist of Five"(1)) pour vérifier si les équipes étaient prêtes à se lancer dans la vie réelle. Aucune objection n'a alors été soulevée et nous avons donc obtenu le feu vert pour aller de l'avant.

Il était probable que les parties prenantes seraient également impactées par la mise en oeuvre de la démarche Kanban. Même si les changements qui allaient avoir lieu étaient faits pour améliorer les choses (l'équipe allait bientôt pouvoir répondre "non" pour un travail qui ne pourrait être terminé, axer son travail autour de la qualité et de la suppression des choses de très faible priorité dans le backlog), il était préférable d'en discuter avant avec elles.

Les parties prenantes les plus proches étaient le support de niveau 1 et les managers du département. Ces derniers ayant participé à l'atelier, ils étaient déjà d'accord pour aller de l'avant. Même chose pour les équipes de développement (qui étaient plus ou moins en attente que les choses s'améliorent d'une manière ou d'une autre). Mais, pour une équipe, celle du support, les choses étaient différentes. Leur problème le plus important était qu'ils étaient surchargés de travail. Ils assuraient notamment le support client et étaient soumis à des engagements pour répondre à tout type de demande. Ces points allaient probablement changer avec la mise en place de Kanban et l'application des limitations du TAF.

Nous sommes donc allés voir les principales parties prenantes pour présenter notre démarche, les bénéfices attendus et les impacts possibles. À mon grand soulagement, nos idées ont été généralement bien reçues, avec parfois une remarque du type "super, nous allons enfin pouvoir enterrer ces problèmes".

Une bonne façon de commencer la construction d'un tableau Kanban est de cartographier les flux de valeur. Il s'agit de visualiser la chaîne de valeur et de fournir un aperçu de l'état d'avancement des travaux, de l'écoulement du flux et du temps passé dans le système (temps de cycle).

Mais nous avons commencé par quelque chose de beaucoup plus simple ; nous avons dessiné avec le manager un simple tableau Kanban sur le papier. Nous l'avons révisé plusieurs fois de suite puis nous avons démarré avec. Les questions que nous nous sommes posées dans cette phase étaient les suivantes :

• Quels types de travaux réalisons-nous ?
• Qui les gère ?
• Devons-nous partager des responsabilités entre les différents types de travail ?
• Comment pouvons-nous faire face à une responsabilité partagée parmi des compétences spécialisées ?

Étant donné que les différents types de travaux ont des exigences de niveaux de services (SLAs) différents, il a semblé naturel de laisser à chaque équipe le soin de concevoir son propre tableau. Les équipes ont donc élaboré les colonnes et les lignes elles-mêmes.

La grande décision suivante fut de savoir si l'on passait par un partage de responsabilités entre différents types de travaux. "Devons-nous laisser une partie de l'équipe dédiée à la réponse aux questions directes (réactivité) et laisser le reste de l'équipe se concentrer sur les projets (pro-activité)?" Nous avons d'abord essayé le partage des responsabilités. Une des principales raisons était que nous avions identifié que l'auto-organisation et l'augmentation du nombre de personnes dans les équipes étaient indispensables pour soutenir la croissance. L'inconvénient avec ce choix était que chacun pouvait subir d'éventuelles perturbations, mais cela a été la meilleure solution que nous avons pu trouver au départ. Une petite remarque : lorsque nous avons mené l'atelier, les équipes s'étaient déjà organisées d'elles-mêmes pour traiter cette problématique. Une personne gérait les demandes immédiates et le reste de l'équipe traitait les problèmes de fond.

3-6-1. Le premier modèle Kanban▲

Vous trouverez ci-dessous le modèle de base que nous avons utilisé comme Kanban. Notez que l'équipe a décidé de gérer l'état des éléments du tableau du bas vers le haut (comme des bulles qui remontent à la surface de l'eau) plutôt que d'utiliser le modèle typique où les éléments circulent de gauche à droite.

3-6-2. Lignes utilisées▲

3-6-3. Colonnes utilisées▲

Notre première limite de TAF pour En cours était assez généreuse. Nous pensions qu'en visualisant le flux, nous verrions de façon concrète ce qui se passait et qu'il était peu probable que nous soyons en mesure de deviner la meilleure limite dès le départ. Au fur et à mesure, nous avons ajusté les limites de TAF, à chaque fois que nous avons trouvé de bonnes raisons de le faire (tout ce que nous avions à faire était de l'indiquer sur le tableau).

La première limite de TAF que nous avons utilisée était 2n-1 (n = nombre de membres de l'équipe, -1 pour encourager la coopération). Pourquoi ? C'est simple, parce que nous n'avions pas de meilleure idée :-). En outre, cette valeur nous semblait incontestable. La formule fournissait une explication simple et logique à toute personne tentant de donner du travail en surcharge à l'équipe : "... donc étant donné que chaque membre de l'équipe peut travailler sur au plus deux choses à la fois, une chose en cours et une chose en attente, pourquoi voudriez-vous qu'ils en prennent plus ?" Avec le recul, n'importe quelle limite confortable aurait fait l'affaire au démarrage. En observant le tableau Kanban, il est facile de faire ressortir les bonnes limites au fur et à mesure.

Nous avons observé qu'il était inutile de définir la limite de TAF en story points. C'était tout simplement trop difficile d'en garder la trace. La seule limite assez facile à suivre était de simplement comptabiliser le nombre d'items (= tâches parallèles).

Pour l'équipe support, nous avons défini un TAF par colonne (donc par type de travail) parce que nous avions besoin d'une réactivité plus grande si la limite venait à être dépassée.

Respecter une limite de TAF semble facile en théorie, mais très difficile dans la pratique. Cela signifie pouvoir dire "non" à un certain stade. Nous avons essayé différentes approches pour traiter ce problème.

3-8-1. En discuter devant le tableau▲

3-8-2. Créer une colonne Débordement▲

Comme dire "non" était trop agressif et retirer des items du tableau était trop compliqué, nous déplacions les items de priorité plus faible vers une colonne "débordement" sur le tableau à chaque fois que les limites de TAF étaient dépassées. Deux règles s'appliquaient dans ce cas :

1. Les items concernés n'ont pas été oubliés ; si nous avons du temps, nous les traiterons.
2. Quand nous les supprimons, nous le faisons savoir.

Tout juste deux semaines après, il était évident que les items en débordement ne seraient jamais traités ; donc, avec l'appui du manager de l'équipe, nous les avons finalement supprimés.

Nous avons décidé très tôt de ne pas ajouter sur le tableau tout le travail effectué par l'équipe. Inclure des tâches comme répondre au téléphone ou prendre un café transformerait le modèle Kanban en un monstre administratif. Nous étions là pour résoudre des problèmes et non pour en créer :-). Nous avons donc décidé d'afficher sur le tableau uniquement les tâches de taille > 1 heure, tout ce qui était inférieur étant considéré comme du "bruit". La limite de 1h a effectivement assez bien fonctionné et a été l'une des rares choses qui soit demeurée inchangée. (Nous avons dû revoir nos prévisions quant à l'impact qu'avfond, plus de détails ultérieurement sur ce sujet.)

C'est un sujet toujours ouvert, et il y a certainement plus d'une réponse :

• Estimer régulièrement.
• Estimer quand le besoin s'en fait sentir.
• Faire les estimations en jours idéaux ou en story points.
• Si les estimations sont incertaines, utiliser des tailles de T-shirt (S, M, L, XL).
• Ne pas estimer, ou estimer uniquement lorsque le coût d'un retard le justifie.

Légèrement influencés par Scrum (puisque c'est là d'où nous venions, après tout) nous avons décidé de démarrer les estimations avec des story points. Mais dans la pratique, les équipes ont traité les story points comme si c'était des heures/homme (cela leur semblait plus naturel). Au début, toutes les stories étaient estimées. Avec le temps, les managers ont appris que s'ils conservaient un nombre faible de projets menés de front, ils ne faisaient pas attendre les parties prenantes. Ils ont également appris que dans le cas d'un changement soudain, ils pourraient revoir les priorités et traiter le problème.

Le besoin de prévoir la date de livraison n'était plus un vrai problème. Les managers en vinrent à ne plus demander d'estimations préalables. Ils ne l'ont fait que lorsqu'ils craignaient de faire attendre des personnes.

Au cours des premiers temps, un manager, stressé suite à un appel téléphonique, a promis la livraison d'un projet "avant la fin de cette semaine". Le projet étant sur le tableau Kanban, il s'avéra facile d'évaluer l'état d'avancement (comptabiliser les stories terminées) et de conclure qu'il serait réalisé à environ 25% à la fin de la semaine. Du coup, un délai supplémentaire de trois semaines semblait nécessaire. Face à ce constat, le manager changea la priorité du projet, stoppa les autres travaux en cours et rendit ainsi la livraison possible dans les délais prévus. Vérifiez toujours le tableau ! :-)

3-10-1. Que représente la taille estimée ? Le temps de cycle ou le temps de travail ?▲

Le système Kanban pose vraiment très peu de contraintes, vous pouvez travailler de toutes sortes de façons. Vous pouvez laisser l'équipe s'appuyer sur un déclenchement planifié des activités ou vous pouvez choisir de commencer une activité lorsqu'elle est suffisamment précise pour la justifier.

Nous avons décidé de programmer deux évènements récurrents :

• Le point quotidien - avec toute l'équipe, devant le tableau, pour identifier les problèmes et aider à créer une "vision transversale partagée" des tâches des membres des autres équipes.
• Le planning hebdomadaire d'itération, avec pour objectifs la planification et l'amélioration continue.

Cela a bien fonctionné pour nous.

3-11-1. Le point quotidien▲

3-11-2. La planification d'itération▲

Une fois par semaine, nous organisions une réunion pour planifier l'itération. Nous avons conservé cette fréquence d'une semaine car nous avons constaté que si nous ne prenions pas ce temps pour planifier, il était consommé par d'autres priorités :-). Et puis nous avions besoin de plus de discussions d'équipe. L'ordre du jour typique était le suivant :

• Mettre à jour les diagrammes et le tableau (les projets terminés étaient déplacés vers le "Mur des Terminés").
• Bilan de la semaine écoulée. Que s'est-il passé ? Pourquoi cela s'est passé ainsi ? Que pourrions nous faire pour améliorer les choses ?
• Ajustement de la limite de TAF (si nécessaire).
• Répartition des tâches et estimation des nouveaux projets (si besoin était).

En gros, la réunion de planification d'itération était une combinaison d'estimations et d'amélioration continue. Les problèmes de petite ou de moyenne taille étaient résolus sur le champ avec l'appui des managers de premier niveau. Mais garder le rythme sur des problèmes complexes d'infrastructure était une épreuve plus ardue. Pour gérer ça, nous avons introduit la possibilité pour chaque équipe de remonter 2 "obstacles pour l'équipe" à son manager.

Les règles étaient les suivantes :

1. Un manager peut travailler sur 2 obstacles en parallèle.
2. Si les 2 places sont prises, on peut ajouter un nouvel obstacle à condition de retirer celui d'importance la plus faible.
3. C'est l'équipe qui décide quand un obstacle est éliminé.

Ce fut un changement positif. Tout à coup, les équipes pouvaient voir que leurs managers travaillaient pour les aider, même sur des problèmes complexes. Ils pouvaient pointer le tableau des obstacles et demander "comment ça se passe ?". Ils ne pouvaient plus être oubliés ou "doublés" par une nouvelle stratégie plus prioritaire.

Un exemple d'obstacle sérieux : l'équipe exploitation n'arrivait pas à obtenir l'aide dont elle avait besoin de la part des développeurs quand ils suspectaient un bug. Ils avaient besoin d'aide pour identifier quelle partie du système était responsable du problème ; mais comme les développeurs étaient pris dans leur sprint à développer de nouvelles choses, les problèmes continuaient à s'empiler. Ce n'est donc pas étonnant que les exploitants aient eu l'impression que les développeurs ne s'occupaient pas assez de la qualité.

Quand cet obstacle a été mis en évidence, il a été remonté, d'abord au manager de premier niveau, puis plus tard au manager de département. Celui-ci a alors programmé une réunion avec le responsable des développements. Dans les débats qui suivirent, les managers décidèrent de mettre en priorité première la qualité, et ils ont imaginé une solution de support tournant, des développeurs vers les exploitants - chaque sprint, une équipe de développement serait "joignable" et se rendrait instantanément disponible pour assister l'exploitation. Après avoir obtenu le soutien de ses managers, le responsable des développements a fourni une liste de contacts aux équipes de support. Ils ont testé immédiatement la solution, suspectant qu'elle ne fonctionnerait pas. Mais les devoirs avaient été bien faits cette fois et le problème a été considéré comme résolu. Cela a été d'un grand secours pour les équipes d'exploitation.

3-12-1. Une histoire▲

3-12-2. Réinventer la planification▲

3-12-3. Approche 1 - Echanger et revoir▲

• Pour chaque projet/story, désigner une paire senior + junior pour estimer (c'est à dire une personne qui connait particulièrement bien la story et une autre qui ne la connait pas bien). Cela aide à diffuser la connaissance.
• Les autres membres de l'équipe choisissent quelle story ils veulent aider à estimer (mais avec une limite de quatre personnes par story pour conserver une discussion efficace).
• Chaque équipe d'estimation découpe sa story en tâches et, si nécessaire, l'estime.
• Puis, les équipes échangent les stories et revoient le travail des autres (une personne par équipe était "détachée" pour expliquer le travail de son équipe aux "relecteurs").
• Terminé !

En général, la session d'estimation durait environ 45 minutes et le niveau de concentration restait élevé tout au long de la réunion. 1 à 2 ajustements étaient généralement effectués lors de la rotation et revus par un ensemble de regards nouveaux.

3-12-4. Approche 2 - Revue de haut niveau puis estimationestimat▲

Deux membres expérimentés de l'équipe mènent une revue de haut niveau sur la story / le projet avant la planification. Ils analysent les solutions d'architecture et font un choix. Une fois lancée, l'équipe découpe la story en tâches en utilisant la solution proposée comme point de départ.

De nombreux points pourraient être mesurés : le temps de cycle (temps écoulé entre le moment où le besoin est découvert et celui où il est satisfait), la vélocité, les files d'attente, les burndowns... La question essentielle est de savoir quels indicateurs peuvent être utilisés pour améliorer le processus. Mon conseil est d'expérimenter et de trouver ce qui marche pour vous. Nous avons appris que les burndown charts étaient surdimensionnés pour les petits projets de 1 à 4 semaines. La progression peut être examinée en regardant le tableau Kanban (nombre de stories qui sont dans le backlog et nombre de stories qui sont terminées).

Nous avons commencé par mesurer la "Vélocité par type de travail" et la "Longueur des files d'attente". La vélocité par type de travail est facile à mesurer et est suffisante. La longueur des files d'attente est un indicateur de premier plan, car il peut être repéré instantanément (une fois que vous savez où regarder).

Nous n'avons pas utilisé de diagramme de flux cumulé, mais cela aurait été intéressant.

Nous n'avons pas utilisé les diagrammes de flux cumulés puisque le tableau Kanban et le graphe de vélocité nous ont donné suffisamment d'informations, tout au moins dans nos premières phases de montée en compétence. Les goulets d'étranglement, l'inégalité du flux et la surcharge de travail ont pu être facilement identifiés et la résolution de ces choses-là nous a occupés pendant les six premiers mois.

Trois mois après l'introduction de Kanban, l'équipe d'administration système a été nommée "équipe la plus performante" du département informatique par le management. Dans le même temps, cette équipe a également été élue comme l'une des trois "expériences les plus positives" au cours de la rétrospective de la société, une manifestation à l'échelle de l'entreprise qui a lieu toutes les six semaines. C'était la première fois qu'une équipe se plaçait au top 3 ! Ceci alors qu'il y encore 3 mois, cette équipe était reconnue comme un goulet d'étranglement dont la plupart des gens se plaignaient.

La qualité de service s'est clairement améliorée. Comment est-ce donc arrivé ?

Le moment essentiel a été quand tout le monde a commencé à bouger ensemble dans le même sens. Les managers ont donné une orientation claire et ont protégé l'équipe du boulot qui ne la concernait pas, et les équipes se sont engagées sur la qualité et les délais. Il a fallu environ trois à quatre mois pour en arriver là, mais après tout s'est passé en douceur. Ce n'est pas comme si tous les problèmes avaient disparu dans le monde (si c'était le cas, on serait tous au chômage n'est-ce pas ? :-) ) - mais nous avons dû relever de nouveaux défis tels que "comment garder une équipe motivée pour s'améliorer (quand elle n'est plus le goulet d'étranglement) ?"

Une pièce importante du puzzle de l'auto-organisation a été l'introduction du principe "un contact de l'exploitation par équipe". Cela signifie que chaque équipe de développement se voyait affecter leur propre interlocuteur au support exploitation. Kanban a rendu cela possible en permettant aux membres de l'équipe d'exploitation de s'auto-organiser autour du travail, de prévenir la surcharge de travail et de faciliter l'amélioration continue. Avant, une personne au hasard dépilait un problème de la file d'attente, essayait de le résoudre au mieux de ses compétences et enchaînait sur le problème suivant. Tout défaut de communication signifiait qu'il fallait tout recommencer avec une nouvelle demande de support. Lorsque le principe "un-pour-un" a été mis en place, l'équipe support eut tout à coup l'opportunité de répondre rapidement lorsque des données erronées et des problèmes de qualité menaçaient le système.

Pour anecdote, après un certain temps, les procédures de communication ont évolué vers des méthodes plus personnalisées : les membres de l'exploitation ont commencé à utiliser la messagerie instantanée avec les développeurs qu'ils connaissaient bien, le courrier électronique pour ceux qui écrivaient mieux qu'ils parlaient et le téléphone si c'était le moyen le plus rapide pour résoudre le problème :-)

Avant

Après

Quels sont alors les impacts sur la performance de l'équipe ?

Ainsi, l'équipe a affiché une tendance globalement positive. Dans le même temps l'équipe a lourdement investi dans le partage des connaissances en utilisant la programmation en binôme.

Jetons un coup d'oeil à la performance de l'équipe des DBAs :

La vélocité totale a une tendance à la hausse même si la variance est significative. Ce qui a conduit l'équipe à surveiller le nombre de petites tâches de support (tâches normalement trop petites pour être affichées sur le tableau Kanban). Comme vous le pouvez le constater, le graphique montre une corrélation invsupport et la vélocité totale.

L'équipe de support ayant commencé à appliquer Kanban plus tard que les deux autres équipes, nous n'avons pas encore de données fiables pour le moment.

Mûrissement

Lorsque nous avons commencé, trouver les zones de problèmes a été facile. Mais trouver les plus grandes opportunités d'amélioration a été dur. Le tableau Kanban nous a apporté un tout nouveau niveau de transparence. Non seulement il était plus facile de repérer les problèmes, mais d'importantes questions ont été soulevées concernant le flux de travail, la variance et les files d'attente. Nous avons commencé à utiliser les files d'attente comme un outil pour isoler les problèmes. Quatre mois après avoir commencé à appliquer Kanban, les gestionnaires partaient à la chasse aux générateurs de variance qui perturbaient leurs équipes.

Comme les équipes évoluaient d'un niveau individuel vers un niveau auto-organisé, les managers ont réalisé qu'ils étaient confrontés à de nouveaux défis en termes de leadership. Ils devaient davantage s'occuper des problèmes des gens - traiter les réclamations, définir des objectifs partagés, résoudre les conflits et négocier des accords. Ce ne fut pas une transition sans douleur - ils ont ouvertement fait remarquer que l'apprentissage exigeait compétences et énergie. Mais ils ont relevé le défi et ont fini par devenir de meilleurs leaders.

3-15-1. Des contraintes émergent lorsque le travail à faire diminue▲

Toutes les équipes ont commencé avec des limites de TAF assez confortables. À cette époque, les efforts ont été employés pour créer un flux de travail et pour s'assurer que l'organisation obtenait le soutien dont elle avait besoin.

Au début, les managers voulaient avoir de nombreux projets en parallèle, mais après quelques semaines il devint évident qu'il n'y avait pas la capacité suffisante pour traiter les projets de plus faible priorité. Il a suffi de jeter un rapide coup d'oeil au tableau pour constater qu'aucun travail n'était démarré sur les projets de faible priorité. Cela a incité les managers à réduire le nombre de projets par équipe.

Au fil du temps, le flux devenant de plus en plus stable pour les travaux prioritaires, nous avons commencé à resserrer les limites de TAF. Cela a été réalisé en réduisant le nombre de projets en cours (colonnes) de trois à deux, puis à un. À ce moment là, des contraintes extérieures à l'équipe commencèrent à apparaître. Certains membres d'équipes signalèrent qu'ils ne recevaient pas d'aide dans les temps, si bien que les managers commencèrent à y prêter attention.

Une autre chose qui est remontée à la surface a été à quel point la mauvaise qualité des livrables produits par d'autres équipes pouvait dégrader les performances. Il a été difficile de maintenir un flux de travail régulier et rapide lorbesoin d'être corrigés.

Ces problèmes étaient connus avant que nous commencions. La question était alors de savoir "quel problème traiter en premier" et ceci avec l'accord de tout le monde. À l'aide du tableau Kanban, tout le monde a pu se rendre compte du problème spécifique qui impactait le flux, ce qui a permis de bénéficier de l'effort commun pour traiter la question globalement quelles que soient les différentes entités en présence.

3-15-2. Le tableau va changer en cours de route, ne figez pas sa conception▲

Tous les tableaux Kanban changent en cours de route. La conception du tableau est généralement revue deux ou trois fois avant qu'une équipe le considère fonctionnel. Donc, investir beaucoup de temps dans la première version du tableau est sans doute inutile. Assurez-vous que vous pouvez réorganiser le tableau facilement. Nous avons utilisé des bandes de ruban noir pour les bordures du tableau. C'était facile à réorganiser et utilisable aussi bien sur les murs que sur les tableaux blancs. Un autre moyen possible est de dessiner le tableau avec des marqueurs épais (mais assurez-vous qu'ils soient effaçables ! :-) )

Vous trouverez ci-dessous un exemple typique d'une optimisation de la conception d'un tableau. L'ordre des priorités changeaient souvent au début, donc afin d'éviter d'avoir à déplacer des colonnes entières de post-its, l'équipe a choisi d'afficher un numéro de priorité au dessus de chaque colonne.

3-15-3. N'ayez pas peur d'expérimenter et d'échouer▲