Une démarche Kanban pour un enjeu Lean - partie 3

Dans le précédent post,  nous avons parcouru les trois premiers principes Lean pour optimiser notre flux de production. Continuons notre chemin pour voir comment Kanban répond aux 2 derniers principes.

4. Établir un flux tiré

Pourquoi cela?

• On ne construit pas de fonctionnalité dont personne n’a besoin maintenant
• On n’écrit pas plus de spécification que l’on ne peut coder
• On n’écrit pas plus de code que l’on ne peut tester
• On ne teste pas plus de code que l’on ne peut déployer
• On ne déploie pas plus de code que l’on ne peut utiliser

Partant de cela, nous n'allons déployer de code que par rapport à la capacité de l'utilisateur à l'utiliser; ne le tester que par rapport à notre capacité à le déployer; ne coder que par rapport à notre capacité à le tester; ne spécifier que par rapport à notre capacité à le coder. Le travail est donc tiré de l'aval vers l'amont du processus par rapport à la capacité de chacun.

La mécanique pour y arriver : les limites sur les états

Pour Scrum, La limite est indirecte et porte sur la capacité de réalisation de l'équipe sur une itération : sa vélocité.

Scrum répond à une partie de ces enjeux, mais sur la partie réalisation. On peut aller plus loin vers du Scrum Ban, en gardant la contrainte principale du processus Scrum: itératif, incrémental et time-boxé en régulant le travail en cours à l'intérieur d'un sprint.

Cette mécanique permettant d'aller sur du flux tiré doit être complétée par une autre mécanique pour arriver à une gestion juste à temps. On retrouve la mécanique Kanban de l'industrie utilisée pour déclencher des ré approvisionnement: une limite minimum qui déclenche une séance de planification ou de priorisation.

5. Rechercher la perfection


La valeur étant spécifiée, la chaîne de valeur identifiée, le flux mis en place, le flux tiré, on itère pour chercher la perfection par petit pas en s’appuyant sur des modèles d’amélioration continue partagés avec l'équipe pour:

• Améliorer le flux avec la théorie des contraintes
• Réduire les limites par le gaspillage avec le muda du Lean
• Réduire la variabilité pour augmenter la prédictibilité avec une approche statistique type 6 Sigma. La variabilité est moins important qu'il n'y parait dans nos processus comparée à la limite sur les états et le travail sur le flux.

Ce sont les principaux modèles mais non les seuls: Le Lean va bien au-delà du gaspillage, la pensée systémique, les options réelles, le modèle OODA, ... sont autant d'approche à digérer par le coach Kanban pour les restituer de manière pragmatique à l'équipe sur le projet.
Car on l'aura compris, le Kanban se positionne donc comme un moteur du changement et de l'amélioration continue pour aller vers une organisation Lean.

Conclusion


Kanban apparaît donc bien comme un moyen d'engager la transformation vers cet enjeu Lean, d'optimisation du flux de production vers du juste à temps. David Anderson  sur twitter a répondu récemment en ces termes:

People ask me "what is the diff between #Lean & #Kanban?"
Answer : #Lean is a destination, #Kanban is a means to get there

Les principes fondateurs du Kanban sont naturellement très proches de ceux du Lean que l'on vient de parcourir.

Post #1 : Une démarche Kanban pour un enjeu Lean
Post #2 : Une démarche Kanban pour un enjeu Lean - partie 2


La présentation

Une démarche Kanban pour un enjeu Lean - partie 2

Suite au post précédent, nous allons parcourir les premiers principes Lean pour optimiser notre flux de production, en s'appuyant sur le Kanban et au-delà:

1. Identifier la valeur

Identifier la valeur mais du point de vue utilisateur. C'est notamment la Voix du Client pour le Lean. Identifier la valeur c'est aussi identifier la pièce minimale ayant de la valeur que l'on délivre à l'utilisateur.

Le Kanban n'apporte rien sur le sujet mais peut s'appuyer sur cette pièce unitaire pour créer le flux continu pièce à pièce que nous aborderons au troisième principe.

On peut par exemple parler de MMF, MVP, d'Epic ou Story selon les approches et les contextes.

2. Identifier la chaîne de valeur

Toutes les étapes de la chaîne de valeur du point de vue de l'utilisateur. C'est la cartographie de la chaîne de valeur. Elle peut être identifiée par des outils tels que la VSM.
Le Kanban va s'appuyer sur cette cartographie pour visualiser le processus au travers du tableau kanban, qui en est la matérialisation. C'est le processus réel: On part de là ou on en est. Cette chaîne de valeur est vue de l'utilisateur. Elle est donc plutôt orientée métier et doit contenir toutes les étapes pour produire la pièce.

Il est bien évidement difficile d'adresser toute la chaîne, du besoin à l'usage. La démarche va être d'abord de partir de ce que l'on maîtrise et de diffuser doucement en amont et en aval du processus. Certaines approches ou communautés essayent d'apporter ou apportent déjà des réponses:

Du côté métier,  Scrum ou XP ont permis d'enlever des barrières entre le représentant des utilisateurs et l'équipe de réalisation. Il faut aller encore plus loin, plus proche des clients, comme peut être le fait le Customer Developpement, notamment avec les Lean Start Up.

Du côté production, le mouvement DevOps travaille sur la culture et les pratiques logicielles pour enlever les barrières entre l'équipe de réalisation, d'exploitation et de qualité. Il faudra là encore aller plus loin, jusqu'aux utilisateurs, au travers du support lorsqu'il existe, vitrine de l'entreprise. Les premiers retours d'expérience Lean IT sur des équipes supports montrent l’intérêt de cette démarche.

