Month: juillet 2017

Comment prioriser son Product Backlog à l’aide du WSJF ?

WSJF ? Qu’est ce que c’est ? Encore un acronyme de plus dans notre vocabulaire. J’ai découvert cette technique dans le Framework SAFe. WSJF veut tout simplement dire « Weighted Shortest Job First » ou en français « la plus importante ou la plus courte fonctionnalité d’abord ! ». Organiser ou prioriser le Product Backlog est souvent un casse tête pour le Product Owner. Sur des projets complexes avec beaucoup de fonctionnalités, il est parfois très chronophage de faire l’exercice de raffiner son Product Backlog de manière efficace. Cet outil pourra nous y aide. Je vois plutôt le WSJF comme un outil plutôt qu’un indicateur. Il permet de déterminer un chiffre représentant le bon compromis entre la valeur qu’apportera la fonctionnalité si on la livre et le temps que l’on prendra à la développer.

D’où vient le WSJF ?

SAFe part du principe que toute fonctionnalité non livrée à temps à un coût : The Cost of Delay. Dans la philosophie de Lean, l’objectif est donc de réduire ce coût au minimum pour augmenter notre efficacité et livrer le maximum de valeur à l’issue d’un Sprint. Prenons quelques exemples simples. Imaginons que nous avons deux fonctionnalité à développer. Elle ont la même valeur métier mais l’une d’entre elle est plus courte à développer. Le product Owner priorisera sans aucun doute la plus courte. Par contre, si l’une des fonctionnalité prends moins de temps à développer mais est aussi moins prioritaire, il est difficile de la prioriser dans le Product Backlog. Le Product Owner devra trouver le bon compromis. L’idée du WSJF est de lui fournir un outil factuel permettant de l’aider dans cette tâche!

Comment se calcul-t-il ?

Le calcul du WSJF prends en compte les critères suivants. On utilisera pour tous ces indicateurs une notation suivant une suite de Fibonacci par ordre croissant:
– User-Business Value : la valeur métier de la fonctionnalité.
– Time Criticality : détermine si la fonctionnalité doit être livré rapidement ou non.
– Risk Reduction or Opportunity Enablement: Détermine si cette fonctionalité réduit le risque ou facilite le développement d’autres fonctionalités par la suite
– Job Size : Taille de la fonctionnalité à développer. On parle aussi d’effort. Cette valeur peut être estimée par l’équipe de développement.

Calcul du « Cost of Delay »

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Oppty Enablement
WSJF = Cost of Delay / Job Size

Plus le WSJF a une valeur importante, plus la fonctionnalité pourra être priorisée. On voit ici que dans cette formule, nous prenons en compte à la fois la valeur métier mais aussi la contrainte de temps et la réduction du risque. Le facteur ayant le plus de poids sur la formule est donc la taille ou l’effort.
Cela met en évidence plusieurs chose. D’une part plus les Features sont petites, plus elles sont faciles à estimer et à ordonnancer les unes par rapport aux autres. On parle en général de MMF (Minimum Marketable Feature). D’autre part, ce n’est pas parce qu’une fonctionnalité semble importante qu’elle doit être priorisée. Il faudra prendre en compte l’impact si celle-ci n’est pas développée à court terme. Dernier point, ce calcul n’est pas figé dans le temps. L’ensemble des facteurs pourra être revu au fil des sessions de Product Backlog Refinement.

En conclusion, le WSJF est un outil relativement puissant permettant une bonne priorisation du Product Backlog en entrée de chaque Sprint. Il fera aussi gagner beaucoup de temps à la Scrum Team dans les sessions de Product Backlog Refinement où l’équipe pourra se focaliser sur les fonctionnalités les plus cruciales.

Pour aller plus loin:

http://www.scaledagileframework.com/wsjf/

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 !