SAV de l'agilité : Soirée spéciale "fails"

Pour démarrer la rentrée du bon pied, je me suis inscrite à plusieurs meetups sur l’agilité. Mercredi, j’avais rendez-vous chez So@t sur le thème des fails agiles organisé par le French Scrum User Group. Objectif : venir exposer ses échecs et repartir avec quelques conseils de coachs (par définition : des gens avec de la bouteille). Voici le compte-rendu d’une soirée où l’on découvre que l’on n’est pas seul à prendre des claques et où les expériences des autres sont très enrichissantes.

Le déroulement de la soirée

En arrivant dans la salle, les organisateurs de la soirée nous demandent d’écrire le titre d’un fail ainsi que notre nom sur un post-it. Puis de le coller au mur. La soirée se déroule en 3 temps :
1ère partie : un animateur pioche un fail au hasard et demande à son auteur de le présenter en 1 minute.
2ème partie : tous les participants se lèvent et donnent chacun 4 votes pour les fails présentés (principe du DotVoting). L’animateur comptabilise les points et identifie les fails ayant eu le plus de « succès ».
3ème partie : l’auteur du fail s’installe près de l’équipe du SAV (4 coachs agiles expérimentés) et réexplique son fail en donnant un peu plus d’informations sur le contexte. Le SAV lui pose des questions et suggère des bonnes pratiques à mettre en œuvre dans pareille situation. Démarre alors un échange de 15/20 minutes pendant lequel les participants peuvent aussi intervenir et proposer une analyse.

L’importance de bien pitcher son fail

Bien évidemment, nous n’avons pas eu le temps d’aborder tous les fails cités mais seulement ceux qui ont suscité le plus d’intérêt. C’est amusant car, pendant la 1ère partie de soirée, tout le monde s’est vite rendu compte qu’il y avait une façon de raconter une expérience malheureuse. Comme tout sujet, face à un auditoire de gens fatigués, mieux vaut savoir se mettre en scène pour intéresser.

Quelques exemples de fails agiles du classique au plus original

• C’est l’histoire d’une équipe qui travaille en Scrum. Le Product Owner s’absente pendant 2 semaines. A son retour il demande « vous en êtes où ? », « Est-ce que c’est en prod ? »
• « J’ai proposé à mon équipe de développement de mettre en place un KANBAN. Tout le monde était très motivé, mais personne ne l’a jamais mis à jour. »
• « Ça fait 3 jours que je dis que je vais mettre en production. Je suis Product Owner, et ça m’arrive très fréquemment. »
• C’est l’histoire d’un projet agile dont les parties prenantes sont liées par un contrat au forfait. Le projet est assez massivement sous chiffré. L’équipe n’est pas formée. La priorisation est mal faite. Le budget n’a jamais été réévalué. Le produit n’est jamais sorti.
• « Le métier trouvait qu’on ne développait pas assez vite. On lui a proposé de développer en méthode agile. Après un début d’expérimentation, le Product Owner trouvait que ça lui demandait trop de travail et a décidé d’arrêter. »
• La fée maléfique : un coach agile accompagne une équipe. Tout se passe à merveille. Seul le responsable de la DSI n’est pas convaincu. Le coach ne prend pas le temps de le sensibiliser et se concentre sur les membres de l’équipe. 3 ans après, le responsable arrête tout et recrute des chefs de projets.
• Une personne travaille sur un projet « super agile », super quali (91% de couverture de code). Le métier s’alarme : « vous allez trop vite, les specs étaient un peu anciennes, on arrête tout ».
• « Mon Product Owner s’appelle Hitler ». Histoire d’une personnalité compliquée qui ne fait pas confiance à l’équipe et qui incendie tout le monde en review.
• Un fail qui m’a plu car hors contexte informatique : un déménagement agile réalisé en très peu de temps. Au moment de fêter la réussite du projet, le propriétaire se demande « oui… Mais si on avait réfléchi plus… »
• Et enfin mon fail à moi : Je suis Scrum Master sur un projet bien préparé avec un Product Owner formé, convaincu, un product backlog issu d’une réflexion globale (impact mapping), des scénarios de test bien rédigés. 1er sprint review : nous n’avons rien à montrer.

Les bons conseils du SAV : ce que j’ai retenu

• Si l’équipe ne parvient pas à délivrer une story et que la date de la review se rapproche, tout le monde se concentre sur la story qui bloque plutôt que de s’éparpiller sur plusieurs stories. « Le soleil ne se couche jamais sur une tâche non terminée. »
• Si le Product Owner est réticent à découper ses stories (dit « saucissonnage ») : lui proposer d’expérimenter. Il verra que ça rend service au projet et donc à lui-même.
• Impliquer l’ensemble de l’équipe lors de la conception du produit.
• « On ne fait pas de l’agilité, on est agile » : penser à communiquer et diffuser le manifeste dans l’entreprise.
• Quand vous avez en face de vous une entreprise qui n’est toujours pas convaincue malgré les projets agiles mis en place, engagez la conversation sur ce qui marche.
• « Quand on commence une transformation, il faut créer une urgence ».
• Si une entreprise impose un contrat au forfait à un intégrateur pour des projets en méthode agile, le SAV est assez catégorique : il ne faut pas signer. Cela signifie que l’entreprise ne fait pas confiance. Il y a plusieurs alternatives comme s’engager sur un MVP uniquement, rédiger et faire valider au client un mode opératoire (de type PQS).
• Une personne peut tuer l’agilité quand elle ne cherche pas à collaborer à l’exercice commun.
• Si un Product Owner ne fait pas confiance à son équipe, il faut éviter le flou, lui faire rédiger des tests d’acceptance sur les stories.

Cette soirée était très amusante. C’est marrant de jouer au coach (certains se sont lancés plus que d’autres d’ailleurs). Cela a peut-être suscité des vocations…
Il ne faut pas avoir peur des fails mais s’en servir pour s’améliorer.
Cette expérience m’a rappelé mon entretien à la coach clinic au Scrum Day. Avec l’interaction des participants en plus.
Encore une fois, je trouve ça dommage qu’il n’y ait pas eu plus de Product Owners présents. Est-ce que cela signifie que les Product Owners ne se sentent pas responsables d’un succès ou d’un échec sur leur projet ? Dans mon environnement de travail, ils sont encore trop nombreux à pointer du doigt le reste de l’équipe en cas de difficultés.