Introduction

Le mois dernier, le responsable d’un projet – au sens manager – d’un projet SCRUM qui a débuté il y a trois mois est venu me voir. Il était très inquiet car après avoir ré-estimé le backlog, l’effort nécessaire pour réaliser le projet avait été multiplié par deux. Or il avait besoin de comprendre, afin de pouvoir aider l’équipe et le projet à s’en sortir.

Vous l’aurez compris, le contexte organisationnel n’est pas encore complètement mature. Pour autant, la volonté des membres de l’équipe et du management est présente, et sans vouloir tout de suite m’attaquer à l’organisation globale, je cherche des moyens pour déjà mettre en place les bons réflexes à ce niveau.

Comme cette question est déjà revenue plusieurs fois ces dernières années. Et les réponses que j’ai apportées, et les actions qui ont été réalisées en retour ne m’ont que rarement satisfait.

L’objectif de cet article est de partager mes réflexions sur ce thème.

REX : ce qu’il ne faut pas faire

Face à ce type de situations anxiogènes, j’ai vu s’élaborer plusieurs types de stratégies :

• Evaluer en détail tout un backlog pour un projet de 2 ans et des dépendances fortes avec un projet Cycle en V :
  • l’évaluation très macroscopique initiale malgré toutes les réserves émises a pourtant été interprétée comme un engagement
• Communiquer un burnup produit idéal avant le début du projet
  • Ce burnup prévoyait une vélocité qui s’est avérée trop optimiste par rapport à la réalité. Le problème, c’est que cet écart a été interprété comme un manque ou un défaut de l’équipe. Et non comme une mauvaise estimation…
• Ajouter du budget pour financer un(des) développeur(s) supplémentaire(s) :
  • la production de l’équipe n’a pas augmenté pendant plusieurs semaines. Et l’augmentation mesurée à terme sur la vélocité ne peut pas être associée uniquement aux personnes ajoutées, étant donné que d’autres actions ont été entreprises.
• Définir un nombre de Storypoint « prévus » au projet (contractualisation entre le PO et l’équipe), et suivre tous les écarts :
  • les difficultés de l’équipe se sont reportées ailleurs, dans les nouvelles estimations, dans la simplification sans tenir compte de la valeur pour l’utilisateur. Ce fonctionnement a été rapidement abandonné par le Product Owner et l’équipe.
• Enlever une grosse fonctionnalité complète :
  • cela a permis de diminuer l’attente, mais cela a aussi généré de la frustration. Pour qu’au final, on réintègre une version simplifiée de la grosse fonctionnalité.
• Négocier la qualité : diminuer les critères de qualité de la Definition of Done. Accepter des anomalies et des défauts mineurs et majeurs non bloquants. Ne plus automatiser les tests.
  • quelques sprints plus tard la vélocité a tellement baissé qu’il a fallu dédier 2-3 sprints à résoudre la dette technique principale.