Première journée d’un nouveau sprint. C’est parti!

Pour une base de travail initiale, capacité de l’équipe = moyenne des points livrés jusqu’à aujourd’hui. Pour ce sprint, j’interdis à l’équipe d’en prendre plus. Dans les faits, j’ai même limité l’équipe à 1 point en dessous de cette moyenne.

Première implication : Le carnet doit être bien ordonné, car l’équipe s’engage sur peu d’items. Ces items doivent être clairs sur le plan des besoins sinon on n’en tiendra pas compte. Deuxième implication : La définition de « terminé » doit être visible, connue de tous et à jour.

Pour des fondements plus solides sur la durée du sprint, l’objectif suivant est de permettre à l’équipe de suivre son avancement. Pour cela, j’impose des tâches courtes, pas plus longue qu’une journée. L’idée est qu’à chaque mêlée quotidienne, une tâche doit être terminée, une autre commencée. Si ça dérape, l’équipe peut le voir et s’ajuster en conséquence.

Avec ces deux éléments de base, lors du premier sprint, l’équipe livre les items sur lesquels elle s’est engagée, y compris au passage le « paiement » d’une partie de la dette accumulée en termes de code et de tests.

Au cours des sprints suivants, j’ai raffiné avec l’équipe certaines pratiques, comme le découpage en tâches, ajusté la définition de « terminé », amené l’équipe à tenir les blocs de temps pour les rencontres, etc., pour ne citer que quelques interventions.

En parallèle, l’équipe a réestimé l’ampleur du carnet de produit restant, le PO a réordonné les items, complété les besoins pour chaque item.

Le gain majeur pour tout le monde, c’est que l’équipe s’est significativement améliorée sur plusieurs points tels que l’estimation des items, la prévisibilité en termes de capacité à livrer, la qualité du bien livrable.

Au final, après quelques sprints seulement, l’équipe a livré, à la date révisée, avec un excellent niveau de qualité et une satisfaction des besoins utilisateurs rarement atteinte.

Vous vivez une situation semblable? Un expert de Pyxis peut vous aider à la rétablir. Voulez-vous essayer?

Quelques billets qui pourraient vous intéresser :

• Faut-il réestimer les stories non terminées ou celles refusées par le PO à la fin du sprint?
• Les points de visibilité en Scrum : comment choisir la longueur des itérations?
• Estimer un carnet de produit complet en 2 heures : Wall Planning Poker

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 :

1. évaluer la vraie capacité de l’équipe;
2. limiter l’équipe à sa capacité réelle;
3. ordonner le carnet de produit en travaillant avec le PO et l’équipe;
4. réviser la définition de « terminé »;
5. améliorer le découpage des items du carnet de produit en tâches courtes (limitées à 1 journée maximum);
6. 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?