Vous l’avez peut-être lu par le passé, je me débat avec une équipe qui voit la méthode comme une contrainte. Au chapitre des difficultés … l’objectif de sprint
- Déjà, au départ c’était « bon, quelles US on prend dans ce sprint ? » … puis « bon, alors quels objectifs on met au sprint ? » . OK, on est parti de loin
Après avoir fighté pour expliquer que les US étaient au service de l’objectif, on est arrivé marcher dans le bon sens.
Mais c’est pas aussi simple.
On se retrouve avec des sprints qui ont comme objectif(s) des trucs comme :
- Continuer les travaux sur le lot 1 (*) de …
- Avancer sur l’outillage de tests du Générateur …
- Préparer le remplacement de …
Continuer, avancer, préparer … Pas de livrable, pas d’incrément de produit. Rien de concret.
Pas du Scrum … au mieux du Kanban. Et encore, il faudrait définir des WIPs
Mais ce qui me turlupine, c’est qu’en fait l’équipe manipule la méthode pour faire en fait ce qu’ils veulent et notamment s’affranchir de tout engagement.
On sauvegarde les apparences. DSM (devenu simple reporting), Démo de quelques fonctionnalités, Rétro pour se plaindre, Sprint planning pour « avancer, continuer, préparer … »
Assez naturellement, vous allez me répondre que le Scrum master doit les convaincre du bien fondé de la chose. Certes, mais dans l’organisation, le PO est issu d’une direction métier qui se comporte en donneur d’ordre à un équipe qui dépend de l’IT. Et le PO se positionne quasiment en CP de l’équipe.
Bref, l’espace est restreint pour le SM …
Comment à réagir quand l’équipe me sort de tels objectifs de sprint aussi peu concrets ?
(*) Je sais, le « lot » est issu d’un « lotissement » fonctionnel, avatar d’un cycle en V planifé selon une roadmap métier. Mais je dois faire avec, c’est le métier qui décide, l’IT s’exécute …