à partir de : https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf
Scrum est un cadre de travail léger qui aide les personnes, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes.
- Un Product Owner ordonne le travail à faire pour résoudre un problème complexe dans le Product Backlog
- La Scrum Team transforme une sélection de ce travail en un Increment de valeur lors d'un Sprint
- La Scrum Team et ses parties prenantes inspectent les résultats et s'adaptent pour le prochain Sprint
- Répéter
Le cadre de travail Scrum est volontairement incomplet, ne définissant que les parties nécessaires pour mettre en œuvre la théorie Scrum. Il repose sur l'intelligence collective des personnes qui l'utilisent.
Scrum est fondé sur l'empirisme et la pensée Lean.
- L'empirisme affirme que la connaissance provient de l'expérience et que la prise de décision s'appuie sur l'observation de faits
- La pensée Lean réduit le gaspillage et se focalise sur l'essentiel
Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et le contrôle de risque.
-
Transparence : Le processus et le travail émergents doivent être visibles pour ceux qui effectuent le travail ainsi que pour ceux qui le reçoivent. Des artefacts peu transparents peuvent mener à des décisions qui diminuent la valeur et augmentent le risque. La transparence permet l'inspection.
-
Inspection : Les artefacts Scrum et les progrès vers les objectifs convenus doivent être inspectés fréquemment et avec diligence pour détecter des écarts ou des problèmes potentiellement indésirables. Scrum fournit une cadence sous la forme de ses cinq événements. L'inspection permet l'adaptation.
-
Adaptation : Si certains aspects d'un processus s'écartent des limites acceptables ou si le produit résultant est inacceptable, alors le processus appliqué ou les éléments produits doivent être adaptés. L'adaptation doit être effectuée le plus rapidement possible afin de minimiser tout écart supplémentaire.
L'application réussie de Scrum dépend de la capacité des personnes à mieux vivre ces cinq valeurs : Engagement, Focus, Ouverture, Respect et Courage.
- La Scrum Team s'engage à atteindre ses objectifs et à se soutenir mutuellement
- Son but principal est la réalisation du Sprint pour progresser le plus possible vers ces objectifs (le focus)
- La Scrum Team et ses parties prenantes sont ouvertes sur le travail et les défis à relever
- Les membres de la Scrum Team se respectent mutuellement pour être des personnes compétentes et indépendantes
- Les membres de la Scrum Team ont le courage de mener les bonnes actions et de travailler sur des problèmes difficiles
Ces valeurs orientent le travail, les actions et l'attitude de la Scrum Team. Lorsque ces valeurs sont incarnées, les piliers empiriques de transparence, d'inspection et d'adaptation émergent en consolidant la confiance.
L'unité fondamentale de Scrum est une petite équipe, la Scrum Team. Elle se compose d'un Scrum Master, d'un Product Owner et de Developers. Il n'y a pas d'équipe dans l'équipe ni de hiérarchies.
- Pluridisciplinaire : Les membres ont toutes les compétences nécessaires pour créer de la valeur à chaque Sprint
- Autogérée : Décide en interne qui fait quoi, quand et comment
- Taille : Suffisamment petite pour rester réactive, habituellement 10 personnes au plus
- Responsabilité collective : Toute la Scrum Team est responsable de la création d'un Increment qui ait de la valeur et qui soit utile à chaque Sprint
- Focalisée : Sur un seul objectif à la fois, l'Objectif de Produit
- Stable : C'est une seule et même unité stable de professionnels
La Scrum Team est responsable de toutes les activités liées au produit : collaboration des parties prenantes, vérification, maintenance, exploitation, expérimentation, recherche et développement.
Les Developers sont les membres de la Scrum Team qui s'engagent à traiter tout ou partie utile d'un Increment à chaque Sprint.
Redevabilités :
- Créer un plan de Sprint, un Sprint Backlog
- Inculquer la notion de qualité en adhérant à une Definition of Done
- Adapter leur plan chaque jour par rapport à l'Objectif de Sprint
- Se tenir mutuellement responsables en tant que professionnels
Les compétences spécifiques requises pour les Developers sont souvent larges et varient selon le domaine d'activité.
Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team.
Redevabilités :
- Formuler et communiquer explicitement l'Objectif de Produit
- Créer et communiquer clairement les éléments du Product Backlog
- Ordonner les éléments dans le Product Backlog
- S'assurer que le Product Backlog est transparent, visible et compris
Points importants :
- Le Product Owner est une personne et non un comité
- Le Product Owner peut déléguer le travail à d'autres, mais en demeure redevable
- Toute l'organisation doit respecter ses décisions
- Ceux qui souhaitent modifier le Product Backlog doivent le convaincre
Le Scrum Master est redevable de la mise en place de Scrum tel que défini dans le Guide Scrum et de l'efficacité de la Scrum Team. C'est un véritable leader au service de la Scrum Team et de l'ensemble de l'organisation.
Service à la Scrum Team :
- Accompagner les membres en matière d'autogestion et de pluridisciplinarité
- Aider la Scrum Team à se focaliser sur la création d'Increments de grande valeur qui répondent à la Definition of Done
- Faire en sorte qu'il n'y ait pas d'obstacles pouvant entraver la progression
- S'assurer que tous les événements Scrum ont bien lieu et sont efficients, productifs et respectent bien les temps impartis
Service au Product Owner :
- L'aider à trouver des techniques pour définir efficacement l'Objectif de Produit et gérer le Product Backlog
- Sensibiliser la Scrum Team à la nécessité d'avoir des éléments du Product Backlog clairs et concis
- Encourager l'application de la planification produit empirique dans un environnement complexe
- Faciliter la collaboration des parties prenantes
Service à l'organisation :
- Accompagner, former et encadrer l'organisation dans son adoption de Scrum
- Planifier et apporter conseils sur les implémentations de Scrum
- Faciliter la compréhension de l'approche empirique en environnement complexe
- Contribuer à lever les obstacles entre les parties prenantes et les Scrum Teams
Le Sprint est un conteneur pour tous les autres événements. Chaque événement dans Scrum est une occasion formelle pour inspecter et adapter les artefacts Scrum. Ces événements sont spécifiquement conçus pour permettre la transparence requise.
L'incapacité d'organiser les événements conformément à leur prescription est une occasion perdue pour inspecter et s'adapter. Idéalement, tous les événements se tiennent à la même heure et au même lieu pour réduire la complexité.
Les Sprints sont au cœur de Scrum, où les idées sont transformées en valeur.
Caractéristiques :
- Événements d'une durée fixe, d'un mois ou moins
- Un nouveau Sprint commence immédiatement après la fin du précédent
- Tout le travail nécessaire pour atteindre l'Objectif de Produit se fait dans le cadre des Sprints
Durant le Sprint :
- Aucun changement n'est permis qui pourrait remettre en cause l'Objectif de Sprint
- Les objectifs de qualité ne sont jamais revus à la baisse
- Le Product Backlog est affiné si nécessaire
- Le périmètre peut être clarifié et renégocié avec le Product Owner selon ce qu'on en apprend
Bénéfices :
- Permettent la prédictibilité en assurant l'inspection et l'adaptation de la progression vers l'Objectif de Produit au moins une fois par mois
- Les Sprints plus courts raccourcissent le cycle de l'apprentissage, limitant les risques liés aux coûts et à l'effort
Annulation : Un Sprint peut être annulé si l'Objectif de Sprint devient obsolète. Seul le Product Owner a le pouvoir d'annuler le Sprint.
Le Sprint Planning lance le Sprint en présentant le travail à effectuer durant le Sprint. Le plan qui en résulte est créé par le travail collaboratif de toute la Scrum Team.
Le Product Owner veille à ce que les participants soient prêts à discuter les éléments les plus importants du Product Backlog et de comment ces éléments représentent l'Objectif de Produit.
Trois thèmes abordés :
1. Pourquoi ce Sprint est-il important ?
- Le Product Owner explique comment augmenter la valeur du produit et son utilité pour le Sprint en cours
- L'ensemble de la Scrum Team collabore à définir un Objectif de Sprint
- L'Objectif de Sprint doit être finalisé avant la fin du Sprint Planning
2. Que peut-on faire durant ce Sprint ?
- En discutant avec le Product Owner, les Developers sélectionnent les éléments du Product Backlog à inclure
- La Scrum Team affine ces éléments, améliorant leur compréhension et leur confiance
- Plus les Developers connaissent leurs performances passées, leur capacité à venir et leur Definition of Done, mieux ils sont à même de faire des prévisions
3. Comment le travail choisi sera-t-il réalisé ?
- Les Developers planifient le travail nécessaire pour créer un Increment qui réponde à la Definition of Done
- Cela se fait souvent en décomposant les éléments du Product Backlog en éléments de travail d'une journée ou moins
- La façon de procéder est laissée à la seule discrétion des Developers
Résultat : L'Objectif de Sprint, les éléments du Product Backlog sélectionnés et le plan pour les livrer forment le Sprint Backlog.
L'objectif du Daily Scrum est d'inspecter la progression vers l'Objectif de Sprint et d'adapter le Sprint Backlog si nécessaire, en ajustant les futurs travaux planifiés.
Caractéristiques :
- Événement de 15 minutes pour les Developers de la Scrum Team
- Tenu à la même heure et au même lieu, chaque jour ouvré du Sprint
- Si le Product Owner et/ou le Scrum Master travaillent activement sur des éléments du Sprint Backlog, ils participent en tant que Developers
Fonctionnement :
- Les Developers peuvent choisir la structure et les techniques qu'ils souhaitent
- Le Daily Scrum doit se focaliser sur la progression vers l'Objectif de Sprint
- Il doit produire un plan d'action pour la prochaine journée de travail
Bénéfices :
- Améliorent la communication
- Aident à identifier les obstacles
- Favorisent la prise de décision rapide
- Éliminent la nécessité de faire d'autres réunions
Le Daily Scrum n'est pas le seul moment où les Developers sont autorisés à ajuster leur plan. Ils se réunissent souvent tout au long de la journée pour des discussions plus détaillées.
L'objectif de la Sprint Review est d'inspecter le résultat du Sprint et de déterminer les adaptations futures.
Déroulement :
- La Scrum Team présente les résultats de son travail aux principales parties prenantes
- Les progressions vers l'Objectif de Produit sont discutées
- La Scrum Team et les parties prenantes passent en revue ce qui a été accompli durant le Sprint et ce qui a changé dans leur environnement
- Les participants collaborent sur la marche à suivre et sur les décisions à prendre
- Le Product Backlog peut être ajusté pour répondre à de nouvelles opportunités
Important :
- La Sprint Review est une session de travail
- La Scrum Team doit éviter de la limiter à une session de présentation
- C'est l'avant-dernier événement du Sprint
L'objectif de la Sprint Retrospective consiste à réfléchir à des pistes pour améliorer la qualité et l'efficacité.
Inspection :
- La Scrum Team inspecte le déroulement du dernier Sprint concernant les individus, les interactions, les processus, les outils et leur Definition of Done
- Les hypothèses qui les ont fait dévier sont identifiées et leurs origines explorées
- La Scrum Team discute de ce qui s'est bien passé, des problèmes rencontrés et de la manière dont ces problèmes ont été (ou n'ont pas été) résolus
Amélioration :
- La Scrum Team identifie les changements les plus utiles pour améliorer son efficacité
- Les améliorations ayant le plus d'impact sont abordées dès que possible
- Elles peuvent même être ajoutées au Sprint Backlog pour le prochain Sprint
Conclusion : La Sprint Retrospective conclut le Sprint.
Les artefacts de Scrum représentent un travail ou une valeur. Ils sont conçus pour maximiser la transparence des informations clés. Ainsi, tous ceux qui les inspectent ont la même base d'adaptation.
Chaque artefact contient un engagement qui apporte l'information nécessaire à la transparence et au focus rendant possible la mesure de la progression.
Le Product Backlog est une liste ordonnée et émergente de ce qui est nécessaire pour améliorer le produit. C'est l'unique source du travail entrepris par la Scrum Team.
Affinement du Product Backlog :
- Consiste à décomposer et à définir davantage les éléments du Backlog en éléments plus fins et plus précis
- C'est une activité continue visant à ajouter des détails tels qu'une description, un ordre et une taille
- Les Developers qui effectueront le travail sont responsables du dimensionnement
- Le Product Owner peut influencer les Developers en clarifiant ses explications et les aider à trouver des compromis
Éléments prêts : Les éléments du Product Backlog qui sont susceptibles d'être réalisés dans un seul Sprint par la Scrum Team sont considérés comme prêts à être traités en Sprint Planning. Ils acquièrent généralement ce degré de transparence après avoir été affinés.
Engagement : Objectif de Produit
L'Objectif de Produit décrit un état futur du produit qui peut servir de cible à la Scrum Team pour planifier. Il est dans le Product Backlog.
- C'est l'objectif à long terme de la Scrum Team
- Un produit est un vecteur de valeur avec une limite claire, des parties prenantes connues, des utilisateurs ou des clients bien définis
- Un produit peut être un service, un produit physique ou quelque chose de plus abstrait
- La Scrum Team doit atteindre (ou abandonner) un objectif avant de s'attaquer au suivant
Le Sprint Backlog est composé de :
- L'Objectif de Sprint (le « pourquoi »)
- L'ensemble des éléments du Product Backlog choisis pour le Sprint (le « quoi »)
- Un plan d'action pour la réalisation de l'Increment (le « comment »)
Caractéristiques :
- C'est un plan élaboré par et pour les Developers
- Image très visible et en temps réel du travail que les Developers prévoient d'accomplir durant le Sprint
- Mis à jour tout au long du Sprint selon ce qu'on en apprend
- Doit être suffisamment détaillé pour que les Developers puissent inspecter leur progression durant le Daily Scrum
Engagement : Objectif de Sprint
L'Objectif de Sprint est l'unique but du Sprint. Bien que ce soit un engagement fait par les Developers, il offre une certaine flexibilité en termes de travail nécessaire pour atteindre cet objectif.
- Crée de la cohérence et du focus
- Encourage la Scrum Team à travailler ensemble plutôt que sur des initiatives séparées
- Créé pendant le Sprint Planning, puis ajouté au Sprint Backlog
- Les Developers gardent l'Objectif de Sprint à l'esprit pendant le Sprint
- Si le travail s'avère différent, ils collaborent avec le Product Owner pour négocier le périmètre du Sprint Backlog sans affecter l'Objectif de Sprint
Un Increment est une première étape concrète vers l'Objectif de Produit. Chaque Increment s'ajoute à tous les Increments précédents et fait l'objet d'une vérification approfondie, ce qui garantit que tous les Increments fonctionnent ensemble.
Caractéristiques :
- Doit être utilisable pour fournir de la valeur
- Plusieurs Increments peuvent être créés durant un Sprint
- La somme des Increments est présentée lors de la Sprint Review
- Un Increment peut être livré aux parties prenantes avant la fin du Sprint
- La Sprint Review ne doit jamais être considérée comme le seul moment pour délivrer de la valeur
Important : Un travail qui ne remplirait pas les conditions de la Definition of Done ne peut pas être considéré comme un Increment.
Engagement : Definition of Done
La Definition of Done est une description formelle de l'état de l'Increment lorsqu'il satisfait les mesures de qualité requises pour le produit.
Fonction :
- Apporte de la transparence en permettant à chacun une compréhension commune du travail Fini dans le cadre de l'Increment
- Dès qu'un élément du Product Backlog satisfait à la Definition of Done, il se transforme en Increment
- Si un élément du Product Backlog n'est pas conforme à la Definition of Done, il ne peut pas être publié ni même présenté lors de la Sprint Review, et est renvoyé au Product Backlog
Standards :
- Si la Definition of Done pour un Increment fait partie des standards de l'organisation, toutes les Scrum Teams doivent la suivre au minimum
- Si cela ne fait pas partie des standards, la Scrum Team doit créer sa propre Definition of Done appropriée pour le produit
- Les Developers sont tenus de se conformer à la Definition of Done
- Si plusieurs Scrum Teams travaillent ensemble sur un même produit, elles doivent la définir ensemble et s'y conformer
- Le cadre de travail Scrum est volontairement incomplet, ne définissant que les parties nécessaires pour mettre en œuvre la théorie Scrum
- Scrum repose sur l'intelligence collective des personnes qui l'utilisent
- Plutôt que de fournir des instructions détaillées, les règles de Scrum guident les relations et les interactions
- Divers processus, techniques et méthodes peuvent être employés dans ce cadre de travail
- Scrum rend visible l'efficacité relative du management existant, de l'environnement et des techniques de travail
- Cela permet que des améliorations puissent être apportées
- Scrum englobe des pratiques existantes ou les rend inutiles
- Durant le Sprint, aucun changement ne peut remettre en cause l'Objectif de Sprint
- Les objectifs de qualité ne sont jamais revus à la baisse
- Seul le Product Owner peut annuler un Sprint (si l'Objectif de Sprint devient obsolète)
- Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et le contrôle de risque
- Scrum engage des groupes de personnes qui ont collectivement toutes les compétences et l'expertise requises
- Travailler sur des Sprints à un rythme soutenable améliore le focus et la cohérence
- Diverses pratiques existent : courbes de burn-down, burn-up, diagrammes de flux cumulatifs
- Ces courbes ne remplacent pas l'importance de l'empirisme
- Dans des environnements complexes, seul ce qui s'est déjà passé peut être utilisé pour une prise de décision à venir
Scrum est gratuit et offert dans ce guide. Le cadre de travail Scrum, tel que décrit, est immuable.
Bien que la mise en œuvre uniquement de certaines parties de Scrum soit possible, le résultat ne sera pas du Scrum. Scrum n'existe que dans sa totalité et peut fonctionner comme un conteneur pour d'autres techniques, méthodologies et pratiques.
Résumé basé sur le Guide Scrum officiel de Ken Schwaber et Jeff Sutherland, version novembre 2020