Catégorie : Scrum

Bien choisir la durée de ses sprints

C’est un sujet qui revient très souvent lorsque l’on pratique Scrum. Quelle est la bonne durée pour un Sprint ? Deux semaines, une semaine, un mois ?

Le Scrum Guide n’est pas prescriptif sur la durée du Sprint, elle doit être d’un mois maximum et doit permettre à l’équipe Scrum de délivrer un incrément Done ✅ à l’issue du Sprint.

Définition of Done

La Définition of Done est propre à chaque équipe. Elle signifie la plupart du temps que l’incrément délivré à l’issue du Sprint est de bonne qualité et qu’il peut être déployé en production avec l’ensemble des contraintes d’intégration que cela implique.

Lorsque l’on choisi la durée du Sprint, il faut s’assurer que notre organisation nous permet d’être Done à l’issue du Sprint.

La questions à se poser serait la suivante:

– En tant que Dev team, sommes nous capables de développer, livrer, intégrer et tester notre incrément avec un bon niveau de confiance par rapport à la durée du Sprint ?

Sustainable pace

C’est un point souvent oublié dans Scrum. Sans doute à cause du terme Sprint. La construction d’un produit en agile relève en effet plus du Marathon ou de l’Iron man que du 100m. Le rythme que l’on s’impose est clé pour l’aboutissement du produit. Si l’ on commence le marathon à courir comme un 100m, nous finirons en marchant sans doute beaucoup plus tard que si nous avions pu garder la bonne vitesse.

Question à se poser à l’issue de chaque Sprint :

– Sommes nous capable de conserver ce rythme en considérant notre environnement de travail ?

Les dépendances

La gestion des dépendances est clé dans tout projet. Plus on a de dépendances à gèrer, plus cela nécessite un effort de synchronisation et d’intégration. Les problèmes liés aux dépendances sont plus difficiles à gérer et à anticiper par la Scrum Team.

Par rapport à la durée du Sprint, les questions à se poser seraient :

– Quelle est le nombre de dépendance sur notre produit ?

– Quelle est leur complexité ?

– Sommes nous en mesure de livrer un incrément conforme à notre DoD en prenant en compte ces dépendances ?

Le Product management

Concevoir un produit nécessite du temps. Cet exercice réalisé en partie par le Product Owner doit être fait de manière continu tout le long de la vie du produit. Le rythme des Sprint peut influer sur la capacité à générer un product Backlog de qualité pouvant être actionné par l’équipe de développement.

Questions à se poser :

– Sommes nous en mesure de prioriser correctement l’équivalent de deux Sprint d’avance ?

– La durée du Sprint nous permet elle de rencontrer nos stakeholders ? De recueillir assez de feed-back pour évoluer dans la bonne direction?

– La durée du Sprint permet elle de remonter les Actionable Metrics nécessaires à la prise de décision ?

– Est ce que la majorité des stakeholders peut se rendre disponible lors du Sprint Review ?

Conclusion

La durée de Sprint peut avoir un impact important sur le Produit livré. Elle ne peut être changée uniquement par la Scrum Team après l’analyse du contexte dans laquelle elle évolue. Bien que ce changement de rythme ne soit pas fréquent, il est parfois nécessaire pour augmenter l’efficacité globale de l’équipe.

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 (le maximum est de 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 activement. On dit aussi qu’il peut y assister en mode « chicken » 🐓.
De tous les évènements Scrum, le Daily Scrum est l’un des plus difficiles à 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 fois l’équipe habituée, les 15 minutes tiendront sans chrono.

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. Si une discussion, un choix technique doit être pris, un session de travail pourra être prévue à la suite du Daily sans impacter l’ensemble de l’équipe.

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.

L’objectif du Sprint est d’atteindre le Sprint Goal. Il est important que l’ensemble de l’équipe l’ai en tête afin qu’elle puisse évoluer dans la bonne direction.

Voici un exemple de prise de parole synthétique durant le Daily :
« Dans le but d’atteindre le Sprint Goal (rappeler éventuellement celui ci), depuis le dernier Daily Scrum » : J’ai travaillé sur le PBI A, j’ai pu avancer sur …. avec ….
« Jusqu’au prochain Daily Scrum » : Je vais continuer sur le PBI A (ou travailler sur autre chose), je compte faire …. Et j’ai besoin de 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 !