Entamer une démarche Kanban n'est pas compliquée en soi. C'est l'amener à la cible, adresser toute la chaîne, qui peut le devenir selon le contexte et la culture de l'entreprise.

Travailler sur toute la chaîne va impliquer de travailler avec des équipes potentiellement fortement spécialisées. Il va donc falloir mettre en place un flux continu tiré qui absorbe la variation (de travail, de vélocité, de caractéristiques de processus) entre celles-ci:
Cela va être le rôle des files d'attente du Kanban. Au-delà de cette mécanique, ce que l'on va chercher, ce sont les discussions entre équipes et les solutions qui vont en découler pour travailler mieux ensemble, alignées sur une cible et une démarche et des modèles d'amélioration.

3. Créer un flux continu pièce à pièce

Une fois la chaine identifiée et visualisée, on va la revoir comme une séquence telle que le produit se développe en flux jusqu’à l’utilisateur. Le premier objectif, avant d'optimiser quoi que ce soit, est d'être en maîtrise de notre processus, le flux tiré est bien l'étape suivante, mais concentrons-nous d'abord sur le flux.

Une des difficultés de cette étape est de trouver l’élément de travail qui va permettre de créer ce flux tout au long du processus.
Quel peut-il être lorsque le métier manipule des exigences, les analystes des spécifications, les développeurs du code, les testeurs des tests, l'exploitation des packages ou des modes d'op., le support des incidents?

Sur mon dernier projet Kanban, nous avons franchit une étape significative dans l'amélioration de notre processus au bout de 9 mois, on se mettant d'accord sur toute la chaîne de réalisation sur cet élément de travail, du concepteur aux homologateurs.

C'est un projet de migration outillée, cet élément de travail est l'écran à migrer. Il a fallu plusieurs mois avant de converger car chaque équipe spécialisée manipule concrètement d'autres éléments de travail.

Suite à cela, un refactoring du processus et du tableau à permi de passer d'un temps de cycle par écran de 40 jours à 29 jours. Ce qui est significatif car notre cadence de livraison est mensuelle. Un temps de cycle de 40 jours signifiait que du travail en avance de phase était réalisé et stocké, du gaspillage donc. 

Le gain s'est également répercuté sur la variabilité de notre processus en passant d'un écart type sur le temps de cycle de 12 jours à 4 jours.

Scrum, sur ce sujet du flux de pièce à pièce apporte une réponse intéressante: la user story qui est effectivement un bon vecteur de communication entre le métier, l'équipe de réalisation et les utilisateurs (ou leurs représentants lors des démos). Ce n'est pas la seule. Les uses cases sont également de bons vecteurs de communication comme le montre Alistair Cockburn. Et peut permettre d'aller jusqu'au déploiement continu de micro fonctionnalité.
Sans aller jusque là, en restant à un niveau plus macroscopique, les MMF sont également une réponse intéressante car elles vont faciliter l'utilisation du Kanban au niveau gestion de portefeuille.

Le prochain post sera consacré aux 4ème et 5ème principes de flux tiré et de perfection.
Post #1 : Une démarche Kanban pour un enjeu Lean

Une démarche Kanban pour un enjeu Lean

A la soirée Devops, Scrum et Kanban du French SUG, je proposais une introduction au Kanban axée sur les enjeux qu'il porte. Je vais, dans une série de trois posts, commenter cette session. Les slides seront en lignes à la fin de cette série. Au cours de cette session et de ces posts, un focus est mis sur Scrum et le Scrum Ban. L'objectif était d'introduire la session d'Antoine et Fabrice, non de comparer Kanban à Scrum.

J'ai expérimenté Kanban à partir de 2008 pour des problématiques opérationnelles. Initialement le choix de cette approche a été motivé par un souhait d'être agile dans des contextes projets qui n'étaient pas éligibles à Scrum: une migration outillée. J'ai fait un retour d'expérience sur le sujet l'année dernière.

Depuis, avec plus de recul, plus d'expérience et une meilleure connaissance et compréhension du Kanban, l'enjeu a, pour moi, basculé sur un plan plus stratégique pour les organisations:
Dépasser les frontières du projet vers l'organisation et faciliter l'adoption de l'agilité au niveau de la culture d'entreprise.

Nous rencontrons ces challenges comme coach agile régulièrement, les enquêtes ou conférences sur l'agilité le confirment également.
Pourquoi, par exemple, trouve-t-on des organisations qui ont pour un même projet deux équipes: une équipe agile pour le développement et une équipe traditionnelle pour la maintenance corrective?

Tous ces points et bien d'autres abordent la difficulté et l'enjeu d'emmener l'agilité en dehors des frontières du projet, vers l'organisation, en passant entre autre par la gestion de portefeuille.

Malgré quelques retours d'expérience réussis et qui semblent être encore l'exception, cette problématique est aujourd'hui difficilement adressée par l'agilité.

Pour moi, cela fait partie d'un enjeu plus global auquel le Lean se confronte. Le Kanban apparaît ici comme un élément de réponse permettant de commencer le voyage vers l'un des piliers de Toyota, celui de l'optimisation des flux de production : le pilier du Just In Time.

Le Lean propose 5 principes pour répondre à cet enjeu:

Dans la série de posts qui vont suivre, je vais parcourir ces étapes et voir comment le Kanban y répond.