Mon projet dérape. Rien n’est perdu, mais il faut agir… maintenant! – Partie 1
Votre équipe a commencé son premier projet en mode Agile sur les chapeaux de roues. Les développeurs sont motivés, fiers de travailler ensemble et avec le propriétaire de produit (ou Product Owner ou PO), de participer activement à la conception de l’application et d’affiner les besoins avec le PO qui tient compte de leurs commentaires. Après 2 sprints, tout le monde pense avoir compris ce nouveau mode de travail que l’on appelle Scrum. L’équipe décide alors que le soutien du coach Agile n’est plus requis.
Mais « Scrum, c’est simple à comprendre; le mettre en œuvre, c’est difficile. »
Et pendant tout ce temps, sans s’en apercevoir, l’équipe a pris une route qui s’annonce chaotique.
Les membres de l’équipe ont commencé à faire des heures supplémentaires. Les fonctionnalités promises ne sont pas « terminées », donc pas livrées. L’engagement est, sprint après sprint, trop important par rapport à la capacité réelle de l’équipe. De plus, cette dernière accepte souvent de commencer le développement de fonctionnalités alors que le PO ne sait pas encore ce qu’il veut.
Résultat : La pression monte, la date de livraison approche, les fonctionnalités reviennent sprint après sprint, car elles ne sont pas complétées, etc.
À 2 semaines de la date de livraison initialement prévue, la bulle éclate. Nous ne pourrons pas livrer! À ce moment-là, l’équipe est démotivée, fatiguée par les heures supplémentaires et aussi peu fière de la qualité du travail fournie, car pour maintenir le rythme, il a fallu « couper les coins ronds ».
Maintenant, il est vital d’agir vite, de prendre une décision : « Stop ou encore? » Tout le monde pourrait passer du temps à regarder ce qui n’a pas fonctionné et à chercher des coupables. Pour être franc, ça soulage, mais ça ne fait pas avancer la solution. Il est nécessaire de redresser la situation : avertir les gestionnaires, préparer un plan qui leur sera présenté, comprenant notamment une planification et un budget revus; et ensuite, évaluer ce dernier : le projet est-il toujours rentable?
Ces activités prennent du temps, et il n’est plus question d’en perdre. Il faut, dès maintenant, commencer à mettre en place des correctifs. Pour s’aider, l’équipe décide de rappeler un coach Agile; moi dans cette circonstance.
Mon intervention se passe sur 2 plans. Le premier, auprès de l’équipe, consiste à lui permettre de reprendre le contrôle et de livrer. Le second, auprès du chef de projet et des gestionnaires, consiste à les assister dans la révision du plan de projet. Je vais m’attarder sur le premier volet de mon intervention pour ce billet : aider l’équipe à livrer.
Cela se résume en quelques interventions ciblées à court terme qui seront approfondies sur un plus long terme afin de les intégrer, de les ancrer fermement.
Voici ces interventions ciblées :
- évaluer la vraie capacité de l’équipe;
- limiter l’équipe à sa capacité réelle;
- ordonner le carnet de produit en travaillant avec le PO et l’équipe;
- réviser la définition de « terminé »;
- améliorer le découpage des items du carnet de produit en tâches courtes (limitées à 1 journée maximum);
- commencer à payer la dette de code et de tests.
Dès demain, une nouvelle étape! La première journée d’un nouveau sprint, que je vous présenterai dans un prochain billet dès mercredi prochain.
Vous vivez une situation semblable? Un expert de Pyxis peut vous aider à la rétablir. Voulez-vous essayer?
