Hoja de repaso: Introduction à Scrum et ses principes fondamentaux

📋 Plan du Cours

1. But du guide et définition
2. Théorie empirique de Scrum
3. Valeurs Scrum
4. La Scrum Team
5. Sprint et planification
6. Daily Scrum et revues
7. Artefacts Scrum et engagements
8. Changements de la version 2020

📖 1. But du guide et définition

🔑 Notions clés & Définitions

• Guide Scrum : Le Guide Scrum est le document qui définit le cadre de travail Scrum et décrit comment chaque élément vise l’obtention de valeur et de résultats.
• Cadre de travail Scrum : Le cadre de travail Scrum rassemble des parties indispensables pour mettre en œuvre la théorie Scrum avec des règles qui guident les relations plutôt que des instructions détaillées.
• Scrum : Scrum est un cadre léger qui aide les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives face à des problèmes complexes.
• Developers : Dans Scrum, le terme Developers désigne un ensemble de personnes qui participent à la création de valeur, sans exclure les autres profils capables d’apporter des compétences nécessaires.

📝 Points essentiels

• Le Guide Scrum a été publié en 2010 pour aider à comprendre Scrum, puis mis à jour par de petites améliorations fonctionnelles jusqu’à la version de novembre 2020.
• Le Guide Scrum contient la définition du cadre Scrum, et chaque élément du cadre sert un objectif essentiel à la valeur globale et aux résultats.
• Ne pas suivre les règles de Scrum, omettre des éléments ou modifier les idées de base peut masquer des problèmes et réduire les avantages, voire rendre Scrum inutile.
• Scrum aide à générer de la valeur via des solutions adaptatives pour des problèmes complexes, en combinant Product Owner, Scrum Team et inspection-adaptation en Scrum.
• Scrum a besoin d’un Scrum Master pour favoriser un environnement où le Product Owner ordonne le travail du Product Backlog, où la Scrum Team produit un Increment en Sprint, et où l’équipe et les parties prenantes inspectent puis s’adaptent pour le prochain Sprint.
• Le cadre est volontairement incomplet : il ne décrit que ce qui est nécessaire, et laisse des pratiques, techniques et méthodes varier selon le contexte.

💡 Astuce mémo

Scrum = PO trie le backlog → Team crée l’Increment → tout le monde inspecte & s’adapte au prochain Sprint.

📖 2. Théorie empirique de Scrum

🔑 Notions clés & Définitions

• Empirisme : Approche selon laquelle la connaissance vient de l’expérience et les décisions s’appuient sur l’observation de faits.
• Pensée Lean : Approche axée sur la réduction du gaspillage et la focalisation sur l’essentiel.
• Approche itérative et incrémentale : Approche où le travail progresse en cycles et ajouts successifs pour améliorer la prédictibilité et contrôler le risque.
• Piliers empiriques de Scrum : Transparence, inspection et adaptation structurent l’enchaînement permettant à Scrum de faire émerger le changement.
• Événement conteneur Sprint : Cadre temporel où Scrum réunit des événements d’inspection et d’adaptation pour piloter l’évolution sur un produit complexe.

📝 Points essentiels

• Scrum est fondé sur l’empirisme et la pensée Lean pour mieux gérer les problèmes complexes.
• Scrum utilise des cycles itératifs et des incréments pour augmenter la prédictibilité et le contrôle du risque.
• Les événements Scrum fonctionnent car ils appliquent les piliers empirique de transparence, inspection et adaptation.
• Sans transparence, l’inspection devient trompeuse et génère du gaspillage.
• Si l’inspection ne conduit pas à une adaptation, elle est jugée infructueuse.
• L’adaptation doit se faire dès que possible quand le processus sort des limites acceptables ou quand le produit est inacceptable.

💡 Astuce mémo

TIA : Transparence → Inspection → Adaptation (l’inspection sans adaptation est stérile).

📖 3. Valeurs Scrum

🔑 Notions clés & Définitions

