Six signes que l'accélération de votre équipe est trop belle pour être vraie

Permettez-moi de dire d'emblée que je suis un grand fan du suivi de la vélocité dans Scrum... c'est un concept incroyablement puissant.

• La capacité de mesurer les résultats de l'équipe d'un sprint à l'autre permet à l'équipe d'expérimenter systématiquement différentes améliorations de processus et de s'améliorer constamment au fil du temps.
• Le fait d'avoir une idée claire de la quantité de produits que l'équipe produit réellement au cours d'un sprint permet également de prendre de meilleures décisions quant au moment où le projet doit être achevé sans que l'équipe qui l'élabore ne soit réduite à l'état d'esclave.
• En tant que leader agile, j'aime savoir si mes équipes accélèrent, décélèrent ou restent stables dans le temps. Si elles accélèrent, je suis convaincu que les dates d'achèvement prévues sont relativement sûres, alors que si elles sont stables ou en décélération, cela implique un risque plus important dans les projections actuelles.

1. Vélocité augmente toujours - Même les équipes les plus performantes subissent des revers ou rencontrent de nouveaux obstacles. En général, les équipes scrum qui se fixent des objectifs ambitieux doivent s'attendre à échouer environ 20% de leurs sprints, ce qui signifie que la vélocité devrait diminuer par rapport au sprint précédent dans le même pourcentage de temps (si vous utilisez la "météo d'hier" pour intégrer des histoires dans le sprint). Si votre équipe a traversé une douzaine de sprints sans un seul recul de la vélocité, cela suggère que cette tendance stable à la hausse est gérée plus délibérément qu'elle ne devrait l'être.
2. Accélération inexplicable - La vélocité peut augmenter sans raison particulière, mais il est difficile de maintenir une amélioration structurelle de la vélocité sans éliminer systématiquement les obstacles rencontrés par l'équipe. Par conséquent, si la vélocité d'une équipe a augmenté de façon constante mais qu'elle ne peut pas indiquer les obstacles spécifiques qu'elle a supprimés, il s'agit d'un signal d'alarme indiquant que l'accélération n'est peut-être pas réelle. Au mieux, l'équipe ne mène pas d'expériences saines sur les processus afin d'obtenir une accélération répétable et durable. Au pire, elle risque de compromettre la pertinence de sa vélocité.
3. La même histoire reçoit aujourd'hui une estimation de points plus élevée qu'auparavant - C'est la définition de l'"inflation de points" que les opposants à la mesure de la vélocité en points pointent toujours du doigt. Dans la pratique, nous voyons rarement des cas flagrants d'inflation de points où la même histoire qui était à 3 points dans un sprint précédent est maintenant à 5 points dans le sprint en cours. Nous rencontrons plutôt des formes plus nuancées d'inflation, par exemple lorsqu'un contrôle de qualité supplémentaire est ajouté pour corriger des problèmes antérieurs et que des points sont ajoutés pour réaliser ce travail supplémentaire. La quantité d'efforts nécessaires pour réaliser le travail peut avoir augmenté, mais pas la quantité de résultats, de sorte que ces points supplémentaires représentent une forme subtile d'inflation des points.
4. Remplissage du carnet de commandes avec des "histoires de remplissage". - Les équipes qui s'efforcent d'augmenter la vélocité deviennent souvent obsédées par le fait de s'assurer que tout ce qu'elles font est reflété dans le backlog. En général, vous ne voulez pas faire des tonnes de travail en dehors du backlog et vous voulez rester concentré sur la réalisation des objectifs du sprint. Cependant, un certain niveau de ménage et de travail d'hygiène de l'équipe fait naturellement partie du processus de groupe. Si l'inclusion de ces éléments dans le backlog a toujours été une norme pour l'équipe... c'est très bien. Si cela n'a pas toujours été le cas, l'inclusion de ces histoires de remplissage avec les points associés donne la fausse impression que l'équipe accélère alors qu'elle ne produit pas réellement plus.
5. Beaucoup d'histoires distinctes de taille minimale - Nous disons souvent que les petites histoires d'utilisateur sont meilleures, et qu'en fin de compte les équipes devraient s'efforcer de travailler avec des histoires uniformément petites dans le sprint. C'est un excellent objectif, mais il peut être poussé trop loin. Si le travail est divisé en de nombreuses histoires qui sont plus petites que le plus petit incrément de taille utilisé par l'équipe ("xs", "1-point", "Chihuahua", etc.), alors l'erreur d'arrondi de l'addition de toutes ces histoires fractionnaires commence à exercer une forte influence à la hausse sur la vélocité. Si ces histoires divisées avec précision sont toujours de bonnes histoires d'utilisateur reflétant une fonctionnalité incrémentale, il est alors temps de réinitialiser votre histoire de référence pour l'adapter à des divisions plus petites. Le plus souvent, cependant, ces petites histoires sont en réalité des tâches et nuisent à la capacité de l'équipe à travailler ensemble pour produire un produit de qualité.
6. - Le suivi de la force de l'équipe dans chaque sprint est utile pour connaître le contexte dans lequel l'équipe opère. Il existe un certain nombre de raisons convaincantes d'appliquer un niveau de normalisation léger à la vélocité brute d'une équipe afin d'obtenir un meilleur indicateur de la production réelle de l'équipe : cela permet d'obtenir une mesure plus stable de la production en cas de maladie grave, de vacances, de congés familiaux et d'autres changements significatifs dans la capacité de l'équipe. Les équipes doivent donc veiller à ne réserver les ajustements de normalisation qu'aux impacts majeurs sur la capacité et à ne pas essayer de les ajuster pour chaque changement perçu dans la force de l'équipe. Si vous remarquez que l'équipe n'est pas à pleine capacité depuis longtemps, il est temps de se demander s'il n'y a pas un excès de normalisation.