Quand un binôme PO-Proxy PO se laisse happer par leur backlog, c’est toute l’équipe qui subit.
La situation
Situation observée sur un projet en Kanban d’une autre équipe :
- Pas de cadre défini sur le Kanban à part … 4 colonnes
- Pas de stand up, ni tout autre rituel : pas de communication dans l’équipe
- Un projet qui devait durer 2 mois et qui va en durer 7 au final!
- Un proxy PO pas assez formé
- Un PO trop gourmand
- Des “découvertes” en cours de projet qui ajoutent du travail
Bref, le projet qui devait durer 2 mois s’éternise, les difficultés s’accumulent, et chaque équipier a son propre son de cloche.
On se retrouve avec un projet en perdition, et un impact fort sur tout le service dû au retard et aux ressources monopolisées.
Le Scrum Master, au secours du Proxy Po, s’entend dire que le Proxy PO n’a plus le temps de gérer son backlog car trop de boulot! Et oui, le Proxy PO au vu de la situation s’était mis à réaliser pour rattraper le retard au détriment du backlog, à la dérive. Tout ce qu’il faut éviter.
Explications
Bon, plus la situation avançait, plus elle s’enlisait.
Et on se retrouve dans le contexte de personnes “nez dans le guidon” qui cherchent à abattre le plus de travail possible… sans se poser de questions.
Et, ce n’est pas la première fois que j’entends que la gestion de backlog (de projet, au final) est une perte de temps.
Remettons les pendules à l’heure : oui gérer un projet prend du temps. Mais c’est une garantie de bon fonctionnement.
Sans cela, comment faire les bons choix, fédérer une équipe, rendre compte au client… ?
Alors si on enlève cette partie et que l’on se lance tête baissée dans la réalisation, c’est la garantie de ne pas faire les bonnes choses, dans le bon ordre et de partir vers un bel effet tunnel. Au final peut-être que le rendu sera correct, mais à quel prix!
Remède ?
Le Scrum master a fourni un fort accompagnement du proxy PO pour remettre au propre le backlog, le planning, les besoins de ressources.
Cela a permis de réintroduire un équilibre entre les demandes insistantes du PO et les besoins de l’équipe.
Il en a profité pour réexpliquer les concepts de base et échanger avec chaque membre de l’équipe. La mise en place de stand up s’est avérée efficace.
Le planning a été réévalué en fonction des aléas.
Bilan
En discutant avec le Scrum Master, nous en sommes venus à la conclusion que nous devions poser un cadre plus fort sur Kanban, en s’inspirant des projets que nous menions en Scrum… ou de partir directement sur Scrum.
Rituels, définition des rôles, démo, rétrospectives : tous ces éléments ont manqués depuis le début et auraient pu permettre une fin bien plus heureuse!
