Org Topologies & Stratégie Kanban pour augmenter son agilité business - Quatrième volet

Chapitre 4 : La montée en puissance sur la stratégie Kanban

Avec un peu de patience, d'effort de dialogue, Paul et son équipe scellèrent un esprit collectif et d'unité. 

Ils avançaient sur leur compréhension de Scrum, mais aussi de la stratégie Kanban. Ils commencèrent à mesurer des temps de cycle, à faire des expériences de limitation de WIP dans une recherche d’optimiser leurs flux.

En créant la DoD de l’équipe, ils devaient malheureusement encore s’arrêter avant la mise en production. Cette dernière étape était toujours réalisée par d'autres personnes en dehors de leur équipe.

Paul raconte : “Nous ne considérions plus les éléments de travail comme quelque chose que nous nous transmettions les uns aux autres, mais comme quelque chose que nous devions terminer aussi vite que possible ensemble. Nous nous aidions mutuellement, que ce soit sur le plan fonctionnel ou technique, avec toutes les compétences dont nous disposions individuellement. Par exemple, les personnes fonctionnelles avaient appris à réaliser des tests automatisés, et pas seulement au travers des IHM, nous allions jusqu’à l’automatisation de tests au niveau des API. Les personnes aux compétences techniques étaient invitées à participer plus tôt à la conception de la solution et à apporter leurs idées. Certains réalisaient des tests, lorsque cela était préférable au regard de l’état de notre flux de travail. Nous étions maintenant dans la même pièce, la collaboration était très forte, la programmation en binôme était devenue une coutume régulière et des binômes souvent fonctionnels & techniques.”

Le workflow* de l’équipe Scrum avait donc évolué et était maintenant :

En prenant des précisions auprès de Paul, l’équipe avait instauré des limites de WIP sur les étapes d'affinage, de dev et de recette. Les limites de WIP devaient aider à améliorer la focalisation de l’équipe en évitant de démarrer un trop grand nombre de travaux en parallèle, mais aussi à éviter que quelque part dans le workflow une “pénurie”. L’équipe avait donc instauré des limites de WIP optimum, c'est-à-dire à la fois une limite haute à ne pas dépasser, mais également une limite basse à laquelle se maintenir. Le but in fine était de rechercher par expérimentation les meilleures limites qui feraient gagner en performance. 

Paul précise : “L'erreur que nous fîmes au début, fut de ne pas limiter aussi les étapes d'attente de dev, d'attente de recette (ou par regroupement d'étapes avec l’étape précédente de travail actif)”

Une erreur assez classique, qui génère bien souvent un empilement de travaux en attente, et in fine plus de travaux globalement en cours que le niveau optimum pour l’équipe.

Paul relate que ce problème fut assez rapidement détecté et corrigé, il ajoute : “Tout cela nous amena à une progression nette de notre rapidité à traiter les sujets. On ne le mesurait pas très bien avant, mais avec les données que le chef de projet, hmm pardon notre Product Owner communiquait et les différentes replanifications, nous étions grosso modo entre 30 jours et 90 jours pour boucler une fonctionnalité. Les données que nous collections maintenant nous indiquaient une division par deux du temps de cycle maximum et une variabilité plus réduite (~25-45 jours).”

Une équipe qui avait une volonté d’amélioration continue qui s’ancrait de plus en plus en elle. Ces mesures maintenant fréquentes des temps de cycle et la recherche de l’amélioration de leur performance, les amena à s’intéresser à une métrique encore plus intéressante que le temps de cycle, à savoir l’âge des éléments en cours dans leur flux.

Pourquoi encore plus intéressante ? Parce qu’elle les informait bien plus tôt que le temps de cycle (calculé seulement une fois l’élément ayant atteint la fin du workflow), ce qui leur permettait d’avoir les conversations nécessaires plus rapidement pour gérer au mieux la performance de leur flux.

Paul nous raconte comment cela est venu : “Nous avions découvert cette métrique au travers du billet de blog : https://caroli.org/en/latency-and-banana/. L’idée nous avait paru géniale, mais on préféra tout de même compter le nombre de jours sans accrocher de peaux de bananes sur nos post-it…

Un peu plus tard, nous apprenions à visualiser le temps de cycle de nos différents éléments sur un graphique en nuages de points et, en y ajoutant des percentiles, nous découvrions la répartition du temps de cycle de nos éléments… 70 % en dessous de 24 jours, 85 % en dessous de 33 jours.

Ceci nous conduira à définir un niveau de service attendu (SLE) basé sur nos données historiques et en nous challengeant à faire mieux : 20 jours ou moins à 85 % du temps.

Nous couplions cela avec le suivi de l’âge de nos éléments en cours et ce fut un game changer.”

Les limites de WIP que l’équipe avait expérimentées, avaient apporté une amélioration de performance assez minime. Les expériences menées leur avaient apporté parfois des améliorations, mais aussi parfois des régressions, sauf que cela prenait un peu de temps à se voir. Le contrôle de l’âge et le challenge autour du SLE qu’avait choisi l’équipe par contre apporta une amélioration conséquente. De meilleures limites de WIP se dessinèrent même assez naturellement au travers de cette pratique du contrôle de l’âge et du focus à essayer de ne pas dépasser le SLE.

Après quelques mois, l’équipe avait largement rempli son challenge et pouvait même se challenger à améliorer encore son SLE.

Elle entreprit cependant une autre amélioration, celle de l’augmentation de la qualité d’utilisabilité de son produit, avec la montée en compétence d’une partie de l’équipe sur l’UX Design.

Paul nous raconte cependant une mésaventure sur cette montée en compétence UX : “Nous avions réussi à bien vendre l’apport que cette compétence pouvait avoir pour in fine le bonheur de nos clients et donc le business. La direction et notre représentant métier (Product Owner) avaient du coup très hâte de voir l’apport de ce type de compétences pour le produit, à tel point qu’ils ne nous laissèrent pas appliquer de nous même la compétence que nous avions fraîchement acquise. Ils firent appel à un cabinet de consulting spécialisé et malheureusement cela ajouta une unité distincte de notre équipe et donc une dépendance”.

Découvrez dans le prochain et dernier chapitre l'avenir de Paul et de cette entreprise...

Consultez mes classes certifiantes à mon catalogue sur la stratégie Kanban,  je peux aussi enseigner les classes ASPK et APV du catalogue de ProKanban. Contactez-moi pour arranger une classe privée inter-entreprise, ou si vous voulez suivre une classe publique mais n'avez pas les moyens de vous l'offrir.