• Engagement : La valeur d’engagement décrit le fait que la Scrum Team vise ses objectifs et se soutient mutuellement pendant l’exécution du travail.
• Focus : La valeur de focus signifie que la Scrum Team reste concentrée sur ce qui rapproche le plus de l’Objectif de Sprint et des objectifs convenus.
• Ouverture : La valeur d’ouverture signifie que la Scrum Team et ses parties prenantes partagent clairement le travail, les défis et les informations utiles.
• Respect : La valeur de respect implique de considérer chaque membre comme une personne compétente et indépendante, et d’être traité ainsi par les autres.
• Courage : La valeur de courage consiste à oser mener les bonnes actions et affronter des problèmes difficiles malgré les contraintes et l’incertitude.

📝 Points essentiels

• Les cinq valeurs Scrum sont Engagement, focus, ouverture, respect et courage, et elles orientent le travail, l’attitude et les décisions de la Scrum Team.
• Le but principal de la Scrum Team est de réaliser le Sprint afin de progresser le plus possible vers les objectifs du produit.
• Les décisions et les mesures prises avec Scrum doivent renforcer les valeurs, au lieu de les réduire ou de les saper.
• Quand les valeurs sont incarnées, la confiance permet l’émergence des piliers empiriques de transparence, d’inspection et d’adaptation.
• La Scrum Team et les personnes qui l’entourent apprennent et explorent ces valeurs en utilisant les événements et artefacts Scrum.

💡 Astuce mémo

E.F.O.R.C. = Engagement, Focus, Ouverture, Respect, Courage (les 5 piliers humains de Scrum).

📖 4. La Scrum Team

🔑 Notions clés & Définitions

• Scrum Team : La Scrum Team est l’unité fondamentale de Scrum, une petite équipe stable composée de Scrum Master, Product Owner et Developers.
• Product Owner : Le Product Owner est responsable de maximiser la valeur du produit et d’assurer une gestion efficace du Product Backlog pour qu’il soit transparent et compris.
• Scrum Master : Le Scrum Master est responsable de mettre en place Scrum selon le Guide et d’aider la Scrum Team, le Product Owner et l’organisation à réussir avec Scrum.

📝 Points essentiels

• La Scrum Team ne comporte ni équipe dans l’équipe ni hiérarchies, et forme une seule unité stable focalisée sur l’Objectif de Produit.
• Elle est pluridisciplinaire, autogérée, et suffisamment petite pour rester réactive et produire un travail significatif durant le Sprint (habituellement 10 personnes au plus).
• Si une Scrum Team devient trop grande, elle doit envisager de se réorganiser en plusieurs Scrum Teams cohérentes axées sur le même produit avec le même Objectif de Produit, le même Product Backlog et le même Product Owner.
• La Scrum Team est responsable de toutes les activités liées au produit, et elle est habilitée par l’organisation à gérer son propre travail.
• Les Developers s’engagent à traiter tout ou partie d’un Increment utile à chaque Sprint et doivent notamment créer le Sprint Backlog, respecter la Definition of Done, adapter le plan chaque jour et se rendre mutuellement redevables.
• Le Product Owner est une personne et pas un comité, et ses décisions se reflètent dans le contenu et l’ordre du Product Backlog ainsi que dans un Increment inspectable lors de la Sprint Review.

💡 Astuce mémo

3 rôles = 1 objectif : Developers livrent, Product Owner maximise la valeur, Scrum Master fait tenir Scrum (pas de hiérarchie, ≤10).

📖 5. Sprint et planification

🔑 Notions clés & Définitions

• Sprint : Événement Scrum à durée fixe (un mois ou moins) qui sert de conteneur pour transformer des idées en valeur, avec un nouveau Sprint démarrant juste après le précédent.
• Objectif de Sprint : Cible qui rend l’utilité du Sprint claire pour les parties prenantes et qui doit guider les choix tout au long du Sprint.
• Sprint Planning : Événement qui lance le Sprint en construisant, avec toute la Scrum Team, le travail à réaliser durant le Sprint.
• Sprint Backlog : Ensemble constitué de l’Objectif de Sprint, des éléments du Product Backlog sélectionnés pour le Sprint et du plan pour livrer l’Increment.

📝 Points essentiels

