Mettons les choses au clair:
· Scrum est un simple cadre de travail
· Sprint est une durée faisant partie du cadre Scrum
· Spring est une joke pour attirer votre attention
Maintenant que vous êtes attentif, imaginez un jeu d’échec avec pas de plateau : ce serait le chaos! Le cadre Scrum aide à mettre de l’ordre et à simplifier certaines choses dans un contexte complexe. Parce qu’on va se le dire, si dans un projet, il y a l’ombre d’une incertitude ou d’un inconnu, c’est là que ça devient complexe.
Le Guide Scrum 2020 dit : “Scrum is simple”.
C’est faux.
Si c’était vrai, il n’y aurait pas de formations, de tonnes de livres et de blogs, ni même ce présent texte pour l’expliquer. Le principal problème avec Scrum, c’est son jargon. Il a été pensé par des Geeks. On aime les Geeks, mais on ne les comprend pas toujours du premier coup. Du coup, pour simplifier Scrum, le truc est de le rendre accessible à ceux qui n’y connaissent rien au Rugby ni même aux TI.
Voyons Scrum comme un jeu de rôle coopératif.
Scrum, le jeu
· Le but du jeu est d’ajouter de la valeur à un produit de façon rapide et progressive
· Pour ce faire, les joueurs collaborent sur des cycles de 1 à 4 semaines
· La durée du jeu est infinie, parce qu’un produit peut toujours être amélioré
· Les cycles sont ainsi répétitifs et constants
Matériel nécessaire
· Un produit qui a un objectif (ce produit peut être un service, une application, une omelette)
· Une liste de travaux ou d’idées à réaliser pour ajouter de la valeur au produit (l’améliorer)
· Un jargon particulier pour se reconnaître en tant qu’initié au jeu
· Des joueurs qui comprennent et respectent la règle du jeu
· Quelques pratiques agiles pour rendre le tout encore plus agréable (nous y reviendrons)
Jargon Scrum
· Le cycle de 1 à 4 semaines se nomme Sprint
· Le fait de jouer en Sprint répété constamment se nomme Itération
· La valeur ajoutée au produit de façon constante se nomme Incrément
· Les réunions planifiées pour s’inspecter et valider le travail se nomment Événements
· La liste des travaux ou idées pour améliorer le produit se nomme Product Backlog
· La liste des travaux que l’équipe s’engage à réaliser pendant un Sprint se nomme Sprint Backlog
· Les éléments qui représentent le travail ou la valeur ajouté se somme Artéfact (terme qu’on n’utilise pratiquement jamais et qui fait la fierté des initiés du jargon conceptuel Scrum)
· Tout autre mot weird qui peut éventuellement être traduit en langage accessible au pas geek
Les joueurs de Scrum
L’équipe Scrum
Interfonctionnelle, multidisciplinaire et responsable de toutes les activités reliées au produit, elle est composée de 3 rôles clés sans hiérarchie :
· Un à huit Développeurs (Dev), responsables de créer la valeur du produit. Ici, toute personne qui participe à la création de valeur, qu’il soit engagé par les RH en tant que conseiller, analyste, architecte ou cuisinier, est considéré comme un Dev.
· Un Product Owner (PO), porteur de la vision et responsable de maximiser la valeur du produit créé par les Dev
· Un Scrum Master (SM), «maître du jeu de rôle» responsable de l’efficacité de l’équipe et de la rendre autonome
Les parties prenantes
Responsables de collaborer avec l’équipe Scrum, elles comprennent :
· Le client
· L’organisation
· Les collègues ne faisant pas partie de l’équipe Scrum et qui l’aident dans ses travaux
Préparation
1. Identifiez un produit, déterminez son objectif et engagez-vous à utiliser Scrum (ou changez de jeu tout de suite)
2. Composez votre équipe Scrum avec des professionnels qui se complètent dans leurs compétences et qui pourront ainsi être en mesure de créer de la valeur de façon autonome.
3. Trouver une personne qui accepte le rôle de Product Owner et une autre personne qui accepte celui de Scrum master. Attention! Ne jamais «nommer» quelqu’un à l’un de ces rôles.
4. Veiller à ce que tous les membres de l’équipe soient formés adéquatement en Scrum, particulièrement le PO et le SM dans leur rôle
5. Aider le Product Owner à bâtir le Product Backlog en collaboration avec les joueurs, plus spécifiquement avec ses coéquipiers de l’équipe Scrum.
6. Déterminer la durée de chaque Sprint, soit entre 1 et 4 semaines maximum.
Déroulement du jeu
Chaque Sprint compte 4 phases :
1. La phase de planification
2. La phase de développement
3. La phase de revue
4. La phase de rétrospective
En continue durant ces phases, l’équipe Scrum inspecte la liste des travaux pour améliorer le produit ou le service (le Product Backlog) pour s’assurer qu’il soit toujours à jour et pertinent à mesure que le temps file (sait-on jamais quand un virus pourrait apparaître et changer le contexte). Cette inspection permet de préciser des éléments, de s’assurer que tout le monde comprend le travail à faire et qu’il y a un consensus sur la manière et le moment de le réaliser.
Phase 1 – la planification
La planification est un moment où tous les membres de l’équipe Scrum se réunissent pour déterminer l’objectif des prochaines semaines (du Sprint) et répondre aux questions suivantes :
1. Que peut-on livrer dans le prochain Sprint ?
2. Comment les travaux seront réalisés ?
Avec l’aide de ses coéquipiers, le Product Owner aura déjà mis de l’ordre dans la liste des travaux pour améliorer le produits ou le service (le Product Backlog) en plaçant en priorité les éléments essentiels et les plus pertinents pour livrer de la valeur au client.
En équipe, on construit et ainsi la liste des choses à réaliser dans les prochaines semaines (le Sprint Backlog), qui devrait permettre d’atteindre l’objectif des prochaines semaines (l’objectif de Sprint), et on s’engage à ensemble à livrer tout ce qui se trouve.
Phase 2 – le développement
Chaque jour, les développeurs se rencontre un maximum de 15 minutes pour synchroniser leurs travaux en vue d’atteindre l’objectif des prochaines semaines (l’objectif du Sprint). Si quelque chose survient et ralenti ou bloque les travaux, l’information est rapidement communiquée et un plan d’urgence est enclenché pour enlever ce bloquant.
Le PO et le SM sont invités à ses rencontres quotidienne, mais ils ne sont pas tenus d’y participer. Ces rencontres sont appelées «mêlée quotidienne» ou «Daily» ou très souvent juste «Scrum».
Phase 3 – la revue
À la fin de la période d’une à quatre semaines qu’on s’est donné pour réaliser les travaux (autrement dit à la fin du Sprint), une rencontre informelle est tenue avec tous les joueurs pour inspecter les réalisations et discuter de ce qui s’est passé durant cette période de jeu. Le but est de sortir avec un backlog à jour selon les dernières informations partagées pour rester pertinent dans le développement du produit ou du service.
Phase 4 – La rétrospective
Après la revue de Sprint, l’équipe Scrum se réunie pour discuter de comment s’est passé le dernier Sprint et surtout comment améliorer les pratiques pour faire des progrès et gagner en efficience.
Bref, c’est comme un jeu d’enfant, mais différent.
