Tag: 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 !

Les 7 points clés de la réussite du DevOps

Beaucoup d’articles parlent de DevOps, des clés du succès de DevOps sur leur projet, dans leur contexte. Voici ma vision des 7 ingrédients principaux qui font pour moi le succès d’une approche DevOps réussie. Cette liste n’est pas exhaustive, le sujet est vaste, d’autres ingrédients pourront être ajoutés suite à vos commentaires

1. Une culture commune

La culture sont la clé de voûte du DevOps. On parle aussi de DevOps comme un mouvement culturel, une philosophie qui vise à rapprocher les Dev des Ops. La culture du DevOps est pour moi la culture d’entreprise, du métier qui induit le professionnalisme des équipes. Une culture similaire facilite les échanges et la communication entre les personnes et ainsi créé une bonne synergie pour accomplir de grands exploits !

2. Une communication ouverte et transparente

La transparence est un des pilier de Scrum et de l’Agile. L’ensemble des membres d’une équipe DevOps doivent communiquer le plus efficacement possible et de manière transparente avec un objectif de partage de connaissance maximale. C’est crucial pour assurer une bonne dynamique du projet. Cela réduit aussi le stress de l’équipe et partage le fardeau de la responsabilité  sur l’ensemble de l’équipe DevOps en réduisant considérablement le risque de syndrome du Héro. « Tout seul on va vite. Ensemble on va plus loin ! »

3. Des outils communs

Tout comme dans la mécanique, il faut avoir de bons outils pour travailler de manière professionnelle ! Les outils améliorent considérablement l’efficacité de l’équipe et réuni par nature les métiers nécessaire à la création d’un logiciel réussi. Ces outils peuvent travailler et doivent s’intégrer en toute ergonomie à l’environnement de travail de l’ensemble des membre de l’équipe DevOps.

La plateforme Visual Studio Team Services est un excellent exemple de plateforme DevOps. Via une interface intuitive, elle centralise l’ensemble des artefacts du projet et permet le suivi du déploiement continu sur les environnements cibles du projet. De plus, cette plateforme est extensible et peut s’élargir au besoin d’autre fonctionnalités à partir d’un market place bien fourni !

4. Partager les victoires et les défaites

Historiquement, les Dev et les Ops ne partagent pas la même culture et exercent des métiers très différents. Les uns cherchent à intégrer le plus de changement et d’innovation possibles dans un produit sur la base des besoins des utilisateurs. Les autres recherchent la stabilité, la sécurité et la performance de l’application en production. Il existe parfois des tensions ou des incompréhensions entre ces deux population qui sont la plupart du temps dues au manque de vision globale du projet. Le DevOps a pour but d’adresser ce problème en fournissant une vision plus large à l’ensemble des membre du projet. Tout comme en agile, les succès sont partagés et toute l’équipe doit être récompensée ou remerciée (c’est un minimum !). Il en est de même pour les défaites. Ensemble, l’équipe DevOps est bien meilleure dans la défaite et pourra en tirer les enseignements pour les futures version du produit !

5. Un budget partagé

C’est sans doute la point le plus difficile à adresser dans les grands groupes où les process des finances sont bien enracinées dans la culture traditionnelle. Il faudra donc s’adapter pour que l’équipe DevOps soit vue comme une équipe à part entière et non comme deux équipes distinctes. En DevOps, par définition, il n’y a pas de phase Projet et de phase de Run à proprement parler. On délivre une première version le plus rapidement en production (Minimum Viable Product) et on la fait évoluer le plus souvent possible avec une équipe polyvalente et compétente. Si possible la taille de l’équipe DevOps doit rester identique sur toute la durée du projet (Consistancy Removes Complexity). D’un point de vue budget, cela correspond un peu à un mode d’abonnement au mois où l’on va garder la même charge. En théorie, c’est plus simple à calculer. C’est un peu comme si l’on payait un forfait mobile avec un iPhone. Cela revient au même coût au final, mais on a pas besoin d’avancer le coût du téléphone à chaque nouvelle mise à jour.

Dans la pratique, c’est un peu plus compliquer à aborder, il faut donc s’adapter aux systèmes de facturation existants… (Inspect and Adapt !)

6. Une méthode commune et appliquée

Dans le cadre d’un projet DevOps, l’application d’un framework Agile doit être très rigoureuse et partagée par l’ensemble de l’équipe. En DevOps, tout le monde parle la même langue, utilise les mêmes outils et communique efficacement. Il est toujours plus facile de jouer à un jeu lorsque les règles sont clairement définies. Un Scrum Master veilleura à l’application de ces règles et à la suppression de tout obstacle (Impediment) empéchant l’évolution de l’équipe DevOps.

Je conseille vivement la mise en place d’un Framework Agile à la fois strict et simple à comprendre tel que Scrum pour que l’ensemble de l’équipe puisse connaitre et maitriser ces règles rapidement dès le début du projet.

7. Des objectifs communs

Cela va sans doute de soi mais lorsque l’on est sur l’autoroute du DevOps, tout le monde doit rouler dans le même sens ! Notre destination doit être commune et notre équipe doit évoluer de concert en visant un objectif commun à court terme et en partageant une vision commune du produit !

J’espère que ces quelques points vous ont permis de mieux comprendre les enjeux et la philosophie du DevOps. Je suis preneur de vos retours d’expérience.