C'est leeeeeeeeent

Derrière le problème de délai, on va surtout penser plus ou moins consciemment que les développeurs sont trop lents (peu importe les raisons). Même si la rédaction des spécifications a pris trois fois plus de temps ou s'il a fallu un mois pour avoir la validation de toute la chaine de commande. Quelques exemples de cause courante :

  • "Si les specs étaient plus claires, nous n'aurions pas eu besoin de tout ré-écrire"
  • "Si le client avait pensé à tous les cas dès le départ, nous n'en serions pas là"
  • "Il y a trop de tests. Vu le peu de régression, autant les corriger directement en prod".
  • "Le binômage coute trop cher"
  • "Il y a trop de réunions"
  • "Le PO a priorisé des problèmes de production devant donc nous ne pouvons pas tout faire"
  • "Les développeurs ne font pas assez d'heures"
  • "La direction met trop de temps à valider les maquettes"
  • "La recette révèle souvent des régressions"
  • "L'exploitation n'était pas disponible quand nous avons eu besoin d'eux"

Ces causes disent en réalité une seule et même chose : "c'est pas moi, ce sont les autres". Avoir des délais courts nous permet de proposer des solutions aux plus près des besoins du marché. Ce n'est pas forcément au détriment de la qualité. Développer des bugs ne sert à rien et livrer des produits se basant sur des specs d'il y a un an non plus. Les usages changent vite.

Se focaliser sur l'une de ces causes peut améliorer le time to market... ou pas. Le tout est de ne pas pédaler dans le vide.

Visualiser le problème

Mes compères de barre verte ont publié un ebook gratuit "Petit Guide de Lean Management à l'usage des équipes agiles". Il est juste passionnant, je vous le recommande chaudement. Chaque cas pratique parle de "Visualiser le problème". Régis en parle à chaque Agile France et pourtant ce n'est pas encore complètement rentrer dans ma tête. En lisant le livre, j'ai eu une idée sur la visualisation du flux. Je vais y revenir un peu plus tard.

La première fois que j'ai entendu Antoine Contal au XPDays, il évoquait des barres qu'il ajoutait chaque jour sur les post-its en cours. J'avais trouvé cela marrant mais assez peu applicable, c'est un peu chaud pour les équipes ! Quatre ans plus tard, j'entends un coach de la société générale évoquer le même principe mais avec des points. Il appelle ça la varicelle. Cela m'a définitivement poussé à faire une expérience que je voulais faire depuis quelques semaines : logguer le cycle de vie chaque jour.

J'abandonne donc mon diagramme de flow cumulé excel pour un système plus old school. Chaque jour, j'ajoute un petit symbole sur les User Stories indiquant à quelle étape elle est. L'idée étant de visualiser le goulet d'étranglement et à fortiori ce qu'il serait le plus important à optimiser. Je pense que les attentes sont plus nombreuses que l'on pense et qu'éviter des allers retours nous ferait gagner du temps. Ce n'est qu'une intime conviction, à vérifier.

kanban-symboles.png

Cela fait environ presque deux mois que l'opération est appliquées sur les user stories mais aussi les imprévus. A chaque MEP, je loggue le cycle de vie de la user story dans un fichier excel, Je renseigne également le nombre de jours ouvrés entre la création d'une demande et sa priorisation. Voici les premiers retours :

  1. toute l'équipe voit au standup depuis quand une story a été engagée. Cela permet de voir des problèmes potentiels.
  2. il y a plus de retours de recette que je pensais
  3. on voit tout de suite les stories qui trainent depuis plus d'une itération.
  4. c'est surprenant de calculer les métriques en partant de ce qui est visible en prod. Vu de l'extérieur, il y a relativement peu de choses livrées au final pour l'utilisateur. Cela fait bizarre car nous sommes chaque jour 100% occupés à faire cela. L'écart est presque choquant.
  5. je sais à peu près en combien de temps en moyenne un imprévu important va être traité. C'est encore trop variable pour une user story par contre. Cela nous permettra de donner des délais approximatifs aux clients.
  6. entre le moment où un ticket est crée et où il est priorisé, il peut s'écouler plusieurs mois. C'est logique : 1. c'est plus facile de créer un ticket que de faire des specs+développer+recetter+mettre en prod. 2. il y a beaucoup plus de personnes pour créer les tickets que pour les traiter. 3. Ils n'ont pas tous la même importance et la même urgence. En conséquence, j'ai ventilé les tickets par catégorie afin de donner un peu de relief : ticket projet, ticket hot topic et ticket problème de production.

Lorsque j'aurais plus de données, je pourrai travailler efficacement sur notre lead time.

Je veux livrer ce billet maintenant. J'aurais pu le publier sur barre verte et du coup avoir une top qualité (chaque billet est relu par plusieurs personnes avant publication). Mais pour un billet qui parle de livrer vite, ce serait un comble. Je le relirai plus tard, ou pas. J'espère que toutes les phrases ont un sens. Bonne nuit !