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
