Table des matières
Introduction à Kanban
1603 : les débuts du Kanban
En 1603, après les conflits militaires quasi incessants du XIVe siècle et les troubles sociaux du Japon, le pays est entré dans une période de stabilité et de croissance économique. Avec la prospérité de l’économie japonaise, les rues des villes se sont remplies de boutiques et d’entreprises locales qui cherchaient à attirer l’attention et à sensibiliser les clients. C’est dans ces rues qu’est né le terme Kanban.
Kanban vient de deux mots japonais : « Kan », qui signifie signe, et « Ban », qui signifie tableau. Les rues et les magasins devenant de plus en plus fréquentés, les commerçants ont commencé à fabriquer des panneaux personnalisés pour attirer l’attention des passants et les informer des services qu’ils proposaient.
Progressivement, les Japonais ont commencé à utiliser ces cartes sous différentes formes, de sorte qu’il est très courant de trouver des cartes Kanban en forme de poisson pour les magasins de pêche, ou en forme de tuyau en bois pour les magasins de pipes.
Toutes ces cartes avaient un point commun et, par rapport aux cartes Kanban que nous connaissons aujourd’hui et que nous visualisons dans nos outils de travail tels que Jira, elles communiquent un message de manière claire et concise. Dans le cas présent, le message consistait à savoir combien de personnes se trouvaient à l’intérieur des magasins ou, en d’autres termes, à contrôler la capacité des espaces publics ou des magasins.
1940 : La production allégée chez Toyota
Ne produisez que ce dont vous avez besoin, quand vous en avez besoin et dans la quantité nécessaire (Taiichi Ōno).
Dans les années 1940, Toyota n’aurait jamais imaginé devenir le géant industriel qu’il est aujourd’hui. Après la Seconde Guerre mondiale, l’industrie automobile stagne. Toyota se retrouve dans l’incapacité de rivaliser avec les constructeurs américains tels que Ford, l’entreprise ne faisant que des pertes. Ne réalisant pas de bénéfices, elle ne pouvait pas non plus embaucher davantage de personnel. C’est alors que le PDG de Toyota, Kiichiro Toyoda, s’est rendu compte que l’écart entre son entreprise et les Américains (les Américains produisaient dix fois plus) ne serait pas comblé par l’embauche de personnel supplémentaire, la solution étant un peu plus complexe.
Toyota s’est engagé à innover et à optimiser l’organisation du travail. Ce changement de culture d’entreprise a ouvert la voie à Taiichi Ōno, un jeune ingénieur industriel. Ōno avait un caractère strict, que nous appellerions « doux mais ferme », ce qui lui a permis de gravir rapidement les échelons de la hiérarchie de l’entreprise. En 1949, il devient directeur de l’atelier d’usinage, où il commence à expérimenter de nouveaux outils et principes d’organisation du travail. En 1954, il est promu au poste de directeur.
Ōno a identifié et catégorisé 7 types de déchets, connus sous le nom de Muda chez Toyota :
Parmi les sept gaspillages identifiés par Ōno, la surproduction et les stocks de matières premières étaient ceux qui le préoccupaient le plus. Qu’a fait Ōno après cette analyse ? Produire ce qui est nécessaire quand c’est nécessaire. Une réponse logique pour le monde d’aujourd’hui, mais révolutionnaire dans les années 1950.
Il fallait donc réduire les stocks au minimum tout en garantissant un flux de travail fluide tout au long du processus. Mais comment identifier le moment où un nouveau produit est nécessaire ? Et surtout, comment alerter la chaîne de production et les fournisseurs de matières premières ? Inspiré par les magasins de détail et leurs cartes Kanban, Ōno a décidé de visiter les chaînes de supermarchés Piggly Wiggly en 1956 et a été impressionné par la façon dont ils gardaient les étagères approvisionnées avec juste la bonne quantité de produits. À son retour au Japon, il a commencé à utiliser des cartes Kanban sur papier pour marquer et suivre la demande dans l’usine Toyota. C’est ainsi qu’est né le système Kanban.
Toyota utilisait des cartes Kanban sur chaque voiture finie, de sorte que lorsque la voiture était livrée au client, la carte était renvoyée sur la ligne de production. Les ouvriers ne pouvaient travailler sur une voiture que lorsque la carte identifiant une demande leur revenait dans le flux de travail, et seulement lorsque le nombre de cartes Kanban en circulation atteignait un seuil défini. De la même manière, chaque matériau utilisé dans la chaîne de production avait sa propre carte, de sorte que le signal de la demande descendait tout au long de la chaîne de production et aboutissait chez les fournisseurs externes.
Ce système a permis de réduire les stocks, d’améliorer le rendement et d’offrir une grande visibilité sur les processus. Son utilisation s’est répandue comme une traînée de poudre dans la division de l’usinage. En 1963, un plan a été élaboré pour le diffuser dans l’ensemble de l’entreprise et, peu après, il a été adopté dans la quasi-totalité des processus de Toyota.
Toyota est passé d’une exploitation déficitaire au concurrent mondial qu’il est aujourd’hui. Ōno a gravi les échelons de l’entreprise et est devenu vice-président exécutif en 1975. Son travail a donné naissance à la nouvelle signification du Kanban et a jeté les bases techniques modernes de la gestion, connues sous le nom de système de production Toyota.
2003 – 2008 : Kanban dans l’industrie du logiciel
Au fur et à mesure que le système de production Toyota gagnait en popularité, les chefs de projet de différents types d’industrie ont essayé d’appliquer le système dans leur travail.
À cette époque, la gestion de projet dans le monde du logiciel s’éloignait progressivement des processus lourds et inefficaces pour adopter une approche plus légère et plus agile. C’est en 2001 qu’a été publié le Manifeste Agile, qui prône, entre autres, l’acceptation des changements d’exigences et la livraison fréquente de logiciels fonctionnels. Toutefois, le Manifeste ne précise pas comment y parvenir. C’est alors que plusieurs systèmes de gestion ont commencé à combler cette lacune, les plus connus étant Scrum, eXtreme Programming (XP) et Lean Software Development.
Ces trois méthodes de travail ont eu un impact significatif sur ce qui allait devenir la méthode Kanban.
- ScrumDe nombreuses équipes Scrum utilisent des tableaux avec des cartes d’histoires d’utilisateurs (US) pour afficher et visualiser les informations. Lors de la planification du sprint, chaque US ou fonctionnalité était écrite sur une carte séparée. Ensemble, ces cartes formaient ce que nous appelons le backlog du sprint et étaient placées sur un grand tableau dans un bureau où toute l’équipe pouvait les voir. Chaque membre de l’équipe pouvait s’approcher du tableau, regarder les US et choisir la carte sur laquelle il allait travailler. Lorsqu’il avait terminé son travail, il remettait la carte sur le tableau, avec les mots barrés. Ce système était simple mais efficace. Il a permis une grande visibilité des progrès, une synchronisation du travail entre les programmeurs et une amélioration du flux de travail, chaque développeur pouvant choisir le type de fonctionnalité sur lequel il se sentait le plus à l’aise.
- Développement de logiciels allégésDéveloppement de logiciels allégés : En 2003, Mary et Tom Poppendieck ont publié le livre Lean Software Development : An Agile Toolkit, dans lequel ils ont transposé les principes de fabrication allégée du Toyota Production System au développement de logiciels et au travail de la connaissance. L’ouvrage se concentre sur l’élimination des déchets, la cartographie de la chaîne de valeur et les systèmes à flux tirés. En 2007, les mêmes auteurs ont publié Implementing Lean Software Development : From Concept to Cash, qui explore plus avant l’utilisation de la théorie des files d’attente pour réduire les délais d’exécution des logiciels et les tableaux Kanban en tant qu’éléments de l’espace de travail visuel. En 2005, Jim Sutton et Peter Middleton ont publié Lean Software Strategies, qui identifie les 5 principes de la production allégée dans le développement de logiciels :
- Définir la valeur
- Cartographie de la chaîne de valeur
- Mise en œuvre du flux
- Maintien d’un processus d’appel d’offres
- Rechercher des possibilités d’amélioration
- Gestion agile : outre Scrum et Lean, d’autres concepts sur la manière dont les équipes peuvent devenir plus agiles ont également été explorés. En 2004, David Anderson a publié le livre Agile Management for Software Engineering : Applying the Theory of Constraints for Business Results, qui couvre des concepts tels que le flux, le goulot d’étranglement, le contrôle visuel et le diagramme de flux cumulatif, tous incorporés par la suite dans la méthode Kanban. À cette époque, les équipes utilisant les tableaux Scrum ont adopté ces nouvelles techniques et réorganisé leurs tableaux en introduisant des colonnes représentant les différentes étapes du travail, donnant ainsi naissance aux tableaux Kanban.
Tableaux Kanban, combinés avec :
- Méthodes de développement de logiciels allégés et gestion agile ;
- Programmation par tirage au sort ;
- Limiter le travail à la capacité
- Mesurer le débit
…a donné naissance au développement logiciel de type Kanban. Ce premier Kanban a été accepté comme un système à part entière, car il permettait de réaliser toutes les choses pour lesquelles Scrum n’était pas particulièrement efficace, comme la réduction de la durée du cycle entre la demande du client et la livraison, et la garantie d’un flux de travail régulier.
Alors que l’adoption du développement logiciel Kanban progressait lentement, quelques pionniers ont contribué à faire connaître le concept et à façonner son avenir.
Microsoft a été l’un des premiers à introduire les principes Kanban. Pour accroître la productivité, elle a ajouté des éléments de Scrum et de Kanban en tant qu’extension du modèle existant de l’équipe de travail. Équipe d’experts et le modèle de la prison à bogues. C’est ainsi qu’est né le premier projet Scrumban en 2004.
David Anderson, Dominica DeGrandis, Corey Ladas et Daniel Vacanti ont introduit le système Kanban chez Corbis en 2007, où ils ont introduit le concept de couloirs de nage pour garder ensemble les éléments de travail connexes. Le succès de la mise en œuvre et de la diffusion du système chez Corbis a suscité l’intérêt d’autres entreprises pour la méthode Kanban.
Karl Scotland a entendu parler de la méthode Kanban lors d’une conférence Agile en 2007 par David Anderson. Il a donc décidé de l’introduire dans son équipe chez Yahoo ! car ils avaient un problème de durée de sprint avec Scrum. La mise en œuvre a été si réussie que Karl est devenu l’un des premiers et plus éminents défenseurs de la méthode Kanban.
2009 : l’année en or pour Kanban
En janvier 2009, Corey Ladas a publié le livre Scrumban : Essays on Kanban Systems for Lean Software Development, une tentative de fusionner Scrum, Lean et Kanban.
En avril de la même année, Henrik Kniberg publie Kanban vs. Scrum : un guide pratique L’article couvre les principes du Kanban d’une manière facile à comprendre.
En mai, lors de la conférence Lean Kanban 2009 organisée par Anderson à Miami, les derniers développements dans l’application du Lean Thinking au développement de logiciels ont été présentés. À la suite de cette conférence, la société informelle WIP Limited a été créée, avec pour mission d’unifier et de diffuser les connaissances sur la méthode Kanban. Cette société a fourni une plate-forme pour l’agrégation d’articles sur Kanban, ce qui a permis de mieux faire connaître la méthode.
C’est également en 2009 qu’ont été lancées les premières applications web pour la gestion de projets et de processus d’entreprise selon la méthode Kanban : Agile Zen, Kanban Tool et LeanKit Kanban.
À partir de 2010 : Kanban pour tous
Au fur et à mesure que la connaissance et l’utilisation de Kanban se sont répandues, il est apparu clairement que Kanban fonctionne dans le développement de logiciels et dans tout processus comportant des itérations (fabrication, ventes, marketing, recrutement, etc.). Même l’armée américaine a commencé à adopter ses principes.
En mars 2010, Henrik Kniberg et Mattias Skarin ont publié Kanban et Scrum – Tirer le meilleur parti de l’un et de l’autre. En avril de la même année, David Anderson a publié Kanban : Successful Evolutionary Change for Your Technology Business. En 2011, Jim Benson et Tonianne DeMaria Barry ont publié Personal Kanban. Peu à peu, de nombreux autres livres et articles en ligne sur Kanban ont commencé à paraître, documentant les expériences individuelles et leurs diverses applications.
En 2016, Essential Kanban Condensed a été publié, distillant les 5 pratiques de cette méthode que nous allons expliquer ci-dessous.
Kanban pour quoi faire ?
Comme nous l’avons vu dans la section précédente, la méthode Kanban peut être utilisée dans divers contextes pour améliorer la gestion et le flux de travail.
Déterminez si Kanban convient à votre équipe
Dans la méthodologie Scrum, après la planification du sprint, le carnet de commandes est gelé, de sorte qu’aucune modification ne peut y être apportée. Cet état dure généralement une quinzaine de jours, ce qui peut être source de frustration tant pour les développeurs que pour les clients finaux.
Que faire en cas d’urgence et si une fonction spécifique doit être mise en œuvre le plus rapidement possible ?
Que faisons-nous de tous les bogues découverts dans le produit réel : les clients finaux doivent attendre entre deux semaines et un mois pour qu’ils soient corrigés ?
Comment gérer les processus de nature plus dynamique, tels que le marketing de sites web ou l’administration de serveurs ?
La méthode Kanban, avec ses tableaux Kanban et l’accent mis sur le flux, apporte une réponse à ces doutes, en fournissant un moyen très structuré, visible et flexible de gérer le travail.
Voici d’autres questions que vous pouvez poser à votre équipe pour déterminer si le modèle Kanban est adapté à vos besoins :
- Du point de vue d’un maître agile, d’un coach agile ou d’un propriétaire de produit :
- L’équipe sait-elle comment identifier et visualiser le flux de travail ?
- Y a-t-il des goulets d’étranglement et sont-ils identifiés ?
- Sont-ils conscients du travail qu’ils accomplissent les uns avec les autres ?
- Exigent-ils de la flexibilité pour s’adapter à la demande imprévisible qui les met constamment en difficulté ?
- Quel niveau de structure recherchez-vous dans la gestion des projets et des processus ?
- Questions à poser à l’équipe :
- Avez-vous des difficultés à gérer vos tâches Sprint ?
- Quelle méthode d’estimation utilisez-vous et pensez-vous qu’elle fonctionne pour vous ?
- Disposez-vous d’un tableau de bord visible et partagé, et le comprenez-vous ?
- Considérez-vous qu’il y a de la transparence et de la communication au sein de l’équipe ?
- Sommes-nous prêts à nous engager dans l’amélioration continue et à commencer à expérimenter le changement ?
- Souhaitez-vous avoir plus d’autonomie et de responsabilité dans la gestion de votre travail ?
- Quels sont les aspects du processus actuel que vous souhaiteriez améliorer ou optimiser ?
- Existe-t-il des accords d’équipe ?
- Partagez-vous la même vision et la même compréhension de chaque statut professionnel ?
Kanban est bien plus qu’un joli tableau avec des posits colorés qui bougent tous les jours. C’est un outil qui nous permet d’optimiser un processus en le visualisant. Il nous aide à améliorer les flux de travail dans n’importe quel processus de production.
Les cinq pratiques présentées dans le livre Essential Kanban Condensed sont les suivantes :
- Visualiser le flux de travail
- Limiter les travaux en cours
- Mesurer et gérer les flux
- Définir des politiques explicites
- Mettre en place des boucles de rétroaction
- Evolution expérimentale pour l’amélioration collaborative
1-Visualiser le flux de travail
La visualisation du flux de travail est cruciale et constitue l’un des principes essentiels de la méthode Kanban. La visualisation est synonyme de transparence. En disposant d’un tableau unique où tous les éléments de travail sont visibles par l’équipe et l’organisation, tout le monde sait clairement ce qui doit être fait, ce sur quoi moi ou mes collègues travaillons, quand le travail est censé être terminé et ce que nous avons livré.
La visualisation vous aidera à bien comprendre le fonctionnement actuel de l’équipe, ce qui vous permettra de comprendre pourquoi les choses sont faites de cette manière et de prendre des décisions concrètes et objectives pour les améliorer.
Comment visualiser le flux de travail ?
Le flux de travail est la séquence d’étapes que traversent les tâches ou les produits depuis leur lancement jusqu’à leur achèvement ou leur livraison. Dans le système Kanban, la visualisation du flux consiste à cartographier les différentes étapes de travail sur les colonnes du tableau Kanban et à suivre les éléments de travail au fur et à mesure qu’ils passent par ces états. Le simple fait de nommer ces états peut révéler des faits que vous ignoriez sur votre flux, voire détecter des goulets d’étranglement.
Les étapes de l’identification de la chaîne de valeur sont les suivantes :
- Identifier le flux: la cartographie des flux est le processus par lequel nous nommons les états par lesquels passe la tâche, les états qui ajoutent de la valeur. Vous pouvez vous aider en verbalisant les activités (analyser, développer, tester, etc.). Le flux doit être clair et permettre de savoir quelles sont les actions sur lesquelles il faut se concentrer et celles qu’il faut minimiser parce qu’elles n’ont pas de sens pour le client final, ce que nous appellerions le « gaspillage ».
- Identifier la portée du travail: une fois le flux de valeur dessiné, l’équipe doit décider des parties qu’elle contrôle, de ce sur quoi elle veut se concentrer et de la manière dont elle le visualisera sur un tableau Kanban. Si nous considérons le flux comme une carte, nous devons marquer le chemin le long duquel les tâches se déroulent. Plus l’équipe travaillant dans le flux est soudée et uniforme, plus il sera facile de gérer le travail. Essayez de ne pas inclure dans le processus des étapes sur lesquelles l’équipe n’a pas d’avis ou d’impact, car cela créerait de l’incertitude et de la confusion.
- Associez les étapes du flux de travail aux colonnes d’un tableau de bord: vous pouvez vous appuyer sur un tableau de bord physique visible au bureau ou utiliser un outil numérique tel que Jira. Divisez le tableau en colonnes, dont chacune correspondra à une étape du flux, de droite à gauche. Si vous avez différentes classes de service, vous pouvez utiliser des nageoires pour les diviser en rangées horizontales.
- Définir les types de travail et ce que signifie « Terminé » pour l’équipe: la première étape consiste à définir les types de tâches sur lesquelles l’équipe travaille et à les différencier à l’aide d’icônes ou de couleurs. Assurez-vous que l’équipe sait ce que chaque couleur ou icône signifie et quelles définitions vous avez adoptées pour chaque élément de travail.
- Définir chaque élément de travail sur un modèle de carte: pour chaque élément de travail, définissez avec l’équipe les informations essentielles à voir et ce qui est attendu sur chaque carte. Différents modèles de cartes peuvent être définis en fonction des types de travail ou de produits à livrer, afin de mettre en évidence et de faciliter l’échange des informations essentielles minimales.
- Au travail !Maintenant que vous avez défini les couleurs, les formats, les icônes, les colonnes et les plans de travail, ainsi que le modèle des cartes, vous pouvez commencer à les placer dans les colonnes correspondantes du tableau, en fonction de leur état d’avancement. Dans les différentes colonnes, classez les cartes par ordre de priorité. La carte la plus urgente doit être placée en haut, suivie de la deuxième et ainsi de suite. Nous résolvons ainsi le problème classique : si tout est urgent, alors rien ne l’est.
- Suivez le flux et revoyez le processus périodiquement : le suivi du flux des statuts vous permettra de voir les goulets d’étranglement, les blocages et les états où l’équipe est surchargée. Il est essentiel que le tableau de bord soit consulté quotidiennement et que les cartes soient mises à jour pour assurer la visibilité.
2-Limiter les travaux en cours (TEC)
La limitation des travaux en cours (WIP) est une caractéristique fondamentale du système Kanban. Elle peut sembler contre-intuitive à première vue.
Sommes-nous en train de dire aux équipes de travailler moins ?
Non. Limiter le travail en cours signifie limiter le nombre de tâches pouvant être effectuées simultanément, et non limiter le travail à effectuer. Ce faisant, nous réduisons les temps d’attente et les temps de cycle.
Pourquoi limiter le travail en cours ?
- Cela favorise une culture de l’achèvement du travail: commencez à finir, arrêtez de commencer. Que préférez-vous, 40 produits à mi-chemin du lancement ou 25 produits lancés et générant des revenus ? Limiter le travail signifie se concentrer sur ces 25 produits. Limiter le travail permet de se concentrer sur les tâches, ce qui favorise un achèvement plus rapide et la monétisation. En quoi cela nous aide-t-il avec les bloqueurs ? Imaginez que votre équipe travaille sur 40 produits à la fois et que, en cas d’incident majeur, elle doive interrompre le travail sur ces 40 produits. Ne vaut-il pas mieux en arrêter 25 ?
- Réduire le multitâche et le chaos: si nous limitons le travail en cours, nous réduisons le bruit et nous gérons mieux le chaos. Si je vous lance une balle de tennis, vous pouvez facilement l’attraper des deux mains. Si je vous lance deux balles en même temps, vous pouvez en attraper une de chaque main, n’en attraper qu’une ou n’en attraper aucune. Et si je vous lance dix balles en même temps ? Vous n’en attraperez probablement aucune : c’est le chaos. Il en va de même si nous travaillons sur plusieurs tâches en même temps. Le fait de se concentrer en permanence sur une seule tâche améliore la qualité du travail.
Comment commencer ?
- Observez le processus et identifiez les goulets d’étranglement: regardez le tableau de bord, voyez si l’équipement est surchargé, afin d’identifier les goulets d’étranglement.
- Ajustez la limite du travail en cours : limitez le travail en cours à la capacité de l’état de flux le plus lent. Discutez avec l’équipe des raisons pour lesquelles un goulet d’étranglement se forme à cette étape (manque de ressources, autorisations, dépendances externes, etc.)
- Analysez et révisez les limites : au fur et à mesure que le processus évolue, que l’équipe s’agrandit, se rétrécit ou change, vous devrez peut-être ajuster les limites.
3-Mesurer et gérer le flux
Mais qu’est-ce que le flux ?
Le flux est le chemin parcouru par le travail dans les différents départements ou à différents niveaux de la production. C’est l’expérience unique de chaque travail qui passe par le processus.
Une tâche peut-elle se déplacer en douceur à travers les états, ou peut-elle s’interrompre dans un état ?
Vous avez probablement été frustré à un moment donné lorsque vous avez commencé une tâche et que vous avez dû l’interrompre une ou plusieurs fois parce que vous aviez besoin de quelqu’un pour confirmer un détail, pour obtenir des autorisations, ou même parce qu’une autre tâche plus urgente s’était présentée et que vous deviez la résoudre immédiatement. Dans ces cas-là, le flux est interrompu.
Dans la première pratique, nous avons vu comment visualiser le flux, et dans la seconde, comment les tâches se déplacent dans le flux. En mesurant et en gérant le flux, nous analysons l’impact de ces deux routines sur le flux et nous l’améliorons.
Comment la mesurer ?
Avec des réunions quotidiennes ou Daily Kanban. Lors de ces réunions, qui ont généralement lieu le matin à la première heure et durent de 30 à 45 minutes, vous analysez la manière dont le travail passe d’un état à l’autre. Vous pouvez aider l’équipe à déterminer le temps nécessaire pour qu’une tâche passe d’une colonne à l’autre. Lorsque des tâches sont bloquées ou coincées dans des colonnes, nous devons nous demander pourquoi. À partir de là, nous pouvons commencer à réfléchir aux mesures à prendre pour y remédier.
L’important n’est pas que les tâches se déroulent rapidement, mais qu’elles se déroulent sans heurts du début à la fin, c’est-à-dire sans blocages.
Je propose quelques questions à poser dans le Daily Kanban :
- Quelqu’un est-il bloqué ?
- Que puis-je/nous pouvons faire pour vous aider à obtenir le déblocage ?
Quels sont les indicateurs que je peux utiliser ?
- Organigramme cumulatif: cette mesure vous permet de connaître la quantité de travail en cours dans chaque état. L’uniformité de ce diagramme vous indiquera le degré d’uniformité et de prévisibilité de votre équipe.
- Lead Time et Cycle Time: Le Lead Time mesure le délai de livraison, c’est-à-dire qu’il calcule la moyenne du temps écoulé entre le début du travail sur une tâche(En cours) et sa livraison(Terminée). La durée du cycle mesure le temps qui s’écoule entre le moment où la tâche entre en tant que demande dans le carnet de commandes(À faire) et le moment où elle est livrée(Terminée). Grâce à ces deux mesures, vous serez en mesure de connaître et de prévoir le temps qu’il faut à l’équipe pour produire.
La gestion et la mesure des flux vous aideront :
- Améliorez le processus global et cessez d’éteindre les incendies ;
- Améliorer la prévisibilité du processus ;
- Faire mûrir le processus et vous aider à comprendre qu’il est moins important ; et
- Des temps objectivement prévus.
4-Définir des politiques explicites
Les gens ont tendance à faire des suppositions sur tout ce qui les entoure. Parfois de manière incohérente, parfois de manière contradictoire. Cela conduit souvent à des malentendus et à un travail d’équipe inefficace. Le processus itératif et la qualité de l’exécution de chaque étape sont les garants de la réussite du travail accompli. Il guide également l’équipe sur la manière de prendre des décisions qui lui permettent de faire avancer le processus de la meilleure façon possible.
Qu’entend-on par » politique » dans le cadre de Kanban ?
Une politique Kanban se réfère à une compréhension commune de ce qui doit être fait à chaque étape du travail afin de passer à la suivante. L’objectif ultime est de faire en sorte que cette politique devienne une routine pour l’équipe, afin de l’aider à maintenir le flux.
Veuillez noter ce qui suit :
- C’est nous qui possédons le processus, et non l’inverse. Les processus ne nous appartiennent pas.
- Soyez pragmatique dans la définition des politiques.
- Créez un contrôle visuel qui vous permette de voir quel travail est en cours et quelles sont les étapes qui suivent chaque statut.
- Les politiques doivent aider les équipes à s’organiser elles-mêmes et à développer des relations.
Considérez les politiques de votre équipe comme le Golden Gate Bridge – elles doivent être solides pour que le travail se déroule sans heurts et sans incidents futurs. Lorsque vous constatez que les tâches ont tendance à se bloquer à un moment donné, saisissez l’occasion de poser des questions sur ce que nous pouvons améliorer ou introduire pour que cela ne se produise plus.
Les politiques doivent définir de manière simple et visuelle ce qui doit être fait dans chaque État. Les questions suivantes peuvent vous aider à établir des politiques avec votre équipe :
- L’équipe est-elle au clair sur le déroulement des opérations, sur le point de départ et le point d’arrivée d’une tâche ?
- L’équipe connaît-elle les étapes du contrôle de qualité ?
- L’équipe comprend-elle la même chose que « terminé » à chaque étape du processus ?
- L’équipe sait-elle comment hiérarchiser une tâche urgente et quelles en sont les implications pour elle et pour le flux ?
- L’équipe sait-elle comment gérer les tâches non planifiées et comment les intégrer dans le flux de travail ?
- Comment gérez-vous les incidents que vous rencontrez au cours du processus ? Arrêtez-vous ce que tout le monde est en train de faire et réparez-vous l’erreur ? Remettez-vous la tâche de l’incident dans le carnet de commandes ?
5 – Mettre en place des boucles de rétroaction
« Kanban devrait conduire à une amélioration quotidienne, à une amélioration pour tous et à une amélioration partout. (Masaaki Imai)
Kanban est une méthodologie qui considère chaque itération comme une nouvelle opportunité d’amélioration. Avec Kanban, vous n’avez pas besoin de changer immédiatement, mais de commencer exactement là où vous êtes, simplement en observant, à partir de là, vous pouvez travailler sur l’approche en 5 étapes de la théorie des contraintes :
- Identifiez les goulets d’étranglement: examinez le tableau de bord et la façon dont le travail se déroule afin d’identifier les points où le flux de travail change radicalement et stagne.
- Exploiter les goulets d’étranglement : les goulets d’étranglement n’ont pas la même capacité que les autres états de travail. Sachant que la vitesse à laquelle le goulet d’étranglement accomplit le travail est la vitesse à laquelle l’ensemble du système accomplit le travail, décidez de la meilleure façon d’affecter des ressources à cet état plus lent. Faites-le à un rythme qui ne submerge pas le flux ou l’équipe.
- Tout subordonner aux goulets d’étranglement: le flux de travail et les politiques établies doivent être synchronisés avec le rythme du processus plus lent, afin d’éviter ou de minimiser les goulets d’étranglement.
- Lever les goulets d’étranglement: vous devrez renforcer l’État en investissant dans des améliorations telles que les ressources, le plafonnement de l’État ou d’autres alternatives que vous envisagez.
- Observez les goulets d’étranglement: il est important de surveiller le processus. Les goulets d’étranglement étant fréquents, vous devrez répéter les étapes 2 à 5 pour les résoudre.
L’élimination des déchets ou Muda vous aidera à analyser les tâches actuelles dans la chaîne de valeur et à identifier celles qui n’ajoutent pas de valeur directe à votre produit ou projet. Si votre équipe répond « on a toujours fait comme ça » lorsque vous l’interrogez sur une étape, il est temps de remettre en question l’objectif et de le modifier.
Il est important qu’en tant que dirigeant, vous identifiiez les gaspillages et fassiez la distinction entre les gaspillages nécessaires et les gaspillages inutiles. La réduction des activités qui ne sont pas directement liées à la valeur du produit vous permettra de vous améliorer.
La confiance du client est acquise lorsqu’un service est fiable et prévisible (W. Edwards Deming).
6-Évolution expérimentale pour l’amélioration collaborative
Pour s’aligner sur l’amélioration continue du Kanban, nous pouvons utiliser les cycles PDCA.
Les cycles courts du PDA sont basés sur :
- Planifier: une activité à améliorer est identifiée et communiquée à l’équipe. Idéalement, toutes les personnes concernées devraient être incluses dans le processus d’amélioration.
- Faire: à ce stade, le plan de l’étape précédente est exécuté. Cela doit être conforme à la mise en œuvre de politiques et de procédures explicites. Prenez des mesures tangibles issues de l’étape précédente.
- Vérification: évaluez les mesures prises à l’étape précédente. Reliez-les à la gestion et à la mesure du flux Kanban de votre équipe.
- Agir: nous entendons par agir le fait d’évaluer si les changements que nous avons apportés au cours de l’étape précédente ont produit des résultats positifs ou escomptés. Si ce n’est pas le cas, cela signifie qu’ils peuvent être éliminés, ajustés ou améliorés. Dans ce cas, nous recommencerons à partir de la première étape.
Comment démarrer
Si vous souhaitez que nous vous aidions à démarrer avec Kanban, vous pouvez nous contacter ou suivre ce guide simple.
Dans la première phase, la phase d’enquête, il est important qu’en tant que maître agile, vous rencontriez le plus tôt possible l’équipe et le propriétaire du produit pour comprendre la demande.
Analyse de la demande
En tant que maître agile, l’analyse de la demande comme première étape vous aidera :
- Comprendre le contexte: Lorsque vous intégrez une équipe, il est important que vous compreniez l’environnement dans lequel elle opère, les attentes de ses parties prenantes et les besoins de l’entreprise en ce qui concerne l’équipe. Cela vous permettra d’obtenir une première image et une première idée qui vous aideront, plus tard, à planifier et à exécuter les activités d’amélioration et la mise en œuvre de Kanban.
- Identifier les priorités: l’analyse de la demande vous permettra d’identifier les priorités de l’équipe. Vous saurez ainsi si l’équipe partage les mêmes priorités, si elles sont établies ou si vous devez les souligner. Avec des priorités claires et partagées, vous pouvez aider l’équipe à allouer efficacement les ressources et les efforts pour relever les défis auxquels elle est confrontée.
- Possibilités d’amélioration: lorsque vous effectuez l’analyse de la demande, vous, en tant que maître agile, et l’équipe elle-même, identifiez les possibilités d’amélioration dans les domaines où des changements peuvent être mis en œuvre. Il est très probable que l’équipe ait déjà une idée claire de ces domaines d’amélioration. Laissez-la parler, écoutez-la et prenez note de ses préoccupations, de ses inquiétudes et de ses idées.
- Alignement sur les objectifs de l’entreprise: une fois que vous aurez analysé la demande, vous pourrez voir si l’équipe est alignée sur les objectifs et les priorités de l’entreprise. Vous verrez également si elle apporte une réelle valeur ajoutée et, si ce n’est pas le cas, vous pourrez l’aider à modifier les flux pour qu’elle le fasse.
Réunissez toute l’équipe, de préférence au bureau. Si vous ne pouvez pas vous rencontrer en personne, faites-le en ligne et utilisez des outils visuels tels que Miro.
L’objectif de l’analyse de la demande d’équipements est de comprendre :
- Qui demande à l’équipe
- Ce qu’ils leur demandent
- Comment ces demandes leur parviennent-elles (chat Teams, courrier, demande Jira, chat informel, etc.) ?
- Quel pourcentage de la demande totale chaque demande représente-t-elle ?
- Comment ils classent chaque type de demande par ordre de priorité, soit par type de service, soit par demandeur.
Vous pouvez vous aider des questions suivantes à leur poser :
- Qui est votre « Business Owner » et centralise-t-il toutes les demandes commerciales que vous recevez ?
- Comment votre chef d’entreprise vous adresse-t-il les demandes ?
- Le propriétaire de l’entreprise hiérarchise-t-il les différentes demandes que vous recevez ?
- Si vous n’avez pas de chef d’entreprise, quels sont les chefs d’entreprise qui formulent les demandes ?
- À quels départements ou produits appartiennent ces chefs d’entreprise ou demandeurs d’emploi ?
- Par quel canal recevez-vous vos candidatures ?
- Avez-vous des réunions régulières avec eux ou un espace pour formuler des demandes et assurer le suivi des initiatives ?
- Recevez-vous des demandes de la part de votre chef de produit, de quel type de demandes s’agit-il, par quel canal vous parviennent-elles, sont-elles généralement urgentes ?
- D’autres équipes améliorent-elles vos applications ?
- De quel type d’application s’agit-il (croisée, dépendante, etc.) ?
- Par quel canal recevez-vous les demandes des autres équipes ?
- Quel pourcentage de chaque candidat représente la charge de travail habituelle de l’équipe ?
- Comment prioriser cette demande ?
- Comment gérez-vous les demandes urgentes émanant de différents candidats et disposez-vous d’une matrice ou d’accords d’équipe sur la hiérarchisation des demandes ?
- Vous synchronisez-vous avec d’autres équipes avec lesquelles vous avez des projets ou des initiatives communs ?
- Toutes les applications sont-elles dans Jira et qui crée les tickets ?
- Les tickets Jira sont-ils détaillés avec toutes les informations ? Qui détaille ces informations ? Et quand (planification, réapprovisionnement, livraisons quotidiennes, etc.)
- Si l’équipe ne sait pas exactement ce qui est demandé dans un ticket, avec qui doit-elle traiter le problème (avec le Product Owner, avec le Business Owner, seule, etc.) ?
- Avez-vous un modèle dans les tickets Jira avec les informations nécessaires (ce qui est nécessaire, pour quoi faire, les étapes à suivre, etc.)
- Les définitions de « fait » et de « prêt » sont-elles partagées et visibles dans Jira pour l’équipe ?
A l’aide de ces questions, vous enregistrerez l’analyse de la demande dans différents Posits. Il est recommandé d’utiliser des couleurs différentes selon le type d’information (demandeur, pourcentage, urgence, catégorie de la demande, etc.). ). Cela rendra l’analyse plus visuelle.
Encouragez-les à déplacer les Posits ou les flèches si nécessaire, faites-les participer au processus, ils doivent comprendre que l’exercice est également important pour eux afin de partager leur vision de la demande et leur compréhension de celle-ci.
Map Product, Business, Team
Maintenant que la demande a été cartographiée visuellement et partagée avec l’équipe, il est temps d’entrer un peu plus dans les détails sur la façon dont elle est liée aux technologies, à la prévisibilité et à l’équipement.
Grâce à cet exercice, vous pourrez faire :
- Alignement stratégique: la mise en relation de la demande avec les produits, les activités, les technologies et les équipements vous permettra de savoir si l’équipe est alignée sur la stratégie globale de l’organisation. De cette manière, nous pouvons vous aider à éviter de perdre du temps et des ressources qui ne contribuent pas directement aux objectifs de l’organisation.
- Identifier les opportunités: vous serez en mesure d’analyser les technologies actuellement utilisées par l’équipe et de voir si elles peuvent être améliorées. Vous pourrez ainsi résoudre les problèmes, améliorer l’efficacité et fournir un environnement sécurisé dans lequel les données de l’équipe sont stockées et utilisées.
- Prévision et planification: en comprenant comment les produits sont liés aux technologies, nous pouvons mieux prévoir les délais de livraison. Nous pouvons ainsi réduire l’incertitude et contribuer à garantir une livraison rapide et sans heurts.
Une partie du dessin de la demande consiste à rencontrer le Product Owner et à lui poser les questions suivantes pour chaque type de demande :
- Quel est le type de produit à fournir dans le cadre de cette demande – s’agit-il d’un fichier .csv, d’un fichier Excel, d’un produit, d’un fichier SQL, etc.
- Combien de membres du personnel travaillent sur cette demande ?
- À qui s’adresse cette demande, par quel canal et comment la transmettez-vous à l’équipe ?
- Quelles sont les technologies utilisées pour répondre à cette demande (Tableau, Redshift, OnPrem, etc.) ?
- Quelle est la prévisibilité de ce type de demande ? Est-elle standard ? Est-elle expéditive ? Y a-t-il une date limite ? Est-elle planifiable ? Reste-t-elle dans l’arriéré pour le moment où nous aurons plus de capacité ?
- Quelle est l’urgence de cette demande ? Est-il facile pour vous de la planifier pour le prochain sprint ou les deux prochaines semaines ? La classez-vous dans la catégorie des bloqueurs et mettez-vous tout en attente pour qu’elle soit livrée le plus rapidement possible ? Reste-t-elle dans le carnet de commandes ?
Il est important d’identifier les tendances et les modèles dans les demandes afin de mieux comprendre les besoins de l’entreprise.
Analyse Produits ou services de l’équipe
Dans cette étape, une fois que nous avons effectué l’analyse de la demande et que nous avons identifié comment cette demande est liée à l’entreprise et à l’équipe, nous allons analyser les produits que l’équipe possède en collaboration avec le propriétaire du produit.
L’analyse des produits ou services fournis par l’équipement vous aidera :
- Optimiser le flux de travail: afin d’identifier les domaines susceptibles d’être améliorés. En comprenant mieux comment nous gérons et livrons les produits, nous pouvons identifier les goulets d’étranglement, les inefficacités dans les processus et commencer à travailler à la résolution de ces problèmes ou à des améliorations.
- Identifier les opportunités d’amélioration: l’équipe sera consciente de la manière dont elle travaille et pourra détecter les opportunités d’améliorer l’efficacité, la qualité et la satisfaction de l’entreprise. À ce stade, nous pouvons inclure l’optimisation des processus par l’automatisation ou la refonte du flux actuel, l’introduction ou l’investissement dans de nouvelles technologies telles que l’informatique en nuage, l’adoption de nouvelles pratiques ou l’établissement ou la révision des priorités de l’équipe.
- Alignement sur les besoins de l’entreprise: en comprenant et en mettant en évidence les prestations existantes de l’équipe ainsi que leur priorité et leur impact sur l’entreprise, nous alignerons mieux le travail de l’équipe sur ces besoins et ces objectifs. De cette manière, nous nous assurons que l’équipe travaille dans les domaines qui ont le plus d’impact et de valeur pour l’organisation.
Pour ce faire, vous pouvez vous aider des questions suivantes :
- Quels sont les produits introduits par l’équipe ?
- Quels sont l’objectif et la vision du produit ?
- Quelle est la technologie utilisée pour la création et la livraison du produit ?
- Qui est le principal client du produit ? Qui l’utilisera ?
- Quelle est la fréquence de livraison du produit ?
- Dans quelle mesure le processus de livraison des produits est-il prévisible ?
- Quel retour d’information recevons-nous sur les livraisons de produits ?
- Comment gérer ce retour d’information et comment le transmettre à l’équipe ?
- L’équipe est-elle consciente des possibilités d’amélioration des processus liés aux produits ?
- Comment, en tant que PO, recevez-vous ces possibilités d’amélioration de la part de l’équipe ?
- Comment les classer par ordre de priorité ?
- Comment l’information arrive-t-elle dans l’arriéré ?
- Comment ces améliorations sont-elles communiquées aux entreprises ?
Passer à Kanban ?
Si l’équipe travaille sur Scrum et que cela ne fonctionne pas parce que la demande n’est pas planifiable, que les sprints se chevauchent, que le flux de travail n’est pas clair, que les rôles sont très spécialisés et qu’il n’y a pas de visibilité ou de transparence sur le travail effectué par l’équipe, l’adoption de la méthodologie Kanban vous aidera :
- Améliorer la flexibilité dans la gestion du travail: avec Kanban, nous bénéficions d’une plus grande flexibilité dans la gestion des tâches et des projets. Alors que, dans Scrum, les itérations sont fixes et ne permettent pas de s’adapter à des demandes imprévues, Kanban permet d’avoir un flux de travail continu, ce qui améliore la gestion des changements d’exigences ou de priorités.
- Concentration sur la chaîne de valeur: avec Kanban, nous nous concentrons sur l’optimisation du flux de travail de l’équipe et sur l’élimination ou la réduction des goulets d’étranglement. Si Scrum crée des goulets d’étranglement et un flux de travail inefficace, Kanban vous permet d’améliorer la vitesse de livraison.
- Visibilité: avec Kanban, vous pouvez donner plus de visibilité au travail effectué au sein de l’équipe. De la même manière, les parties prenantes telles que les entreprises ou le HPO peuvent voir, à partir du tableau de bord Jira, l’état des initiatives, la façon dont elles sont priorisées et la manière dont elles progressent. Grâce à cette visibilité, nous pouvons identifier et traiter plus rapidement les problèmes dès qu’ils se présentent.
- Élimination du surengagement: dans Scrum, l’équipe s’engage à fournir un nombre fixe de tâches dans un délai fixe. Cela ne signifie pas qu’avec le Kanban, l’engagement disparaît, mais contrairement à Scrum, il ne génère pas de frustration si l’équipe n’arrive pas à destination parce que l’étendue des tâches était plus complexe. De même, il encourage la collaboration entre les membres de l’équipe pour qu’ils accomplissent les tâches ensemble et plus rapidement.
- Moins de cérémonies: Scrum comporte cinq cérémonies, dont beaucoup sont inefficaces pour les équipes ou considérées comme une « perte de temps ». Le Kanban compte sept cérémonies, mais contrairement à Scrum, elles sont plus légères et plus adaptables. Vous pouvez adopter celles qui génèrent réellement de la valeur et vous aident (par exemple, la gestion des risques a tendance à être la moins utilisée par les équipes). N’oubliez pas que la méthodologie doit être au service de l’équipe, et non l’inverse.
- Réduction du gaspillage: avec Kanban, vous serez en mesure d’identifier et d’éliminer, dans la mesure du possible, les étapes du processus qui n’ont pas de sens et qui nuisent à la création de valeur. Vous améliorerez ainsi l’efficacité et la productivité de l’équipe.
- Amélioration des délais de livraison: lorsque nous nous concentrons sur le principe « arrêter de commencer, commencer à finir », nous livrons en continu, nous minimisons les travaux en cours et nous restons concentrés sur les tâches à accomplir, ce qui permet d’accélérer la livraison des produits.
