tremeur balbous
Articles de tremeur :
Mon projet dérape. Rien n’est perdu, mais il faut agir… maintenant! – Partie 2
Dans mon dernier billet, je vous ai présenté la situation entourant un projet en difficulté. Dans celui-ci, je présenterai succinctement quelques interventions…
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.
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.