Game of Bugs : réduisez drastiquement votre backlog de bugs

Prêt à découvrir une nouvelle version du Rally test game ? C’est parti !

1. Start with why!

Quand une équipe ou un ensemble d’équipes travaille(nt) de manière itérative sur le développement d’un produit, des écarts de comportement attendu de ce produit peuvent être observés.

Ces écarts, bugs ou légères modifications quant aux besoins clients, sont un fait. Ils n’ont pas été introduits par volonté de nuire. Plus vous êtes nombreux à co-élaborer, plus ce genre de risque est possible.

Bien que les équipes gèrent au quotidien pour réduire ces écarts, il est parfois moins efficace de se concentrer à la fois sur des études, sur la réalisation de nouveaux besoins, et la correction de bugs/écarts.

Et plus nous attendons pour fixer ces écarts, plus cela « coûte » cher. Toutes les raisons sont bonnes : la refonte d’un code legacy peut mettre en défaut une architecture plus récente et nécessite un coût de correction très volumineux, les personnes qui l’ont codé ne sont plus là et la mise à jour du code nécessite d’avoir des talents d’archéologue (je ne juge pas, je parle en connaissance, j’ai été développeur, je suis passé derrière des gens qui avaient codé et … il faut l’avouer, des gens sont passés après moi et ont du me maudire).

Ce schéma qui a été maintes fois partagé a des détracteurs sur sa conformité avec la réalité, suivant la présence ou non de tests automatisés, de build automatique, etc.

Cependant, un fait est réel, plus un bug est détecté tard, plus il implique de personnes (détection, qualification, résolution, validation).

2. Mise en pratique

Sur un récent accompagnement, j’ai été confronté à un ensemble d’équipes co-élaborant un même produit.

Et le constat est que la pile des bugs au mieux stagne, au pire augmente.

Au détour d’un échange avec les facilitateurs du programme, je leur propose un atelier qui nécessitera d’impliquer le maximum de personnes sur 1 journée orientée sur du test et de la correction en live.

Quand je dis correction, je parle au sens artisan du terme, pas du « quick & dirty ». Les corrections sont accompagnées des tests de non régression qui seront automatisés.

Après plusieurs minutes de discussion, je ne sens pas mes interlocuteurs hyper emballés. J’ai des retours « oui, mais tu sais chez nous, c’est pas un site web, il y a beaucoup de traitement back-office » ou « un bug ça nécessite parfois plusieurs jours pour le reproduire, donc 1 journée on ne va rien sortir ».

Quoi qu’il en soit, je réussi à convaincre quelques early adopters (cf. “Crossing the chiasm” de Geoffrey Moore) et nous nous lançons dans l’organisation de cet événement.

J’avais par le passé discuté autour d’un type d’événement similaire appelé « Rallye Test Game » dont le but est de sortir des tests classiques en invitant les gens à faire du test exploratoire et à fixer en live.

3. La recette de cuisine

Pour cette équipe, nous avons opté pour une approche différente.

Étant donné qu’il existe déjà un backlog (une belle liste priorisée) de bugs infâmes dont nous n’arrivons pas à nous débarrasser et que les métiers souhaitent déjà se soulager de ces bugs, nous partons sur le modèle suivant :

• Mobiliser le maximum de personnes, réparties en petites équipes qui ne sont pas les équipes habituelles. Un métier par équipe et des développeurs qui n’ont pas forcément travaillé sur le fonctionnel concerné (l’œil neuf).
• Identifier ce backlog de bugs
• 2 jours
• Une gamification assez forte du jeu avec des goodies offerts à certains seuils

2 points importants dans cette liste :

La durée

J’entends déjà les :

• « ça va être ennuyeux quand même, non ? » ou
• « et c’est moi qui paye pour tout ça »
• …

Eh ho … tu les veux corriger tes bugs ?

Ceux ouverts depuis 6 mois qui ne sont toujours pas corrigés ?

Si cela n’a pas fonctionné avec la manière classique qui coûte déjà du temps, quel est le coût de tester une manière différente ? Dans le pire des cas, vous n’êtes pas satisfait, ce qui ne changera pas de l’état actuel

Dans l’autre cas, la black list sera réduite 😉

La gamification d’un rally test game

Attention, ici, pas de chapeaux bizarres, de danse des canards ou de shifumi.

La thématique

Nous avons décidé de partir sur une thématique, discutable j’en suis certain : Game Of Thrones. Sans doute l’actualité de la dernière saison arrivant ou alors le fait que sur le plateau quasiment tout le monde est fan.

Du coup, de « Rally Test Game », nous sommes arrivés à « Game of Bugs »

Les goodies

La seconde partie de la gamification, la plus importante : les goodies quand les seuils sont atteints.

Nous sommes partis sur la base suivante :

• 3 bugs corrigé pour une équipe = Un premier niveau de goodies pour l’équipe
• 5 bugs corrigés = un second niveau
• 10 bugs corrigés = Un troisième niveau
• 15 bugs corrigés = Un quatrième niveau

Sur ce point, des détracteurs nous ont remonté « oui, enfin, j’en connais qui vont choisir les plus simples » et « ils vont essayer de les corriger en amont pour -gratter- des points ».

Cela m’a fait sourire :

• Sur l’aspect les plus faciles : il y a un backlog qui par définition est priorisé donc peu de risque.
• Sur l’aspect ils vont essayer de cheater : eh franchement, vous voulez réellement râler car des gens sont restés un peu plus tard les jours d’avant pour « prendre de l’avance » et pré-corriger des bugs.

