Un changement qui peut tout changer dans vos itérations : vers un mindset orienté résolution de problèmes

Je suis toujours surpris par la manière dont les équipes s’approprient l'agilité. Ce qui avait commencé comme une approche flexible, adaptable, et centrée sur la création de valeur est devenue, dans bien des cas, une mécanique robotisée. Les équipes suivent aveuglément des cadres imposés sans les remettre en question ou sans comprendre leurs principes fondamentaux. On applique des méthodologies sans les adapter au contexte, et cela mène à des dérives dangereuses.

La situation qui matérialise le plus ce phénomène et qui m’inquiète au plus haut point (no pune intended 😅), est celle des « feature factories ». On produit des fonctionnalités à la chaîne, avec une obsession quasi religieuse pour la productivité et la vélocité.

Mais pour quoi faire ?

Les équipes ne prennent pas suffisamment conscience de l'impact réel de leurs livraisons sur leurs utilisateurs finaux. Si on le faisait, on se rendrait compte que plus de 80 % (cf. étude Standish Group) de ce qu’elles produisent pourrait être jeté à la poubelle. En plus de gaspiller des ressources financières et humaines, elles perdent leur temps à produire la mauvaise chose. Comme le dit l’adage, mieux vaut faire mal la bonne chose que faire bien la mauvaise chose !

Chez IKKI, quand nous cherchons à maximiser l’impact d’un produit sur le marché, nous travaillons sur 3 axes en même temps.

La vélocité est devenue le mètre étalon des équipes dites « agiles ».

Mesurer le nombre d'éléments livrés en une itération ou la somme des points est une pratique courante.

Le problème majeur avec cet indicateur est qu’il peut pousser les équipes dans cette course effrénée à la production de fonctionnalités.

Une course suivie de près par le Management (souvent utilisée à tort par ce dernier pour comparer les performances entre équipes, une hérésie) mais qui, au fond, s'avère destructrice pour les entreprises si l’impact client n’est pas au rendez-vous.

La vélocité est également subjective car elle peut être manipulée.

Si j'augmente arbitrairement le nombre de points d'un ticket, j'augmente artificiellement la vélocité. Si je découpe un ticket en micro-tickets (incohérents pour le client si livrés indépendamment les uns des autres), j’augmente là aussi artificiellement la vélocité.

Il devient alors un leurre. L'équipe pourrait même être tentée de sacrifier la qualité pour « faire du chiffre » (c’est-à-dire « aligner les fonctionnalités au kilomètre »), oubliant complètement la valeur réelle pour le client.

Mal utilisée, elle peut être à l’origine d’une pression accrue sur l’équipe et sa démotivation. Par ailleurs, elle peut également masquer l’utilisation d’autres éléments agiles, par exemple l’objectif de sprint qui est utilisé pour matérialiser l’impact client recherché.

Cela ne signifie pas pour autant qu’il faille jeter la vélocité à la poubelle. Bien au contraire, elle peut être très utile sur une période donnée pour mesurer la stabilité et la régularité de production dans le temps d’une équipe (comme cela pourrait être le cas avec la couverture de code par exemple) avant de chercher à accélérer la cadence. C’est donc un indicateur temporaire qui n’est pas une finalité en soi.

Et si on changeait de perspective ?

Prenons l’exemple du cœur. Mesurer le nombre de pulsations par minute, la fréquence cardiaque, donne une information sur le rythme global, mais c’est une mesure assez grossière. Ce n’est pas la même chose que de mesurer la variabilité de la fréquence cardiaque, c'est-à-dire les variations du temps entre deux battements.

Pourquoi est-ce important ?

Parce que la variabilité de la fréquence cardiaque, contrairement à la simple fréquence, donne une idée beaucoup plus précise de l'état de santé du cœur. Une faible variabilité peut indiquer un stress ou un dysfonctionnement, tandis qu’une forte variabilité reflète un système flexible, capable de s’adapter aux besoins du corps. En d'autres termes, mesurer simplement la fréquence peut masquer des problèmes sous-jacents que seul un examen plus fin, comme celui des variations, peut révéler.

