Ce post fait suite à un autre texte “Le kanban est le bitcoin du Lean”. On y montrait pourquoi il est possible de considérer le kanban comme une monnaie virtuelle dans le monde de la production de biens ou de services, monnaie qui permet d’organiser le travail de chacun le long d’une chaine de valeur.

L’exemple utilisé était celui d’une petite chaine de développement informatique comprenant un spécifieur, un développeur et un testeur.

Ce nouveau post sort de la partie théorique du kanban et explore ce qui se passe dans la réalité, lorsqu’on essaie de le mettre en œuvre. En un mot comme en cent, ça explose !

Imaginons que le développeur n’arrive pas à terminer la commande que le testeur lui a passée :

 

• Le testeur ne peut pas tester, il ne peut donc pas livrer à son client. Il n’est donc pas payé et il n’a pas la possibilité de racheter quoi que ce soit au développeur ;
• Le développeur ne reçoit pas de nouveaux kanbans, puisque le testeur n’en a pas à lui donner. Il est fauché…et ne peut rien racheter au développeur ;
• Le spécifieur peut terminer sa commande en cours (mettons 10 unités) puis lui aussi s’arrête : pas de bras, pas de chocolat !

On a donc le spécifieur qui arrête de produire des spécifications, donc le développeur qui arrête de coder et le testeur qui n’a plus rien à tester.

Le système ne redémarre que lorsque le développeur retrouve les moyens de travailler. TOUT se désorganise ! Si on veut que la machine redémarre, il va falloir comprendre ce qui empêche de livrer le client !

Que se passe-t-il dans une organisation qui n’est pas Lean ?

La désorganisation se propage à l’intérieur du projet puis se diffuse vers d’autres : plutôt que de ne rien faire, les spécifieurs vont commencer un autre projet et les testeurs vont être destaffés. Apparaissent alors des manageurs en charge de la planification/déplanification, des comités entre les clients et l’informatique pour prendre les décisions ad hoc, etc, etc, etc.

L’effet boule de neige le plus surprenant que j’ai vu a consisté à annuler la réservation de 1 500 chambres d’hôtel. Elles étaient destinées à des commerciaux itinérants, invités à Paris à une démonstration de leur nouvel outil CRM… en retard.

Pour contre-carrer la désorganisation de l’organisation, celle-ci crée des postes de “responsables de portefeuilles” qui essaient tant bien que mal de savoir comment avancent les projets et de donner un peu de visibilité sur les plannings.

On se retrouve in fine avec des projets qui se désorganisent, une nouvelle administration qui planifie et replanifie et un sentiment d’impuissance peu satisfaisant.

Alors pourquoi se lancer dans l’aventure du kanban ?

Tout simplement parce qu’avec le Lean management, on a la conviction chevillée au corps qu’il n’y a aucune fatalité au désordre! Encore faut-il le rendre visible pour motiver chacun à s’intéresser à l’amélioration.

La transformation Lean suit la logique suivante :

1. Définir une situation normale.
   Le kanban sert à définir cette normalité grâce à la régularité du cycle commande / réalisation / livraison qu’il définit ;
2. Lancer les activités et voir les problèmes apparaitre (exploser ?) ;
3. Résoudre ces problèmes 1 par 1, avec la méthode scientifique du PDCA ;
4. Réussir !

Dans le cas de notre équipe en charge d’un logiciel, les principes 1 – 2 – 3 du kanban vont mettre en évidence 1 000 et 1 difficultés différentes. Quelques exemples :

• L’environnement de test n’est pas disponible ;
• Les données de test ne sont pas disponibles ;
• Le testeur est détourné de ses tests par autre chose (une réunion par exemple) ;
• Le développeur n’est pas à son aise avec le système ;
• La documentation du code est inexistante, incomplète ou pas à jour ;
• Le spécifieur connait mal le métier sur lequel il travaille ;
• Etc, etc, etc.

Rien de tout cela n’est une fatalité, il faut s’armer de constance et de méthode (pdca) pour revenir à une situation plus normale et stable.

On dit ici que le Lean management vous amène à vous battre contre “la variabilité”, considérée à juste titre comme LA grande perturbatrice de la performance.

Kanban or not kanban ?

La vraie question est : jusqu’à quel point avez-vous envie du succès ?

Avec un kanban sans grande sophistication, et une vraie détermination ! il est possible de réduire ses délais au temps de travail nécessaire pour construire le produit. Une journée de délai pour produire une petite évolution informatique, une demi-journée pour valider et rédiger une offre de crédit, deux heures pour mettre un poste de travail à disposition, etc…

Je connais une équipe informatique qui, en deux mois, a réussi à augmenter son rythme de livraison d’une fois par semestre à une fois tous les deux mois. Et qui, deux mois plus tard, était capable de livrer toutes les deux semaines.

A suivre…