Enfin, je ne suis plus très fan de créer de la compétition entre plusieurs équipes dont l’objectif final est commun.

Nous avons donc introduit des récompenses globales. C’est-à-dire que si l’ensemble des équipes atteignent des paliers 10, 20, 30 et 40 bugs, alors toutes les personnes du programme sont récompensées.

Étant donné l’historique, beaucoup de personnes qui gravitent autour des équipes se disent « les deux derniers paliers, c’est mort, on n’y arrivera jamais » et du coup, le palier « 40 » a comme descriptif « surprise ». On en reparlera 😉.

4. Tri de la fameuse blacklist

Un des aspects importants dans le backlog est qu’il existait peut être 200 anomalies.

Du fait d’avoir impliqué les métiers et d’avoir été très rigoureux sur la reproductibilité, la veille, il s’est avéré que la liste était réduite à 100 bugs !!!

On pourra toujours dire que c’est un gain artificiel. De mon point de vue cela souligne que tout le monde s’est mis autour de la table pour « enfin » toiletter ce satané backlog. Au revoir les doublons, au revoir les anomalies jamais reproduites, au revoir les anomalies qui surfent avec l’âge de pierre levée par des personnes n’utilisant plus le produit !

Ensuite, nous rentrons dans du classique.

• Un stand up régulier autour d’un radiateur (l’atelier « au tableau » qu’Alex a démocratisé a sans doute bien aidé).
• Des équipes qui pouvaient s’installer un peu partout dans l’open space … ok tu veux coder assis par terre … fait toi plaisir.
• Un klaxon de voiture rétro pour signaler un correctif validé. Cela émule les autres et donne envie d’en finir avec son bug aussi.
• Des scrum masters super impliqués (ce qui me facilite grandement le travail … merci à eux).
• Des métiers qui attendent sur la plateforme de validation pour killer du bug.

Résultats obtenus

Résultat à la fin de la première journée 27 anomalies sont corrigées ou en attente de validation par le métier.

Et là, rappelez-vous du palier « 40 » décrété inaccessible 😉. « Bon, faut qu’on trouve une idée de surprise ».

A la fin de la seconde journée, nous avons atteint quasiment 50% de bugs corrigés.

Au final, oui nous avons impliqué beaucoup de personnes sur une courte période. À l’heure des € et des $, cela parait être un centre de coût.

Maintenant, quand

• vos approches classiques ne donnent plus de résultats
• vous observez une légère démotivation
• vous avez envie d’essayer quelque chose de différent

Regardez le résultat plus que l’investissement

Dans le cas présent (et à chaque fois que je l’ai animé) :

• Un management bluffé
• Des équipes qui s’impliquent au-delà de ce qui est attendu d’eux
• Un métier comblé
• Un produit plus robuste.

Encore quelques arguments…

Au gré des discussions j’ai eu un échange avec une personne qui évoque 2 assertions auxquelles j’ai répondu et que je vais livrer dans cet article :

« Je ne comprends pas qu’il faille des -cadeaux- pour qu’ils se bougent, la fierté d’avoir résolu le bug suffit » :

Honnêtement, les goodies ont été achetés dans une enseigne low cost pour la plus part. Rapporté au coût par personne, cela doit atteindre 8-10€ par personne de goodies. Pas convaincu qu’une « carotte » de 10€ soit le fond de la réussite.

Aujourd’hui, tout est gamifié, vous conduisez votre voiture de manière plus soft car vous gagnez des points ou un statut bon conducteur, j’optimise mes thermostats à la maison pour gagner des petites feuilles vertes une fois par mois par mail.

Donc oui, le fait de rendre cela jouable va aller travailler des leviers de motivation

(Je vous conseille un TED de Jane McGonigal : « Comment le jeu peut rendre le monde meilleur » )

« Mais pourquoi le reste du temps dans les itérations (je ne vous ai même pas dit que les équipes travaillaient en agile … peu importe leur organisation selon moi), ils ne sont pas aussi efficaces ??? »

La réponse – selon moi encore une fois – peut être rattachée au fait que pendant cette courte période de temps, les équipes sont focalisées sur un seul sujet : les bugs.

Dans leur quotidien plus conventionnel, ils ont les bugs, les études, les user stories, les technicals stories, les réunions avec les chefs, etc.

Là, il n’y a qu’un sujet, tuer ces satané bugs !!

Donc si vous voulez vous aussi changer vos approches et essayer quelque chose de nouveau, vous savez où nous trouver 😉

Aurélien

Papa d’un petit aventurier qui dépasse ses limites et m’entraîne dans ses expériences autour du monde
Moniteur de saut à l’élastique le week-end avec pour motivation d’aider des gens à rester en vie

Coach la semaine avec pour motivation d’aider des gens à relativiser le changement auquel ils sont confronté et l’accueillir à bras ouverts.

Donc le week-end j’aide des gens à vivre un changement extrêmement brutal lors duquel ils mettent leur vie en danger. La semaine, j’aide des personnes a appréhender un changement vécu tout aussi brutalement comme une nouvelle organisation, un nouvel outil, une nouvelle méthode de travail, …

Cela se fait dans cas par le biais de la formation, du coaching et du mentoring sur des sujets comme l’agilité, l’écoute active, les nouvelles pratiques de management.

Vous trouvez cette présentation étrange ? Je vous ai d’abord partagé ce qui fait de moi un être humain et me permet de relativiser les difficultés rencontrées par les entreprises.