• Le folklore du « toujours plus »
• La Perspective de l’Outcome : Livrer moins pour impacter plus
• Délai et Focalisation
  • La Loi de Little appliquée au Produit
  • No estimates…
  • …Ou presque
• Vers le bénéfice des bons outils
• Ressources

Beaucoup d’organisations imaginent que « devenir agile » consiste à construire une « machine de guerre » capable de livrer plus de fonctionnalités, plus vite. Pourtant, comme je l’évoquais au sujet du PRD, si nous ne comprenons pas le « pourquoi », on finit par construire très efficacement des solutions dont personne ne veut.

Pour sortir de ce mirage, nous devons revoir notre rapport à la performance, pour disposer d’une mesure efficace.

§Le folklore du « toujours plus »

J’ai souvent vu des équipes mesurer la vélocité, comme si c’était l’étalon de performance ultime… Nous voulons la voir grimper, sprint après sprint, comme s’il s’agissait d’une course de fond.

La mesure de cette vélocité repose sur le nombre de tickets traités, ou plus souvent sur le nombre de points (ou story points) estimés sur les tâches et traités durant le sprint. Le but de l’équipe est alors d’améliorer la proportion de points traités, et le nombre total de points traités, pour montrer au manager un magnifique dashboard avec des courbes qui montent.

Pourtant, la vélocité ne fait pas partie de Scrum, pas plus que les story points ; ils appartiennent à son folklore. Ce sont même des concepts anti-agiles : les utiliser comme indicateur de performance est destructeur. 

D’une part, la vélocité tue l’entraide, car chaque membre de l’équipe se focalise sur sa performance au détriment de l’ensemble ; et d’autre part, il est facile de fausser la vélocité, en jouant sur l’estimation des tickets pour simuler une augmentation artificielle du nombre de points.

Quant à ces derniers, je les ai souvent trouvés indexés à un délai de traitement des tâches « ½ point, c’est 2h ; une journée, c’est deux points. » Nous nous retrouvons à traiter les points comme des nombres de jours/homme pour un chef de projet…

§La Perspective de l’Outcome : Livrer moins pour impacter plus

Entre la mesure de l’effort et la gestion du délai, il existe un espace vital que nous oublions souvent : l’apport de valeur (aussi appelé outcome). L’outcome, c’est ce qui arrive après la livraison : c’est le changement de comportement que nous observons chez nos clients, l’amélioration de leur expérience.

Une équipe performante n’est pas celle qui livre 50 tickets (output), mais celle qui, avec seulement 5 tickets, parvient à lever la friction majeure de son parcours utilisateur. En agilité, le succès se mesure à la satisfaction et à l’impact, et non au volume de code produit.

§Délai et Focalisation

§La Loi de Little appliquée au Produit

Si nous cessons de regarder la productivité pure, sur quoi devons-nous nous focaliser ?

Le professeur John Little (du  MIT) a mené une recherche nous expliquant que plus il y a de travaux en cours, plus le temps de cycle est long. Pour réduire ce délai, il faut limiter la dispersion : se concentrer sur un seul sujet pour le mener au bout.

Pour mesurer le temps réel que prend une idée pour passer du début de sa conception à sa mise en production, nous utilisons le Temps de Cycle (ou Cycle Time). Ce temps sera d’autant plus court que l’équipe se sera focalisée efficacement sur l’objectif de sprint.

Pour approfondir ces concepts, je vous recommande l’article de Business Map (cf. les sources), qui les explique particulièrement bien.

§No estimates…

Face aux imprécisions, aux biais cognitifs et au gaspillage de temps liés aux estimations classiques, des experts comme Woody Zuill et Vasco Duarte ont proposé le No Estimates comme une philosophie focalisée sur la création de valeur et les données empiriques : l’historique des précédents sprints, tel que l’estimation des précédentes stories par rapport aux résultats réels, ou les mesures de temps de cycle.

§…Ou presque

Dans la pratique, nous n’avons pas su mettre en œuvre le temps de cycle, car il était trop abstrait aux yeux des développeurs. Par contre, nous avons pu exploiter efficacement les précédentes estimations des tickets, et nous nous sommes efforcés de découper les tâches au maximum pour en faciliter l’estimation. Et lorsque l’incertitude persistait, nous cherchions l’origine des incertitudes.

Il s’agissait souvent d’incertitudes techniques, que nous avons traitées via des explorations techniques (les spikes), ou bien un manque de clarté fonctionnelle. Dans ce second cas, soit le Product Owner affinait la précision des stories, soit des explorations étaient menées, mais sur l’aspect fonctionnel. Pour une interface web, nous pouvions proposer des maquettes et prototypes aux utilisateurs pour réduire l’incertitude fonctionnelle, en amont du sprint. Nous avons déjà exploré ces démonstrateurs lorsqu’il était question de passer du PRD à l’action.

§Vers le bénéfice des bons outils

Piloter par le délai plutôt que par la productivité n’est pas qu’un choix méthodologique, c’est une question de crédibilité stratégique. Et la clé réside dans l’usage des bons outils de mesure.

En nous éloignant du mirage de la vélocité, nous avons pu améliorer notre maîtrise de notre sprint. Au lieu de chercher à produire à tout prix, nous avons pu nous focaliser sur produire mieux, tout en maîtrisant mieux nos sujets.

Car au bout du compte, ce n’est pas la vitesse qui importe, c’est le temps qu’il nous faut pour apporter, enfin, une réponse au besoin.

§Ressources

• User Story Mapping, Discover the Whole Story, Build the Right Product.
• Écrits de Woody Zuill sur le No Estimates .
• Kanban : Délai vs Temps de Cycle, sur businessmap.