L'équipe faisait exactement ce qu'on lui demandait.

Ce qu'on nous a dit

Une organisation de développement rencontrait des difficultés de productivité.

Le travail prenait plus de temps que prévu. Les fonctionnalités arrivaient en revue mais n’étaient pas acceptées. Les mises en production prenaient du retard.

Du côté produit, l'explication semblait simple : l'équipe de développement ne livrait pas de façon constante ce qui avait été demandé.

Si cette explication était correcte, l'endroit évident où enquêter était la productivité en ingénierie.

Ce que nous avons observé

L'équipe travaillait de façon itérative.

Avant l'implémentation, une story était discutée et le comportement attendu était défini. L'équipe de développement implémentait ensuite ce comportement pendant le sprint.

Les ingénieurs n'ignoraient pas ces exigences.

Ils les implémentaient.

Le problème apparaissait plus tard.

Pendant la revue, un comportement qui ne faisait pas partie des critères d'acceptation convenus devenait parfois nécessaire pour que le travail soit accepté.

Par exemple, une story pouvait définir un flux de travail donné pour une opération particulière.

Au moment de la revue, une condition supplémentaire pouvait être introduite : dans certaines circonstances, une partie de ce flux devait être automatiquement ignorée.

Dans un autre cas, le comportement convenu pouvait préciser comment le système devait informer un utilisateur en cas d'échec d'une opération.

Au moment de la revue, l'attente pouvait devenir que le système lui-même se rétablisse de l'échec, sans exiger que l'utilisateur intervienne.

Dans un autre encore, une fonctionnalité d'aperçu pouvait satisfaire les critères convenus, avant qu'une fonctionnalité de manipulation supplémentaire ne devienne nécessaire pendant la revue.

Chaque demande pouvait être raisonnable.

Ce n'était pas le problème.

Le schéma

Les nouvelles attentes n'étaient pas traitées comme des modifications de la spécification.

Elles étaient traitées comme la preuve que l'équipe de développement n'avait pas correctement implémenté la spécification d'origine.

Cette distinction changeait tout.

Du point de vue du product owner, la fonctionnalité demandée n'était pas terminée.

Du point de vue de l'équipe de développement, les critères d'acceptation convenus avaient été implémentés — et de nouvelles exigences apparaissaient après l'implémentation.

L'organisation qualifiait le retard qui en résultait de mauvaise productivité en ingénierie.

Mais la séquence de travail observable était différente :

1. Les critères d'acceptation étaient convenus.
2. L'équipe de développement les implémentait.
3. De nouvelles attentes apparaissaient pendant la revue.
4. Les nouvelles attentes n'étaient pas classées comme des modifications.
5. L'implémentation d'origine était donc considérée comme incomplète.
6. Le travail supplémentaire allongeait le délai de livraison.
7. Le retard était attribué à la productivité en ingénierie.

Notre hypothèse

L'équipe de développement ne souffrait pas, avant tout, d'un problème de productivité.

Le système utilisé pour déterminer si le travail était terminé était instable.

L'équipe pouvait satisfaire les critères d'acceptation en vigueur au début de l'implémentation et néanmoins échouer à la revue, parce que les critères réellement appliqués avaient changé au moment où le travail était évalué.

Cela crée un problème de productivité particulièrement difficile à résoudre.

Améliorer la vitesse de codage ne le résout pas.

Améliorer les outils ne le résout pas.

Demander aux développeurs d'estimer plus précisément ne le résout pas.

Même rendre l'équipe nettement plus rapide ne ferait que lui faire atteindre plus tôt une cible mouvante.

Pourquoi le problème était difficile à voir

Personne n'avait besoin d'être malhonnête pour que ce système apparaisse.

Le product owner pouvait sincèrement croire que le comportement supplémentaire faisait manifestement partie de ce qui avait été initialement demandé.

Les développeurs pouvaient sincèrement croire avoir implémenté exactement ce qui avait été convenu.

Les deux affirmations pouvaient décrire avec exactitude la compréhension de chacun.

Aucune des deux, à elle seule, ne décrivait ce qui arrivait réellement au travail.

Nous n'avions donc pas besoin de décider quelle interprétation était correcte.

Nous avons comparé les critères d'acceptation en vigueur avant l'implémentation aux attentes appliquées pendant la revue.

La différence était observable.

Ce que les faits ont montré

Le problème signalé était une faible productivité en ingénierie.

Le problème observé était que les conditions d'acceptation d'un travail terminé pouvaient changer après que ce travail avait déjà été implémenté.

En conséquence, un travail conforme à la spécification convenue pouvait tout de même être classé comme incomplet.

L'équipe était évaluée par rapport à des exigences qui n'existaient pas nécessairement au début du travail.

Cela signifiait que le problème de productivité apparent ne pouvait pas être résolu en optimisant les développeurs seuls.

Les développeurs ne manquaient pas aux critères d'acceptation. Ce sont les critères d'acceptation qui se déplaçaient une fois le travail terminé.

Le point de vue de Pulsar

Si nous avions accepté le diagnostic initial, nous aurions commencé par nous demander comment rendre l'équipe de développement plus rapide.

Nous avons plutôt suivi le travail depuis l'accord jusqu'à l'implémentation, puis la revue.

La différence entre ce que l'organisation appelait le problème et ce que le travail lui-même nous montrait constituait le signal utile.

Le problème annoncé était la productivité en ingénierie. Le problème observable se trouvait ailleurs.