À l’ordre du jour du “sprint planning” du lundi matin, figure une “User Story Technique” :

Les développeurs, à la suite d’une revue de la conception, proposent une tâche importante de remaniement, qui devrait occuper une partie de l’équipe pour plusieurs heures. Faire ce refactoring, c’est renoncer à livrer une voire deux stories à la fin du sprint.

Le Product Owner écarte la proposition pratiquement d’un revers de la main : en regard des enjeux de la prochaine démo, et vu l’allure générale à laquelle avance ce projet (une allure jugée inquiétante par le Métier) l’amélioration proposée est considérée comme secondaire, et les efforts dans ce sens comme dispendieux (“Vous vous faites plaisir”).

🔺 Revoilà notre triangle de fer. Rapide, bon marché, de qualité : choisis en deux.

La Technique et le Métier se retrouvent à négocier une fonctionnalité. (Ou bien négocier un refactoring, c’est pareil). L’une renvoie l’autre dans ses filets, et réciproquement :

— Pour des raisons techniques, il va falloir temporairement sacrifier une feature ou deux. Nous te laissons choisir lesquelles.
— La modularité du code, c’est bien gentil, mais ce n’est pas le problème. Vous ferez ça plus tard.

😰😡😣

Bien sûr, comme ces acteurs sont humains, et la culture de l’entreprise où ils travaillent étant ce qu’elle est, la meilleure manière pour chacun de traverser ce conflit passe plutôt par le “drame” d’abord avant de passer à la réflexion posée. Ce n’est pas facile de se poser pour réfléchir ensemble quand les fins de non-recevoir et les sous-entendus même subtils, ainsi que nos propres réactions abîment notre estime de soi. 💬💭🗯

Si elle pouvait lever le brouillard du “drame” (qui fait certes le délice des amateurs de bonnes séries mais complique diablement les choses dans l’entreprise), l’équipe procéderait probablement plus efficacement, ou en tout cas avec une certaine méthode : elle verrait alors que le conflit n’est qu’apparent (c’est un conflit d’idées en vue de réaliser un objectif commun) et qu’il peut être résolu.

Par exemple en utilisant un diagrame de résolution de conflit (Evaporating Cloud) :

A : l’objectif est de livrer sur le marché un produit supérieur, maintenant et dans le futur
B : besoin : offrir des features inédites avant la concurrence
C : besoin : changer facilement la conception du produit
D : objectif respectif : inclure le maximum de stories dans ce sprint
D’ : objectif respectif : améliorer la modularité du code dans ce sprint

  ↙️  B ⬅️  D
A         ⚡️
  ↖️  C ⬅️  D'

Chaque flèche symbolise une hypothèse de nécessité. En analysant chacune des hypothèses, le groupe va pouvoir

  • séparer les conditions réelles des conditions seulement présupposées
  • injecter des solutions possibles qui rendraient une ou plusieurs conditions caduques
  • effectivement résoudre le conflit

tout en se posant la question de l’état de l’art : Quel problème voulons nous résoudre ensemble ?

publié sur LinkedIn le 13/03/2023