• Aucun changement n’est autorisé durant le Sprint s’il remet en cause l’Objectif de Sprint, tandis que les objectifs de qualité ne sont jamais abaissés.
• Chaque Sprint a une durée fixe, et tout le travail pour atteindre l’Objectif de Produit se fait à l’intérieur de ce conteneur.
• Le Sprint Planning doit finaliser l’Objectif de Sprint avant la fin de l’événement.
• Le Sprint Planning est limité à 8 heures pour un Sprint d’un mois, et il est généralement plus court pour des Sprints plus courts.
• Durant le Sprint Planning, les Developers planifient comment créer un Increment conforme à la Definition of Done pour chaque élément sélectionné.

📖 6. Daily Scrum et revues

🔑 Notions clés & Définitions

• Daily Scrum : Événement quotidien de Scrum où les Developers inspectent la progression vers l’objectif de Sprint et ajustent le plan du jour en conséquence.
• Sprint Review : Événement de fin de Sprint où la Scrum Team inspecte les résultats et discute les adaptations futures avec les parties prenantes.
• Sprint Retrospective : Événement de clôture où la Scrum Team inspecte le dernier Sprint et identifie des améliorations pour accroître la qualité et l’efficacité.

📝 Points essentiels

• Le Daily Scrum dure 15 minutes et se tient le même jour ouvré, à la même heure et au même lieu, pour les Developers de la Scrum Team.
• Le Daily Scrum sert à inspecter la progression vers l’objectif de Sprint et à adapter le Sprint Backlog, en décidant les travaux futurs prévus.
• Les Developers produisent un plan d’action pour la prochaine journée pendant le Daily Scrum, afin de renforcer l’autogestion.
• La Sprint Review, avant-dernier événement du Sprint, dure au maximum 4 heures pour un Sprint d’un mois et inclut une collaboration sur la marche à suivre plutôt qu’un simple exposé.
• La Sprint Retrospective dure au maximum 3 heures pour un Sprint d’un mois et vise des améliorations de qualité et d’efficacité basées sur l’inspection des personnes, interactions, processus, outils et Definition of Done.

📖 7. Artefacts Scrum et engagements

🔑 Notions clés & Définitions

• Artefacts de Scrum : Les artefacts de Scrum sont des éléments de travail et de valeur conçus pour rendre visibles les informations clés afin de permettre la même base d’adaptation pour tout le monde.
• Objectif de Produit : L’Objectif de Produit est une cible future qui oriente la planification de la Scrum Team et se trouve dans le Product Backlog.
• Definition of Done : La Definition of Done est une description formelle de l’état d’un Increment quand il respecte les critères de qualité du produit.

📝 Points essentiels

• Chaque artefact de Scrum contient un engagement qui sert la transparence et le focus, rendant possible la mesure de la progression.
• Pour le Product Backlog, l’engagement est l’Objectif de Produit, qui aide à structurer la cible de planification.
• Pour le Sprint Backlog, l’engagement est l’Objectif de Sprint, qui définit le pourquoi du travail choisi pour le Sprint.
• Pour l’Increment, l’engagement est la Definition of Done, et dès qu’un élément du Product Backlog la satisfait, il devient un Increment.
• Un élément non conforme à la Definition of Done ne peut pas être publié ni présenté lors de la Sprint Review et est renvoyé au Product Backlog.
• Si la Definition of Done est une norme d’organisation, toutes les Scrum Teams doivent la suivre, sinon elles créent leur propre Definition of Done et, en cas de plusieurs équipes, elles la définissent ensemble.

💡 Astuce mémo

PB → Objectif de Produit ; Sprint Backlog → Objectif de Sprint ; Increment → Definition of Done. Ensemble, ils rendent tout mesurable et transparent.

📖 8. Changements de la version 2020

🔑 Notions clés & Définitions

• Cadre minimal suffisant : Le cadre 2020 cherche à supprimer autant que possible le langage prescriptif pour ne garder qu’un minimum nécessaire à Scrum.
• Scrum Team unique : La version 2020 met en place une seule Scrum Team concentrée sur le même objectif, avec PO, SM et Developers comme ensembles de responsabilités distincts.
• Engagements liés aux artefacts : Chaque artefact est relié à un engagement : Objectif de Produit pour le Product Backlog, Objectif de Sprint pour le Sprint Backlog et Definition of Done pour l’Increment.

