Dans le cadre d’un produit devant être déployé dans une multitude de pays, une équipe en charge des développements applicatifs a pris la décision d’arrêter les développements, au grand dam des autres équipes qui composent ce programme. Sous le titre volontairement provoquant il faut lire : L’équipe DEV arrête de travailler et utilise l’Andon pour appeler à l’aide.
Pour une bonne compréhension, il est important de préciser que les équipes sont organisées – comme dans nombre de grands projets – en compétences fonctionnelles et techniques, et pas en flux métier. Pour reprendre l’image utilisée dans Le Lean en clair, résoudre le paradoxe de l’efficience (Niklas Modig, Pär Ahlström, Rheologica Publishing, 2014), nous avons un terrain de foot couvert de dizaines de petites tentes, où les matchs se déroulent avec plusieurs ballons à la fois.
Rendre visibles les problèmes
Cette équipe de DEV, avant d’être accompagnée pour comprendre et intégrer le Lean dans son fonctionnement, avait du mal à faire entendre sa voix en cas de surcharge d’activité. Cela avait pour conséquence de créer des tensions avec son écosystème, et de ne pas produire au rythme attendu. Bien qu’utilisant Jira, il a été décidé de construire un management visuel structuré autour
- d’un backlog des sujets à venir ;
- du processus de fabrication ;
- de bacs rouges (pour les problèmes de qualité) à chaque étape ;
- de colonnes d’attente ;
- du quai de livraison.
À cela s’ajoutent des limites (WIP) par colonnes pour réduire le nombre d’en-cours.
Ce management visuel manuel est une surcouche visuelle à Jira pour rendre plus explicites les problèmes. Certes, certains diront que c’est un gaspillage, car il y a du rework, mais c’est sans compter la valeur apportée dans la compréhension de la situation. Je ne rentrerai pas dans ce débat ici ; ce n’est pas l’objet.
Le processus n’étant pas encore en flux tiré par la demande des clients, l’équipe a donc un takt (rythme) calqué sur sa capacité à faire, ce qui n’est que transitoire.
Ce management visuel a permis à l’équipe de DEV de montrer aux autres équipes, mais également au management, la situation réelle, celle du terrain. Plus de 60 tickets dans le backlog et 88 tickets en attente de test, qui doivent être réalisés par des équipes métier avant de pouvoir passer en production. Les délais d’attente étaient très variables, mais surtout importants. Ils se comptaient souvent en semaines. Bref, l’équipe produisait du stock et peu de valeur partait en production. Sans compter que si des erreurs étaient détectées (gaspillage) pendant les tests, des personnes de l’équipe devaient se replonger dans un sujet plus ou moins ancien.
Arrêter de produire
Quand on pratique le Lean, on cherche à mettre l’entreprise en flux tiré (pull flow) par la demande des clients pour rendre visibles les problèmes et les résoudre les uns après les autres. On vise également le flux pièce à pièce (one piece flow). Si l’on produit des pièces pour faire du stock, c’est que le système n’est pas correctement réglé et qu’il génère des gaspillages (stock, attente, rework…).
Nous expliquons donc ces principes à l’équipe de DEV, et notamment l’importance d’arrêter la chaîne de fabrication ; comme dans une industrie (enfin… celles qui sont Lean). Le team leader et le tech lead n’étaient pas à l’aise avec cela et craignaient de se prendre quelques remontrances. Rendez-vous compte ! Que l’équipe prenne l’initiative d’arrêter le développement ? Pour certains c’est juste inimaginable, voire insupportable ! Les gens sont là pour bosser, pas pour se tourner les pouces !
L’équipe DEV arrête de travailler et utilise l’Andon pour appeler à l’aide. L’Andon (corde ou signal en japonais) pour signifier au management qu’elle n’arrive pas à résoudre ce problème toute seule. Et c’est là que doit intervenir le support du management.
L’intérêt pour la réussite de chacun dans son métier est très important en lean. La capacité du manager à voir la difficulté et à apporter son aide renforce la confiance de ses collaborateurs en leurs propres capacité d’apprentissage et d’exécution, et amenuise le stress auquel ils sont soumis. »
Source : La pratique du Lean management dans l’IT, M.-P. Ignace, Chr. Ignace, R. Médina, A. Contal, Pearson, 2012
En parallèle de l’accompagnement des équipes, nous accompagnons le management intermédiaire et les membres du comité de direction. Ils apprennent, comme les opérationnels, les principes Lean et leur rôle pour soutenir leurs équipes et les aider à réussir. Le responsable de l’entité, fort de sa conviction, assure que l’équipe DEV doit poser les crayons, comme nous avons l’habitude de dire, et d’arrêter de produire si rien ne sort.
L’équipe, bien qu’ayant le soutien de la chaîne managériale, est toujours hésitante et se laisse une semaine de plus pour prendre la décision. Des actions sont en cours pour réduire ce stock de tickets à tester. Une semaine plus tard, le stock a baissé… 1 ticket en moins. Elle décide alors d’arrêter les développements des nouvelles fonctionnalités (celles dans le backlog), mais assure le traitement des anomalies et des incidents (bug first pour protéger le client). Elle finit également les sujets en cours.
Vider les colonnes d’attente
Après les réactions de surprise pas toujours positives, l’arrêt des développements a permis de créer les discussions nécessaires avec les autres équipes pour comprendre précisément pourquoi ces tickets n’étaient pas testés et trouver des solutions pour les traiter rapidement.
En 2 semaines, le nombre de tickets en attente est passé de 88 à 31 ; une belle mobilisation et il est tout à fait justifié de s’en féliciter. Pour autant, cette réussite ne doit pas masquer la réalité. Cet arrêt temporaire n’est que l’arbre qui cache la forêt. Le stock de ticket à tester peut très vite remonter si le flux de valeur ne s’organise pas autrement. Le management visuel et ce choix – encore une fois, qui n’a pas été facile à prendre – ont rendu visible une situation anormale qui perdurait.
Reprendre les développements
Maintenant que ce point est sous surveillance (management visuel et mesures), que le stock est à un niveau raisonnable, qu’un seuil d’arrêt des nouveaux développements a été défini et que des actions sont entreprises pour réduire ces attentes, l’équipe de DEV a décidé de reprendre – de façon plus contrôlée – le développement des nouvelles fonctionnalités.
Le dispositif de synchronisation, renforcé pendant cet arrêt, est maintenu le temps de la mise en place d’un management visuel plus transverse qui permettra aux équipes, en charge des tests, de voir et de traiter les tickets disponibles.
Le niveau raisonnable sera abaissé progressivement et régulièrement pour réduire les stocks intermédiaires (les attentes). Chaque baisse mettra en évidence de nouveaux problèmes que les équipes devront traiter. Puis, pas après pas, l’équipe de DEV passera d’un système poussé (tickets terminés poussés vers les équipes qui testent) à un système tiré en déclenchant sa production (les développements) en fonction des besoins des testeurs. Ainsi, c’est toute la chaîne de création de valeur qui va se caler sur le rythme des demandes des clients.
Un long chemin riche en améliorations et en apprentissages.