Category: Scrum

Scrum – The Art of Doing Twice the Work in Half the Time

C’est sans doute un des titres les plus long de la littérature mais il correspond tellement bien à ce livre ! Jeff Sutherland est le co-rédacteur du Scrum Guide avec Ken Schwaber. Ensemble, ils ont créé Scrum, un Framwork Agile simple et léger permettant de développer des projets ou  produits complexes.

Jeff nous emporte dans la génèse du Framework Scrum où il expirimenta ses premières versions dans les années 80. De par ses expériences, il a pu démontrer que lorsqu’une équipe  s’auto organise et évolue de manière itérative autour d’un objectif commun, les résultats obtenus sont souvent de bien meilleure qualité qu’une équipe executant les ordres d’un suppérieur hierarchique. Cette approche permet de construire des produits ou des projets complexes, en capitalisant sur l’expérience et le professionalisme de l’équipe de développement. Vous découvirez que l’ensemble du Scrum Guide peut s’appliquer à de nombreux contextes.

Je vous conseille ce livre si vous souhaitez en savoir plus sur la génèse du Framework Scrum et sur la vie d’un de ses inventeurs.

Bonne lecture !

La vélocité est-elle un indicateur de performance ?

La vélocité est souvent un indicateur mal utilisé  sur des projets Agile. Il est souvent confondu avec le temps consommé sur un sprint et est utilisé par le management pour contrôler la productivité des équipes Scrum. L’objectif de cet article est de comprendre la notion de vélocité et de l’utiliser correctement sur vos projets.

Calcul de la vélocité

Tout d’abord, comprenons le calcul de la vélocité. Au niveau d’une équipe Scrum, il s’agit de la somme des points des PBIs (Product Backlog Items) Done ✅ à l’issue d’un Sprint. Elle est représentée la plupart du temps sous forme d’histogramme permettant de visualiser l’évolution du nombre de points au fil des sprints. Au niveau d’un programme en Agile @ Scale de type SAFe, la vélocité pourra être consolidée au niveau d’un Release Train.

D’où viennent ces points

En Scrum, l’estimation des PBIs est confiée à l’équipe de développement (et uniquement à l’équipe de développement !). Lors des sessions de Product Backlog Refinement, l’équipe estime l’effort du PBIs en points. Cet indicateur est totalement empirique. L’équipe suit en général une suite de Fibonacci pour le quantifier. Des outils simples à mettre en place comme le T-Shirt sizing ou le planning poker sont très efficaces pour lever tout doute sur la complexité du PBI à livrer. Durant ces sessions, beaucoup de questions remontent de l’équipe vers le product owner pour clarifier les Acceptance Criterias du PBI afin de calculer l’effort le plus juste possible.La vélocité planifiée dans le Sprint est déterminé à l’issue du Sprint planning. Il s’agit de la somme des points pour les PBI sur lesquels l’équipe s’est engagée. Il s’agit d’un indicateur de planification ou de Forecast.

Un indicateur empirique

En suivant les concepts de Lean, l’équipe doit chercher à s’auto-évaluer, mesurer de manière factuelle son efficacité et s’améliorer de manière continue. La vélocité est un indicateur propre à chaque équipe. Il ne peut être comparé d’une équipe à l’autre. C’est un indicateur défini par l’équipe pour servir l’équipe ! La vélocité évolue tout au long du projet à chaque Sprint. Les variations peuvent s’expliquer par :

  • Une variation de capacité de l’équipe : Par exemple, un développeur en vacances
  • Des impediments bloquant l’évolution de  l’équipe dans l’achèvement du Sprint Backlog
  • Un manque de rigueur dans le refinement du Backlog
  • Un manque de rigueur dans l’application de Scrum en général.

Lors de la Sprint Rétrospective, l’ensemble de l’équipe Scrum (Product Owner, Scrum Master et Dev Team) peuvent analyser leur propre vélocité pour comprendre les potentiels problèmes et trouver un plan d’action pour les résoudre.

Une vélocité stable, un bon indicateur

La vélocité met en général 3 à 5 Sprints à se stabiliser suivant les équipes. Une fois stable, elle devient un excellent outil de prédiction. Une vélocité stable sur plusieurs sprints indique la charge nominale de l’équipe. Il ne faut pas chercher à l’augmenter à tout prix au risque de compromettre la qualité de l’incrément.

Les dérives du suivi de la vélocité