Si l’on transpose cela à la gestion des livraisons dans une équipe de développement, se focaliser uniquement sur la vélocité, c’est comme ne regarder que la fréquence cardiaque. On obtient un chiffre qui donne une impression de mouvement, mais qui peut masquer des inefficacités (#Gaspillages).

En se concentrant sur la variabilité des temps de cycle, on obtient une vision plus nuancée et plus riche de la capacité d’adaptation et de la santé globale du processus de production.

Le temps de cycle d’un ticket de votre backlog correspond au temps nécessaire pour qu'un ticket passe de l'état « En cours » à « Terminé » dans votre kanban. Le temps de cycle prend donc en compte le temps nécessaire à l'exécution de chaque tâche, la quantité de travail produite ainsi que les temps d’attente entre vos étapes de livraison.

Ce qui est intéressant avec le temps de cycle c’est qu’il met en évidence les étapes où le processus pourrait être plus efficient. Les temps de cycle longs indiquent les goulots d'étranglement et les activités inutiles que les équipes de développement logiciel doivent éliminer pour accroître l'efficacité du flux de travail. Un cycle court améliore le débit, c’est-à-dire la quantité d'éléments finis produits dans un temps donné.

Ce changement de point de vue est simple mais loin d’être simpliste, c’est avant tout un changement de paradigme.

En se concentrant sur le temps de cycle, l’équipe va devoir chercher à développer une véritable culture de résolution de problèmes qui permettra de progresser quotidiennement.

En effet, l’accélération du rythme de livraison va automatiquement amener l’équipe à élever son niveau de jeu sur la qualité de l’ingénierie logicielle. C’est pour cela qu’en Lean, nous ne dissocions pas le Juste-à-temps (délai) du Jidoka (qualité) :

• Le Juste-à-temps vise à ne produire que le bon produit, au bon moment, au bon rythme, dans la bonne quantité : en tendant le flux (par la réduction du lead time), son but est là aussi de rendre visible et adresser (s’arrêter et réfléchir) les « défauts » (avance, retard, quantité trop importante…) et les problèmes de stagnation.
• Le Jidoka vise à ne produire que du bon : réussir chaque opération du premier coup en s'arrêtant à chaque défaut pour en éliminer la cause.

« La résolution des problèmes qui émergent par le Juste-à-temps et le Jidoka est le carburant à utiliser au quotidien pour spécifiquement apprendre à créer la confiance et surmonter les obstacles. »

— Régis Médina

L'objectif n'est plus de produire un maximum d'éléments, mais de fluidifier / lisser le flux de travail, en identifiant et en éliminant chaque obstacle dès qu'il se présente. Plus besoin d'attendre la rétrospective toutes les X semaines pour agir.

En résolvant les problèmes au moment où ils surgissent, l’équipe :

• reste concentrée et évite de gaspiller du temps et des ressources en revenant sur des problèmes anciens ;
• améliore sa compréhension des blocages, ce qui lui permet de trouver des contre-mesures efficaces ;
• analyse chaque geste et essaye de comprendre à quels moments il introduit ou détruit la qualité, et donc la valeur au client ;

In fine, l’équipe cherche à se prémunir de l’apparition des mêmes problèmes dans le futur en formant tous les membres sur la meilleure façon de faire connue à ce jour. C’est ce que nous appelons les standards.

Un standard :

• n'est pas une procédure portant sur plusieurs jours de travail, il porte sur la maîtrise d'un geste précis ;
• n'est pas immuable, il est régulièrement amélioré par la résolution de problème ou sous la contrainte d'une challenge externe ;
• ne liste pas toutes les étapes mais uniquement les points clés sur lesquels il y a un risque (le cerveau ne retient que ce qui est utile) ;

La formation au standard implique donc de revenir constamment sur les raisons d'un geste d'une étape. Cette formation n’est jamais terminée.

La moindre modification du standard implique de former chacun un nouveau. Les gestes ou tâches peu fréquents nécessitent une formation au standard en flux tiré, c'est à dire juste avant le besoin.

— Institut Lean France

En réduisant les temps de cycle, l’équipe rapproche également la valeur du client tout en réduisant les coûts de production (elle délivre plus efficacement grâce à sa maîtrise plus fine et consciente de ce qu’elle fait au quotidien).

Elle est en capacité de tester plus rapidement ses hypothèses sur la valeur et l’impact des fonctionnalités, au lieu de s’embarquer dans une production de fonctionnalités dont on ignore la réelle pertinence.

Ce changement n’est pas simplement une amélioration subsidiaire, ou un effet de style imposé par un soi-disant expert. C’est un véritable changement de mentalité et faire des problèmes un levier fort de progrès individuel et collectif.

Une équipe qui adopte cette approche cherche à être capable de résoudre tous les problèmes qui ralentissent son flux de travail, tout en maintenant un haut niveau de qualité et une cadence de travail soutenable. Mais ne vous y trompez pas, même si vous faites les choses plus vite et plus efficacement, vous n’augmenterez drastiquement les chances de succès que si vous faites en plus la bonne chose : « Chasser les gaspillages c’est bien. Chasser la valeur client avec ces gaspillages, c’est encore mieux ! ».

Cette démarche vous semblera sans doute familière si vous vous intéressez aux racines de l’agilité, partagées avec le Lean.

Pour plus d’informations, contactez-nous !

Auteur : Nicolas Cappello (Linkedin)