Bien du premier coup : comment augmenter durablement sa vélocité

On le sait depuis un moment, la vélocité est un bon moyen de savoir s’il y a des problèmes dans l’équipe, mais un très mauvais indicateur de performance. En fait, le meilleur moyen d’augmenter sa vélocité, c’est d’augmenter son chiffrage. Boom, bonus pour tout le monde.

On se sert surtout de la vélocité comme d’une projection sur la capacité à faire, pour que le Produit puisse faire ses plans. C’est pour ça que la stabilité est l’objectif le plus important.

Tant que votre équipe n’a pas une vélocité stable, tous vos efforts pour accélérer vont simplement amplifier les problèmes, et aucun plan, aucune projection, ne se réalisera comme on l’entend.

Le pire ennemi de la stabilité est le retravail

Ça non plus ça ne devrait pas être une surprise : plus il y a de défauts, d’imprévus donc, moins vos projections seront précises. Et le propre des défauts, c’est que plus il y en a, plus il y en a. Et donc plus votre vélocité sera volatile.

Le problème d’une vélocité erratique causée par trop de défauts c’est que vous allez planifier vos sprints sans connaître votre capacité à faire, et donc augmenter les chances de ne jamais finir le sprint, entraînant pression, frustration, encore plus de mauvaise qualité pour se retrouver dans un cercle vicieux qui tire votre vélocité réelle vers le bas.

Beaucoup d’équipes, confrontées à un trop grand nombre de défauts, s’offrent un semblant de stabilité en limitant la bande passante dédiée à la correction de bug. Malheureusement, ça ne résoud rien pour deux raisons :

• Il y a d’autre défauts que les bugs. Les bugs sont les écarts par rapport à la spécification et les problèmes de fonctionnement d’un point de vue utilisateur. Il existe beaucoup d’autres types de défauts qui vont entraîner eux aussi du retravail, et donc de l’instabilité.
• Plus grave, si vous construisez sur une base instable, vous allez augmenter drastiquement la quantité d’imprévus. C’est pour ça que les équipes qui travaillent sur du code friable et sans tests vont avoir toujours plus de bugs.

Pour vous sortir de tout ça, ne mettez pas tous vos efforts à vous demander comment manager et corriger les défauts, mais plutôt à vous demander comment arrêter d’en produire.

La qualité à toutes les étapes

Plus on attend pour vérifier la qualité du produit, plus les défauts vont se combiner et rendre la correction difficile.

Il peut y avoir des défauts à chaque étape d’un cycle de développement, on va donc vouloir vérifier chaque étape du cycle, en faisant, par exemple : des revues de features, de spécification, d’UX, de code, et des tests de conformité, de parcours, de performance, de sécurité etc..

Le plus simple c’est d’ajouter dans vos Kanban des étapes intermédiaires pour matérialiser chacune des revues, de créer des standards et d’alimenter au fur et à mesure vos Definition of Done. Comme ça, chaque travail effectué est validé par au moins un pair avant d’être intégré au travail du suivant.

J’ai détaillé le processus des revues dans un article sur les revues de codes. Les pratiques sont applicables à toutes les étapes.

Taux de “bien du premier coup”

Une fois que vous avez mis en place toutes vos étapes de validation, vous allez pouvoir compter le nombre d’user stories qui parcourent l’ensemble du cycle du premier coup, donc sans aucune remarque, aucun retour.

C’est le taux de bon du premier coup.

Au début, la plupart des équipes qui mettent cette métrique en place sont à 0%. C’est normal. Même si vous faites attention à la qualité, tant que vous n’avez pas mis en place une systématisation de l’apprentissage vous aurez toujours des remarques et des retours.

Vous allez comptabiliser le nombre de retours par étape de validation, et c’est ce qui va guider votre démarche d'amélioration continue :

1. Vous identifiez le groupe de retours similaires le plus importants (exemple : ça arrive souvent qu’il manque des mesures en px sur les écrans, ou on oublie généralement de penser aux tags de tracking).
2. Vous analysez ces retours et vous essayez de trouver des contre-mesures, si possible automatisées, sinon entérinées dans le DoD.
3. Vous continuez jusqu’à ce qu’on puisse observer une baisse notable du volume de ce type particulier de retours.
4. Vous passez au groupe suivant.

Au fur et à mesure de votre démarche, des groupes d’user stories vont commencer à passer du premier coup. Votre progression sur l’indicateur ne sera pas linéaire, mais par à-coups.

Truc spécial des moines shaolin agiles : plus vos stories sont petites, plus elles auront de chances d’être bonnes du premier coup.

Donc, pour finir, vous avez devant vous le secret des équipes agiles qui fonctionnent : faire des stories toujours plus petites et apprendre à ne pas faire de défauts. En se mesurant avec le taux de bon du premier coup, on se crée une pression qui va aider à aller dans le bon sens.

---

Bonus : “Improvement Board” pour cadrer les grands projets d’amélioration continue

La rétrospective est en général le seul outil d’amélioration continue utilisé par les équipes. C’est intéressant pour la cohésion d’équipe et l’amélioration locale, mais assez inadapté pour les grands problèmes qui ne se résolvent pas en un sprint, comme le fait d’augmenter le taux de bon du premier coup.

Dans ces cas là, j’aime bien utiliser l’improvement board, un A3 simplifié, pour visualiser et cadrer l’effort d’amélioration.

Le principe clé de l’amélioration continue, c’est que si on savait déjà comment faire, on le ferait. Donc il faut imaginer des nouvelles solutions, les essayer, et vérifier que ça apporte ce qu’on souhaitait ou revenir en arrière et essayer la prochaine idée.

Ce tableau encapsule le principe en nous permettant de se focaliser sur ce qu’on connait, et en laissant la place pour les résultats de nos expérimentations :

1. Now/Problem : Le plus important c’est de bien comprendre la situation dans laquelle on est à l’heure actuelle. On veut du factuel, des métriques, des conséquences. C’est ce qui va nous prouver qu’on s’améliore.
2. Definition of Awesome : C’est le top, l’étoile polaire. A quoi ça ressemble d’avoir complètement résolu le problème. On ira peut être pas jusqu’au bout, mais c’est intéressant de se rendre compte du chemin parcourable.
3. Next target condition : C’est l’objectif, concret et réalisable, qu’on se fixe pour le prochain intervalle de temps. Le but n’est pas d’atteindre à tout prix l’objectif dans le temps imparti, puisque le chemin n’est pas connu, mais d’avancer, d’apprendre et d’affiner au fur et à mesure, afin d’éclairer ce fameux chemin.
4. First/Next steps : Les 3 prochaines expériences. On ne va pas détailler toute une roadmap d’avancement alors qu’on ne sait pas grand chose de la solution. On va se concentrer sur le présent, avancer pas à pas et essayer de s’approcher de la cible.

Au fil des sprints, on va continuer des cycles d’apprentissage jusqu’à atteindre la “next target”. Une fois la cible atteinte, on se fixe une nouvelle cible pour l’intervalle de temps à venir et on recommence les cycles.

Pour une explication plus détaillée de l’outil, allez lire l’article de son créateur Jimmy Janlén.