📝 Points essentiels

• La version 2020 vise à redevenir moins prescriptive en supprimant notamment des questions du Daily Scrum et en réduisant la prescription autour des attributs des PBI ainsi que sur la rétrospective et l’annulation de Sprint.
• La logique de “nous et eux” entre Product Owner et Developers (comportement proxy) est réduite car il n’y a désormais qu’une seule Scrum Team pour le même objectif.
• Chaque Sprint doit rapprocher le produit de son objectif global défini par l’Objectif de Produit.
• L’engagement Objectif de Produit apporte plus de clarté en reliant explicitement les artefacts à des engagements pour focaliser la progression et la transparence.
• Le guide 2020 met l’accent sur une autogérée, où la Scrum Team choisit avec qui, comment et sur quoi travailler en visant un objectif.
• La Sprint Planning est structurée autour de trois thèmes : Quoi, Comment et Pourquoi (l’Objectif de Sprint).

💡 Astuce mémo

Moins prescriptif, Une Scrum Team, Objectif de Produit, et 3 thèmes à la Sprint Planning (Quoi-Comment-Pourquoi).

📅 Repères chronologiques

📊 Tableaux de synthèse

Changements clés entre 2017 et 2020

⚠️ Pièges & confusions fréquents

1. Croire qu’il est possible de modifier l’Objectif de Sprint pendant le Sprint si l’on apprend quelque chose de nouveau.
2. Confondre la Scrum Team (1 unité stable) et des sous-équipes avec hiérarchie : dans Scrum, il n’y en a pas.
3. Penser que l’inspection suffit : une inspection sans adaptation est dite infructueuse.
4. Oublier que tout Increment doit respecter la Definition of Done : un élément non conforme ne peut pas être présenté en Sprint Review.
5. Croire que le Product Owner est un comité : c’est une personne, et ses décisions se reflètent dans l’ordre du Product Backlog.
6. Confondre Objectif de Sprint (pour le Sprint) et Objectif de Produit (cible future dans le Product Backlog).
7. Acheter l’idée que Scrum est juste un ensemble de pratiques : le guide précise que Scrum n’existe que dans sa totalité.

✅ Checklist Examen

1. Identifier le but du Guide Scrum et la conséquence de changer/omettre des règles ou idées de base.
2. Donner la définition de Scrum (cadre léger, génération de valeur via solutions adaptatives) et la logique répétable « Essayez-le… ».
3. Expliquer TIA : transparence → inspection → adaptation, et ce que signifie inspection infructueuse sans adaptation.
4. Citer les cinq valeurs Scrum et relier chacune à l’effet sur la confiance et l’émergence des piliers empiriques.
5. Décrire la Scrum Team : membres (Scrum Master, Product Owner, Developers), absence de hiérarchie, taille typique « habituellement dix personnes au plus ».
6. Expliquer les responsabilités Developers (plan de Sprint/Sprint Backlog, Definition of Done, adaptation quotidienne, redevabilité mutuelle).
7. Expliquer les responsabilités Product Owner (maximiser la valeur, gestion du Product Backlog, ordre et transparence).
8. Définir Sprint (conteneur, durée fixe ≤ 1 mois, travail pour atteindre l’Objectif de Produit à l’intérieur) et les règles : pas de changements remettant l’Objectif, qualité non abaissée.
9. Réciter les thèmes de la Sprint Planning (Quoi, Comment, Pourquoi) et le fait que l’Objectif de Sprint doit être finalisé avant la fin de l’événement.
10. Décrire le déroulement/objectif du Daily Scrum (15 minutes, même heure/lieu, production d’un plan d’action) puis ceux de Sprint Review (avant-dernier, max 4h) et Sprint Retrospective (max 3h).
11. Relier les artefacts et engagements : Product Backlog→Objectif de Produit, Sprint Backlog→Objectif de Sprint, Increment→Definition of Done, et la règle de non-publication sans Definition of Done.
12. Citer les changements de 2017 à 2020 : moins prescriptif, une seule Scrum Team, introduction de l’Objectif de Produit, engagements liés aux artefacts, autogérée, et 3 thèmes en Sprint Planning.