I've just finished the two days long training session to be a Scrum Master. These two days were lead by Jeff Sutherland (in collaboration with Xebia France) . Of course, don't imagine that you will be great a Scrum Master at the end of the session. As Jeff said, were you a good driver just after obtaining youri driving license?In this post, I will try to summarize notes I took during the course. It's not exhaustive but it wil give you a global idea of what is Scrum and what should do a Scrum Master.
But, before starting, let's return to the title of this post : "I realized I was a ScrumButt Master". Humm... what's that? Jeff said something very interesting . He asked people about who had already tried Scrum. Many ones in the assistance raised their hand. So, why were they here? ... Ok, let's do another test : can you give me the average velocity of your team? Only two answers iin allt the room. And that's why I was here. As many people, I tried Scrum but not entirely. This is commonly called "ScrumButt" (don't ask me about the two "t", I don't know). And that's why I failed my first Scrum project. Without using all concepts, it smells Scrum, it has got the color of Scrum but it's not Scrum. You see?
Sorry for non-french people, I will continue this article in my mother tongue (which is definitely not Java!).
Après nous avoir demandé de présenter notre voisin, Jeff a fait un rapide sondage histoire de savoir qui travaillait déjà en Scrum (ou, en tout cas, qui avait l'impression d'en faire comme je l'ai dit plus haut...). Il a ensuite reventilé les tables pour avoir des groupes homogènes. C'est un des principes de Scrum : l'équipe ne doit pas comporter de personne qui se démarque. Jeff entend gagner en productivité avec une équipe moyenne.
Scrum, c'est quoi?
Première étape de la formation : présentation du « framework » Scrum. Signalons le tout de suite : pour Jeff, Scrum n'est pas une méthode mais plutôt un cadre de travail pour gagner en performance. Bizarre tout de même, j'ai beau faire le tour de la question, ça ressemble pas mal à de la méthode tout ça. Enfin, on ne va pas chipoter sur les mots. Bref, voici un condensé de ce fameux « framework » :
Les acteurs :
Le Product Owner. En bon français, c'est le chef produit. Enfin... c'est celui qui veut faire faire quelque chose et qui sait ce que ce quelque chose doit faire.
Le Scrum Master. Il anime l'équipe. Il est là pour s'assurer que tous les membres travaillent vers le même objectif. Ce n'est donc pas un « chef » d'équipe dans le sens hiérarchique mais un animateur. Cela peut vous choquer mais c'est dingue le nombre de CdP que j'ai croisés dans ma vie professionnelle qui se prenaient pour des petits chefs... Pourtant, même armé de son diagramme de Gantt, le chef de projet n'est-il pas avant tout au service de son équipe? Et Scrum est assez clair sur le sujet car l'équipe est autogérée.
Le reste de l'équipe projet. Je dit bien « le reste » parce que le Scrum Master en fait partie. Typiquement dans le cadre d'un projet de développement, il développe 50% de son temps. Il est donc pleinement impliqué et ne se contente pas de poser des jalons et de vérifier qu'ils sont respectés! D'autre part, l'équipe (Scrum Master inclut donc) a un rendement optimal si elle est composée de 5 à 7 membres. Au delà, cette productivité s'effondre. Et le mythe du mois-homme dans tout ça? Où il est le bébé fait en un mois par neuf femmes???
Accessoirement, Jeff a insisté sur la nécessité d'avoir un recours à un DBA dans les projets de développement. Il a aussi rappelé qu'un bon architecte est un architecte qui code! Et oui, il doit montrer à l'équipe que ce qu'il a conçu tient la route.
Comment est découpé le projet dans le temps :
Le Sprint. Tout Scrum tourne autour de ça. Un sprint est une unité de découpage temporel du projet avant lequel tout le monde se met d'accord sur ce qui va être fait, pendant lequel l'équi et à la fin duquel l'équipe remet au Product Owner un livrable. Un projet Scrum est composé d'une succession de Sprints. Là, vous devez commencer à sentir la différence avec du projet ordinaire ; Scrum impose de livrer tout au long du projet et non pas à la fin. Dans la pratique, on fait souvent des Sprints de deux semaines. Mais tout est possible. Pendant la formation, Jeff nous a fait faire des Sprints de 3 minutes!
Le Planning Meeting. Cette réunion se fait avec toute l'équipe projet + le Product Owner. L'objectif est de savoir ce que l'équipe va devoir réaliser pour le Sprint à venir.
La Démo : A chaque fin de Sprint, l'équipe doit montrer au Product Owner ce qu'elle a réalisé. Seules les tâches totalement terminées font partie de la démo. La notion de « terminé » est vraiment importante. Par principe, on ne retravaille pas sur ce qui a été livré dans un Sprint précédent donc, autant bien soigner son code dès le début. Rework is Baaaaad. M...kay....
La Retrospective. Petit test : cela fait combien de temps que vous n'avez pas fait de débriefing après un projet? Humm... vous aussi... Et bien en Scrum, on le fait tout le temps! Bref, après la démo, l'équipe fait un point sur ce qui s'est bien ou mal passé histoire de pouvoir s'améliorer au prochain Sprint.
Le Daily Meeting ou « Stand-up meeting » ou « appelez le comme vous voulez du moment que cela ne dépasse pas 15 minutes ». Ce point équipe quotidien permet à chaque membre de décrire ce qu'il a fait la veille et ce qu'il compte faire aujourd'hui. Généralement, ces micros réunions se font debout (ça évite que les participants « s'installent » dans la réunion).
Les outils du Scrummer :
Un paquet de Post-It (on ne rigole pas) pour rédiger les « User Stories ». Les User Stories sont les fonctionnalités attendues. Habituellement, chaque « User Story » est donc notée sur un Post-It collé au mur. Jeff a insisté : pas d'Excel! Chaque fiche comprend : L'objectif recherché (le « ça doit faire quoi »)
Le « How to demo ». Comment tester que cela fonctionne. OBLIGATOIRE! Une fonctionnalité non testable est une fonctionnalité non livrable!
Un chiffre pour indiquer sa priorité par rapport aux autres fonctionnalités. C'est la « Business Value ». Pensez toujours à ce qui va rapporter le plus de valeur à votre business!
Un nombre de points indiquant sa charge de réalisation (Courez tout de suite lire la section sur le planning poker pour découvrir illico comment on la calcule, vous ne serez pas déçu). Ces points s'appellent des Sprint Points. Au fait, vous avez vu? On ne compte pas en temps comme d'habitude mais de Sprint Points. On verra plus tard comment estimer en temps la valeur d'un Sprint Point.
Afin de toujours s'assurer qu'une User Story est pertinente, Jeff nous a donné l'acronyme INVEST. Ainsi, une User Story doit être :
Independant
Negotiate
Valuable
Estimable
Small
Testable
Un bout de mur pour coller les Post-Its. L'espace de collage est découpé en zones bien distinctes pour y accueillir :Le Product Backlog : il comprend l'ensemble des User Stories du projet. Il est créé par le Product Owner qui les priorise en fonction de leur « Business Value ». L'idée sera bien sûr de réaliser en premier les fiches apportant le plus de valeur métier tout en tenant compte bien sûr de leur complexité de réalisation.
Le Sprint Backlog. En bon français, c'est quoi qu'est ce qu'on va livrer à la fin du Sprint :) Lors de la réunion de planificaction du Sprint, on pioche dans les Post-Its du Product Backlog.
Un tableau ou un paperboard pour y tracer le BurnDown Chart. C'est un outil très puissant et très simple à réaliser. Il permet de suivre le « reste à faire » du projet et de voir si l'équipe se porte bien. Prenez votre Product Backlog et faites le total des Sprint Points des User Stories. Reportez le sur votre graphique en ordonnées. En abscisse, mettez les Sprints. A chaque fin de Sprint, recalculez de nombre de points restants à faire et reportez le sur le graphique. Et ainsi de suite... Vous avez votre BurnDown Chart. Comment l''interprêter? Si votre courbe est linéaire, c'est que l'équipe travaille de façon homogène. Vous pouvez en plus avoir une idée précise de la date de fin de projet. Si la courbe fléchit, oh la la alerte rouge... il passer en Emergency Sprint Procedure
Les indicateurs du projet :
La vélocité de l'équipe. C'est sa capacité à produire. En outre, c'est le nombre de Spring Points qu'elle est capable de réaliser en un Sprint. Donc, plus vous connaissez votre équipe, plus vous savez combien de points elle peut réaliser en comparaison avec les Sprints précédents. On appelle ça le « yesterday's weather ». Par conséquent, évitez de faire rentrer/sortir des ressources en cours de projet; ça casse toute l'estimation de vélocité. Je vous ai préparé une petite section sur « Comment calculer la vélocité de son équipe » plus loin.
Le BurnDown Chart. Je ne reviens pas dessus. Ce graph synthétise pas mal de choses : le reste à faire, le durée du projet, l'état de santé de l'équipe, etc...
Le « Rework ». Sur l'un des BurnDown Charts que Jeff nous a présenté, il a fait apparaître le coût du code non conforme qui doit être repris. Cela permet de conserver un oeil sur la qualité des Sprints précédents. En principe, le « rework » doit rester faible car l'une des règles d'or de Scrum est de ne pas négocier sur la qualité. Négligence de la qualité = rework. Rework = surcoût.
Le stress de l'équipe. Et oui, il faut y penser. Jeff nous a conseillé de ne pas charger à plus de 70% de leur capacité les membres de l'équipe et à veiller à ce qu'ils ne fassent pas trop d'heures. En effet, stress ou fatique = rework. Rework = surcoût, etc..., etc...
Enfin, j'en ai fini pour la présentation générale du « framework » Scrum. Place au jeu à préssent.
Le planning Poker
C'est l'un des temps forts pour moi de cette formation. L'objectif est d'estimer la réalisation de chaque User Story. Seule l'équipe joue; pas le Product Owner. Première étape, distribution des cartes. Chaque joueur a en main une série de carte dont les chiffres sont une adaptation libre de la suite de Fibonacci. On place une User Story au milieu de la table. Chacun met une carte indiquant son estimation de charge. On retourne toutes les cartes et on compare les résultats. Si il y a moins de 3 points d'écart entre les cartes, la charge de la User Story sera la moyenne de toutes les cartes. Si il y a plus de 3 points d'écart, c'est que l'objectif de la User Story n'est pas compris par toute l'équipe. Dans ce cas, on en discute puis on revote. Et ainsi de suite.... Cela peut paraître étrange mais c'est terriblement efficace.
A la fin de notre exercice, toute la table était d'accord sur le chiffrage et sur ce qu'elle allait faire. Le planning Poker est un bel exemple de travail d'équipe. J'ai beaucoup apprécié.
Calculer la valeur d'un Sprint Point en jours,
heures, minutes, secondes...
Ah, c'est bien beau de faire du poker et de distribuer des Sprint Points mais il y a bien un moment où il va falloir convertir tout ça en temps; notamment pour savoir combien de Sprint Points vous allez pouvoir espérer réaliser pendant un Sprint. Voilà ce que nous a appris Jeff sur le sujet :
Prenez votre plus petite User Story (celle qui est estimée à 1) et découpez la en tâches toutes petites. Toute l'équipe estime alors en temps la charge pour réaliser toutes ces « pitites » tâches. Faites la somme de tout ça et Bingo! Vous avez la valeur d'un Sprint Point.
Je ne vous cache pas que je suis un peu sceptique sur la méthode de calcul. Prendre le plus petit pour l'extrapoler au plus grand... Bon, de toute façon, comme je ne sais pas comment faire autrement, je vais m'en tenir à cela pour le moment.
Calculer la vélocité de l'équipe
Pour rappel, la vélocité de l'équipe est le nombre de Sprint Points qu'elle peut réaliser dans un Sprint. Ca peut paraître bête à rappeler mais la vélocité peut changer d'un Sprint à l'autre. Pourquoi? Tout simplement en fonction des congés ou indisponibilité des uns et des autres.
Bon, commençons simplement. Dès lors qu'on connait la durée d'un Sprint, la taille de l'équipe et la valeur en temps d'un Sprint Point, le calcul le plus simple est le suivant :
Vélocité brute de fonderie = nombre de jours-homme sur le Sprint / valeur en temps d'un Sprint Point
Jusque là, tout va bien. Maintenant, Jeff nous a précisé que le Scrum Master ne doit pas être considéré comme développant à plus de 50%. Donc, pour une équipe de 5 personnes, seuls 4,5 sont prix en compte.
Nombre de JH corrigé = durée du Sprint x (nombre de personnes dans l'équipe - 0.5)
Ensuite, il a rajouté deux choses : soit le ScrumMaster connait l'équipe est dans ce cas, il en connait déjà sa vélocité (le « yesterday's weather » comme on dit dans l'métier...), soit l'équipe est nouvelle et, dans ce cas, on applique des ratios de facto.
Cas 1 : l'équipe est nouvelle
Jeff nous propose d'appliquer deux ratios simples. Pour le premier Sprint, on plafonne la vélocité à 60% de sa valeur théorique. Pour le second, on passe à 70% et dès le troisième, on est à 100%.
Vélocité théorique = nombre de JH corrigé / valeur en temps d'un Sprint Point
Vélocité Sprint 1 = velocité théorique - 40%
Vélocité Sprint 2 = vélocité théorique - 30%
Vélocité dès le Sprint 3 = vélocité théorique
Exemple : une équipe de 5 personnes sur des sprints de 2 semaines. La valeur d'1 point est de 1,5 jours. Je pense ne charger le ScrumMaster qu'à 50%.
Vélocité théorique = 4,5 x 5 x 2 / 1,5 = 30
Vélocité Sprint 1 = 30 - 40% = 18
Vélocité Sprint 2 = 30 - 30% = 21
Vélocité dès le Sprint 3 = vélocité théorique = 30
Cas 2 : l'équipe a de la bouteille (yesterday's weather)
Dans le cas d'une équipe dont la vélocité est connue, il suffit d'appliquer une règle de 3 pour calculer la vélocité du Sprint à venir en fonction du nombre de jours-homme travaillés. Et voilà que j'introduit un nouveau terme : le Focus Factor.
Focus Factor = vélocité précédente / nombre de JH réalisés
Vélocité prochain Sprint = nombre de JH prochain Sprint x Focus Factor
Exemple : Reprenons l'équipe de 5 personnes précédente. Le nombre de points réalisés dans le Sprint précédent où les semaines étaient complètes est de 30. Imaginons maintenant que, dans le Sprint à venir, il y a un jour férié. Le nombre de jours-homme à venir sera de 4,5 x 5 + 4,5 x 4 = 40,5. Si pour 45 jours-homme, la vélocité était de 30, alors pour 40,5, elle sera de 40,5 x 30 / 45 = 27.
Enfin, tout ça n'est jamais qu'une règle de 3.... Scrum reste avant tout du bon sens avec un peu de bling-bling dessus.
Que faire quand le projet dérape ?
C'est une question qui est revenue souvent pendant les deux jours de formation. A cette question, Jeff propose de faire les choses suivantes (dans l'ordre) :
Trouver ce qui ne va pas. Pour cela, Jeff nous a fait travailler sur le « Toyota A3 Process ». Dans la pratique, l'exercice qu'il nous a demandé consiste à mettre à plat un problème sur une feuille A3 organisée en zones bien distinctes. Chaque zone permet d'aller peu plus loin dans la résolution du problème. Une autre technique est celle du « 5 whys ». En gros, une personne expose ce qui ne va pas et on lui demande « pourquoi » jusqu'à temps qu'elle remonte à la source du problème. Quoi qu'il en soit, je crois que Jeff a bien été clair : en Scrum , pour être efficace, il faut éliminer tous les obstacles (quitte à aller au conflit!). « Remove impediments, remove impediments, remove impediments! »
Trouver quelqu'un pour tester.
Retirer la User Story du Sprint
Si aucune solution ci dessus n'est satisfaisante, annuler le Sprint!
Parmi les questions posées par Jeff, il y a eu la suivante : que faire si le Product Owner ne vient jamais au réunions? Réponse : trouver un autre Product Owner. Sachez aussi qu'il peut se faire représenter par un tiers (appelé « proxy »).
Autre question concernant le Product Owner : que faire si plusieurs Product Owners travaillent sur le projet? (C'est en effet parfois nécessaire lorqu'un Product Owner seul n'est pas suffisant pour fournir assez de matière à l'équipe de développement). Dans ce cas, il faut impérativement un Chief Product Owner neutre pour éviter les conflits d'intérêt.
Que faire si l'équipe fait plus de 10% de support? Avouez que ça vous en bouche un coin ça. Contrairement au Waterfall, Scrum intègre directement les élements perturbateurs de la vraie vie tels que le support. Et Jeff a été assez clair sur le sujet. Il dit : dans la pratique, il faut considérer que l'équipe ne travaille réellement qu'à 50% sur le projet. Dans ces 50%, il y a 30% de « new », 10% de « old » (maintenance) et 10% de support. Si les 10% de maintenance ou de support sont dépassés, le Sprint doit être annulé, les problèmes consignés dans une liste des points bloquants (« impediments list ») et le Sprint doit être replanifié.
Que faire si, dans l'équipe, un membre travaille énormément, refuse de venir aux réunions sous prétexte qu'il fait déjà les ¾ du projet à lui tout seul? Réponse : le sortir de l'équipe. Scrum s'appuie sur la notion d'équipe. Si quelqu'un ne joue pas le jeu, il pénalise l'équipe et réduit sa vélocité. Même s'il est très bon!
Aidez votre Product Owner, il vous le rendra!
Le Product Owner est indispensable; alors, autant en prendre soin.
L'équipe de développement peut l'aider à préparer le Sprint suivant à hauteur de 10% de son temps. Pour que les Sprint s'enchainent, il faut bien de toute façon que le Product Backlog soit à jour. Ainsi, à la moitié du Sprint, commencez à aider votre Product Owner à préparer le Product Backlog pour le Sprint suivant.
Pour sa part, le Product Owner doit vous assister en particulier sur la première moitié du Sprint pour comprendre dans le détail les User Stories.
N'oubliez pas qu'une User Story « gros grain » peut être découpée en plus petites User Stories du moment qu'elle n'est pas dans le Sprint Backlog en cours. Cela peut notamment permettre de boucher les trous lorsqu'il reste de la place dans le Sprint Backlog en réunion de planification.
Pour rappel : le Product Owner n'a pas le droit de modifier les User Stories du Sprint Backlog! Paroles de Jeff. En revanche, il peut changer une User Story non réalisée du Product Backlog par une autre de poids équivalent (nombre de Spring Points). C'est le concept « change for free » de Scrum.
Mise en pratique : le XP Game
Ces deux jours de formation se sont terminés par un XP Game; histoire de mettre en pratique un peu de ce qu'on avait vu jusque là. Le jeu était assez amusant. Pour commencer, il a fallu estimer tout un tas de tâches à réaliser (gonfler des ballons, faire des chapeaux en papier, des châteaux de cartes, etc...). Ensuite, nous avons fait nos réunions de planification pour déterminer ce qu'on allait mettre dans chaque Sprint à venir de façon à obtenir une « Business Value » maximale. en un temps restreint Puis, place au Sprint, suivi des demos et retrospective. Le tout avec un zeste de concurrence car Jeff comptabilise les Business Points obtenus pour chaque équipe. Autant dire qu'on s'est bien lâchés. A la fin, il y avait des ballons partout au sol et surtout la preuve par l'exemple que toute la théorie Scrum fonctionne. Et oui, on a tenu la vélocité calculée et nos estimations étaient juste. Par dessus tout, j'ai vraiment eu le sentiment de travailler en équipe dans un objectif commun. C'est probablement un point fort de Scrum : ramener l'esprit d'équipe en entreprise.
Pour conclure
Une très bonne formation même si j'ai senti qu'elle avait du mal à décoller la première demie journée. Au final, je crois que tout le monde aurait bien voulu repartir avec Jeff dans sa valise. Pour preuve, les deux jours se sont terminés par une séance photo avec la star de Scrum. Alors que conclure si ce n'est vous conseiller de suivre cette formation...
Thanks a lot Jeff.
Pour aller plus loin :