Bienvenue dans notre équipe Scrum !
Tu es développeur et tu vas démarrer une mission dans une équipe Scrum ? Petit guide pour comprendre comment l’agilité et Scrum vont faciliter ton travail.
Le sprint
Tu en découvriras plus au fur-et-à-mesure.
Pour démarrer, l’essentiel est de savoir que Scrum fonctionne par sprints de 1 à 4 semaines, pendant lesquels l’équipe essaie d’atteindre un objectif de sprint.
NB : Atteindre l’objectif de sprint est beaucoup plus important que terminer toutes les tâches qu’on avait envisagé de réaliser.
Ton rôle dans la mêlée Scrum
Les tâches à réaliser son notées sur des post-its, posés sur un tableau : le scrumboard.
Pour démarrer la mêlée, on rappelle l’objectif de sprint.
Devant le scrumboard, chacun à son tour:
- regarde dans la colonne “done”, et dit ce qu’il a terminé hier pour l’équipe
- regarde dans la colonne “doing” :
- et déplace ce qu’il a terminé hier dans la colonne “done”
- ou déplace ce qui est bloqué dans une colonne “blocked”, en expliquant ce qui bloque la réalisation de l’action - regarde dans la colonne “todo” et négocie avec le reste de l’équipe l’action’la plus urgente/importante qu’il va commencer
- exprime les domaines et/ou tâches où il aura besoin d’aide d’autres équipiers pour réaliser le travail.
NB : la mêlée quotidienne n’est pas un rapport de tâches. On n’y parle que de ce qu’on a réalisé pour l’équipe, pas d’autres actions individuelles pour lesquelles on n’a pas besoin de se coordonner avec les autres équipiers (rdv avec son manager, etc.).
Le daily Scrum est un bilan rapide en équipe, qui ne doit pas prendre plus de 15mn.
Si un sujet nécessite plus d’une minute de temps de parole, on convient d’en discuter juste après la mêlée. Ça permet de conserver la rapidité et l’énergie du daily Scrum, et comme ça on peut quand même essayer de débloquer au plus vite les actions qui sont bloquées.
La mêlée se termine généralement par une petite phrase énergisante pour les équipiers. Ça peut être un simple “bonne journée à tous”.
Qu’est-ce que ça apporte ?
La dynamique de la mêlée suit ces 3 phases :
- Transparence
- Inspection
- Adaptation
La transparence consiste à partager les informations dont les autres ont besoin (juste le détail d’information dont ils ont besoin pour décider et agir).
L’inspection consiste à vérifier si on avance vers l’objectif de sprint. Pour cela on ne doit considérer que les choses complètement terminées, prêtes à aller en production.
L’adaptation consiste à faire un plan d’action pour la journée, à partir des informations que l’on a.
On ne va pas forcément s’y prendre comme on l’avait prévu au départ, car des éléments imprévus nous amènent à changer ce que l’on avait prévu de faire ou la façon de le faire.
Ton premier planning poker
Pendant le sprint planning, le Product Owner va négocier avec l’équipe ce qui sera réalisé dans le prochain sprint. Il commence par présenter l’objectif de sprint.
Puis :
- le product owner présente 1 “User Story” : il explique l’objectif fonctionnel à atteindre pour satisfaire l’utilisateur
- en retour, les développeurs analysent rapidement comment il est possible de satisfaire ce besoin utilisateur d’un point de vue technique
- si cette User Story est trop importante, on peut décider de la découper. L’idée est de pouvoir réaliser au mois une demi-douzaine de User Stories (plus il y a de User Stories, plus ont divise le risque d’échouer à atteindre l’objectif de sprint).
Dans l’idéal, une User Story ne devrait pas prendre plus de 1 à 2 jours de réalisation. - un premier tour de table a lieu. Tu gardes les cartes dans tes mains, comme au poker (pour ne pas influencer les autres).
Tu sélectionne ton estimation, sans la montrer.
Si tu estimes que cette User Story demanderait au moins autant d’effort qu’une autre User Story de 1 point, alors tu gardes en main la carte “1”. Si tu veux voter pour 2 points d’effort, tu sélectionnes la carte 2, etc. - au signal, tous les développeurs montrent la carte qu’ils ont sélectionné
- si les votes divergent, chacun explique les raisons de son vote.
Par exemple, la complexité technique sera plus grande pour un débutant que pour un expert.
Certains équipiers peuvent mettre en évidence des risques qui impactent l’effort nécessaire. Etc. - si besoin, un second tour de table est lancé.
Chacun a maintenant plus d’informations pour voter. Un second vote est lancé, de la même façon qu’au premier tour.
Si cette fois-ci les estimations convergent, la User Story peut être sélectionnée pour le sprint. Sinon, elle a probablement besoin d’être clarifiée d’un point de vue fonctionnel ou d’être découpée d’un point de vue technique, avant d’être prête à rentrer dans un sprint.
Le planning poker continue ainsi, jusqu’à ce que l’équipe ait atteint la capacité à faire calculée pour le sprint (sa “vélocité”). Le rôle du Scrum Master est de calculer cette vélocité, et d’éviter que l’équipe s’engage de façon irréaliste. Pour cela, il s’appuie sur les livraisons des sprints précédents.
A la fin du Sprint Planning, le Product Owner et l’équipe réalisent un vote de confiance. C’est l’équipe toute entière qui s’engage pour réaliser l’objectif de sprint.
Si tu a la curiosité de lire le Guide Scrum, tu verras qu’il fait une description un peu différente du déroulement du Sprint Planning.
C’est parce que le Guide Scrum a évolué à chaque édition, alors que certaines habitudes restent ancrée dans les équipes; tant que ça fonctionne, ça ne pose pas de problème.
Qu’est-ce que ça apporte ?
Les estimations peuvent être réalisées dans n’importe quelle unité : “jour idéal”, points, tailles de tshirt (S, M, L, XL…).
Le Guide Scrum ne précise volontairement pas comment réaliser les estimations. L’essentiel est de s’éloigner du traditionnel jour/homme. Dans Scrum, personne ne travaille seul. C’est l’équipe tout entière qui réalise et qui livre le produit.
Tirer le meilleur de la rétrospective
Le Sprint est terminé.
Une Revue de Sprint a eu lieu, pendant laquelle l’équipe a pu :
- montrer l’état du produit (uniquement ce qui est terminé) aux parties prenantes
- vérifier si l’objectif de sprint est atteint ou pas
- le Product Owner a mis à jour le backlog du produit et la roadmap.
Tu vois qu’on retrouve ici aussi les fameux 3 piliers de Scrum : transparence, inspection et adaptation.
Maintenant qu’on a fait le point sur le produit, il est temps de regarder comment l’équipe fonctionne, pour voir ce qu’on pourrait améliorer.
C’est l’objectif de la rétrospective : faire le point sur les processus de travail et les interactions (interactions entre équipiers, interactions de l’équipe avec le reste de l’entreprise, les clients).
Le Scrum Master a préparé un format de rétrospective. Suivant la culture de l’équipe, ce format peut être simple ou très ludique.
Dans l’idéal, une rétrospective comporte 5 phases. Mais le Scrum Master adapte souvent le format en fonction du stade de maturité agile de l’équipe.
Dans l’équipe, et spécialement pendant la rétrospective, il doit régner un climat de sécurité psychologique. Si tu ne te sens pas en confiance, tu as évidemment le droit de ne pas parler de ce qui te dérange. C’est au management d’instaurer le climat de confiance nécessaire.
Le Scrum Master joue un rôle de facilitateur : il ne participe pas aux débats, il se contente de fournir un cadre d’atelier qui permet à l’équipe de passer par les étapes nécessaires pour remettre en cause son fonctionnement et l’améliorer.
Encore une fois, tu retrouves ici aussi les fameux 3 piliers de Scrum : transparence, inspection et adaptation.
Pendant la rétrospective, on vérifie aussi si les hypothèses formulées à la rétrospective précédente ont produit les résultats escomptés.
A l’issue de la rétrospective, on ajoute au backlog du prochain sprint l’action d’amélioration qui a été décidée par l’équipe.
Qu’est- ce que ça apporte ?
Sans un processus d’amélioration continue, difficile d’avancer : on risque de rencontrer encore et toujours les mêmes obstacles qui bloquent le travail et/ou les livraisons.
Les bilans réguliers du cycle Scrum permettent d’identifier ces obstacles et les résoudre à la source.
Mais résoudre des problèmes aussi importants ne pas se faire (que) de façon intuitive : il faut prendre le temps de creuser pour identifier les vraies causes racines et les traiter.
C’est toute la puissance de l’agilité et de Scrum :
fournir un “moteur” qui permet de s’adapter aux imprévus et de régler les problèmes récurrents ou à venir.
Pour aller plus loin
Le guide Scrum décrit les cérémonies et les rôles dans un équipe Scrum. C’est un livret court (seulement 16 pages), et une référence fiable pour mettre en œuvre correctement Scrum.