Lorsque la vélocité est monitorée par le management et prise en compte comme un indicateur de performance cela conduit à de nombreuses dérivent qui nuisent au respect des valeurs de Scrum et peuvent impacted considérablement la productivité du projet.

  • Augmenter la vélocité à tout prix : L’équipe peut très bien décider de le faire mais ne doit pas se le faire imposer. Si c’est la cas, la nature humaine est bien faite et les développeurs vont automatiquement augmenter leurs estimés sur les PBIs. Par conséquent la vélocité sera faussée et deviendra inutile. Dans d’autres cas, l’équipe s’engagera au-delà de sa capacité et ne délivrera pas le bon niveau de qualité et n’aura plus un rythme soutenable.
  • La concurrence entre les équipes : Tenter de comparer la vélocité de plusieurs équipes Scrum ne fait pas de sens et peut casser la dynamique collaborative du projet. Cela est souvent vu sur des programmes agiles à l’échelle. Il peut éventuellement être intéressant d’avoir une idée de la vélocité consolidée de l’ensemble des équipes mais pas d’analyser les différences entre elles.

Conclusion

En résumé, la vélocité est un indicateur de prédiction. Pour l’équipe Scrum, il permet de pouvoir s’engager sur le Sprint Backlog de manière cohérente. Il permet aussi d’analyser de potentiels disfonctionnements. Au niveau Programme, cet indicateur pourra être utilisé à des fins de planification pour projeter les fonctionnalités à venir sur les prochains sprints.

Votre Daily Scrum est-il efficace ?

Il est souvent très difficile de conserver la durée du Daily Scrum à 15 minutes surtout lorsque l’équipe est constituée de nombreux membres (maximum 9). L’objectif de cet article est de souligner les problèmes fréquemment rencontrés et de proposer une approche pour les résoudre.

Avant de commencer, le Daily Scrum n’est pas un Status Meeting. Il s’agit simplement d’un point de synchro synthétique entre les membres de la Development Team. Le Scrum Master devra s’assurer que cet événement a bien lieu chaque jour à heure fixe et que l’ensemble de l’équipe y soit présent. Le Product Owner, quant à lui, pourra y assister mais sans y participer. On dit aussi qu’il peut y assister en mode « chicken ».
De tous les évènements Scrum, je pense que le Daily Scrum est le plus difficile à réaliser. Il doit être synthétique et mené de manière professionnelle pour qu’il soit vraiment efficace. Un mauvais Daily Scrum récurrent mènera à l’échec n’importe quelle équipe Scrum. Voici quelques conseils pour un Daily réussi :

Time boxing

Le meilleur moyen pour respecter la time box de 15 minutes est d’utiliser un chronomètre, un téléphone par exemple. De le poser sur une table visible de tous et de s’assurer qu’il sonne à l’issue des 15 minutes. L’équipe pourra ainsi mieux gérer son temps. Pour l’avoir testé, c’est assez efficace !

Une personne à la fois

Il est crucial que cette règle soit respectée. Si ce n’est pas le cas, cela peut vite partir en débat et déborder. Le Scrum Master veillera à ce que cela soit le cas. Des réactions peuvent arriver mais il faudra s’assurer de les contenir.

Un dialogue construit

Une équipe Scrum travaille sur des projets complexes et par conséquent, les PBI inclus dans le Sprint le sont aussi. Il arrive très souvent que certains membres de l’équipe cherchent à expliquer de manière détaillée à l’équipe l’implémentation du PBI Durant le Daily Scrum. Parfois, cela dérive en discussion ouverte et arrive sur un autre sujet.

Proposition

Formuler les prises de paroles de la façon suivante:
« Depuis le dernier Daily Scrum » : J’ai travaillé sur le PBI A, j’ai pu avancer sur …. Et j’ai pu travaillé avec ….
« Jusqu’au prochain Daily Scrum » : Je vais continuer sur le PBI A (ou travailler sur autre chose), je compte faire …. Et je vais travailler avec …
Impements :
– Pas d’Impediments
Ou
– Impediment
○ Exemple: L’équipe X n’a pas livré le composant sur lequel nous avons une dépendance. Le PBI A ne pourra pas être livré si le composant n’est pas livré à l’issue de la deuxième semaine du Sprint.
○ A la suite de l’annonce de l’impediment, un membre de la Dev Team peut se manifester pour aider à résoudre le problème en dehors du Daily Scrum.

La prise de parole formulée de cette façon permettra de synthétiser en quelques phrases les pensées du développeur. Le temps de parole par personne ne devrait pas dépasser 2 minutes.

Pas de débat !

Le Daily Scrum n’est pas un forum. Son objectif est que l’équipe de développement puisse se synchroniser efficacement et avoir une vision claire et précise des challenges à relever pour la journée. De plus, c’est un évènement qui mobilise toute l’équipe de développement. Leur temps est précieux. Protégeons le !
Le Scrum Master ainsi que l’équipe de développement veilleront à ce qu’il n’y ai pas de place au débat.
Phrase magique : « Ceci n’est pas l’objet du Daily Scrum. Pourriez vous échanger à ce sujet plus tard dans la journée ? »

Une équipe professionnelle et mature pourra s’auto discipliner et gérer son Daily Scrum en deçà des 15 minutes. Plus cet évènement est court, plus il est efficace !