4 - Sprint

4 – Événements Scrum : Sprint

Scrum prescrit cinq événements, le Sprint en est le coeur et le conteneur de tous les autres. Il a une durée d’au maximum un mois, ou moins, au cours de laquelle un Incrément de produit « Fini » fonctionnel et potentiellement délivrable est crée (cf. Scrum Guide).

Le Sprint permet de déterminer une fréquence régulière d’inspection et adaptation du produit et de la manière de travailler de la Scrum Team a des fins d’amélioration continue.

Un Sprint peut être considéré comme un mini projet avec : un objectif clair et immuable (le Sprint Goal), une durée fixe (maximum un mois), une qualité irréprochable (rendue transparente dans la définition de « Fini »)… et le contenu ? Des prévisions sur le contenu sont faites au démarrage du Sprint, pendant le Sprint Planning par l’équipe de développement, car pour un produit complexe on acceptera l’adaptation du contenu par rapport à l’emergence de nouvelles informations (positives ou négatives).

A la fin du Sprint, l’équipe de développement doit atteindre le Sprint Goal matérialisé par un Incrément de produit « Fini » et exploitable par l’utilisateur final.

Seule exception serait l’obsolescence du Sprint Goal en cours de Sprint, par exemple pour un changement des conditions de marché. Dans ce cas, seul le Product Owner peut décider d’annuler le Sprint qui se termine prématurément en executant les événements restants.

Tout le travail de l’équipe de développement est fait à l’intérieur d’un Sprint et contenu dans le Product Backlog. Cela implique le fait que les activités de génie logiciel classiques (analyse, conception, développement, test, integration, etc.) ont lieu dans un Sprint de manière non linéaire et grace à la collaboration de tous. On formalisera moins et on collaborera plus. Ce qui compte sera l’Increment « Fini » et pas la documentation.

Par consequent, un Sprint n’a pas d’adjectifs : le Sprint 0, le Sprint de stabilisation, le Sprint de test, le Sprint de conception, etc. n’existent pas en Scrum.

Événements Scrum : Sprint
4 – Sprint

Téléchargez et imprimez (en A4 ou A3) le poster décrivant le premiers des cinq événements Scrum : le Sprint, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.

3 – L’équipe Scrum

L’équipe Scrum est auto-organisée et pluridisciplinaire. Elle est composée de trois rôles avec des responsabilités clairement définies :

  • Le Product Owner : maximise la valeur du produit et gère le Product Backlog.
  • L’Équipe de Développement : crée un Incrément « fini » potentiellement delivrable en production à chaque Sprint et gère le Sprint Backlog.
  • Le Scrum Master : élimine les obstacles qui empêchent le Product Owner ou l’Équipe de Développement de faire leur métier et gère le Cadre Scrum.

Vous l’avez peut être remarqué, en Scrum les personnes ne sont pas managées, en revanche on manage des artefacts.

Le Scrum Guide décrit plus précisément ces rôles et leur responsabilité. Il est important de garder cette simplicité et d’imaginer comment les rôles existants en entreprise peuvent confluer dans ceux de Scrum. La seule question à se poser devrait être : quelles competences sont nécessaires pour créer de la valeur pour les futurs utilisateurs ?

L’auto-organisation en Scrum est fondamentale pour pouvoir délivrer des produits complexes plus rapidement. Elle est possible uniquement si chaque individu dans la Scrum Team a bien compris son rôle. Dans ce cas, comme dans le cas d’un champ magnétique, il y aura un équilibre de forces qui permettra une efficacité sans pairs dans la création de valeur.

3 - Equipe Scrum
3 – L’équipe Scrum

Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.

2 – Fondations de Scrum

Pour bien comprendre les fondations de Scrum, nous partons du postulat que nous créons et maintenons des systèmes complexes : un système informatique, une campagne marketing, une stratégie de vente, etc.

Les fondations de Scrum sont : les Valeurs Scrum et l’empirisme.

Valeurs Scrum

Les valeurs Scrum sont sont fondamentales pour obtenir un état d’esprit adapté aux défis de création de produits complexes, car il vous permettent de vous sentir en sécurité pour essayer et apprendre.

Les Valeurs Scrum vous donnent la FORCE (technique mnémonique utile pour ne jamais les oublier !)

Les valeurs Scrum
Les valeurs Scrum
  • Attention (Focus) : au travail à faire pendant le Sprint et à l’accomplissement du Sprint Goal
  • Ouverture : à la collaboration avec d’autres équipes ou personnes et au critiques constructives qui permettent l’amélioration continue
  • Respect : des personnes, de leurs compétences et expériences ; du cadre Scrum et des responsabilités de chaque rôle
  • Courage : de dire non ! Je ne sais pas ! Appeler à l’aide ! Refuser de créer des fonctionnalités sans valeur pour l’utilisateur final ; courage de refaire ce qui avait été fait ; courage de changer de voie, ou d’opinion ; de défier le statuquo 
  • Engagement : à donner le mieux de soi même dans chaque activité ; à aider les autres membres de l’équipe ; à atteindre le Sprint Goal

Voici une idée d’atelier sur les valeurs Scrum que vous pouvez expérimenter.

Empirisme

Un système complexe ne peut pas être planifié il émergera au fil du temps, grâce aux différentes expérimentations et au feedback des utilisateurs finaux.

L’empirisme est un type de processus de contrôle dans lequel les décisions sont basées sur les résultats observés, l’expérience et l’expérimentation. L’empirisme met en œuvre des inspections régulières et des adaptations nécessitantes et créant de la transparenceAussi appelé « processus de contrôle empirique » (voir lexique Scrum).

Scrum a Pocket Guide - Gunther Verheyen
Scrum a Pocket Guide – Gunther Verheyen

Ainsi, un de premiers axes d’intervention en entreprise consiste à comprendre quel est le niveau de confiance et transparence parmi les parties prenantes impliquées dans la création du produit et agir en conséquence.

Les entreprises dans lesquelles la culture est naturellement basée sur la confiance et la transparence seront, probablement, plus rapidement efficaces dans leurs cycles d’inspection et adaptation.

Axe de réflexion : quel lien faites-vous entre valeurs Scrum et Empirisme ?

Pour aller plus loin dans la compréhension de Scrum, de ses valeurs et de l’Empirisme, je vous conseille la lecture de Scrum a Pocket Guide – 2eme édition de Gunther Verheyen.

Téléchargez et imprimez (en A4 ou A3) le poster relatif à cet article, il pourra vous être utile au bureau, les QR codes permettent d’approfondir les sujets proposés !

Cet article fait partie d’une série de douze publications, chacune expliquant les bases de Scrum. Il pourra vous être utile comme présentation auprès du management, ou toutes personnes curieuses d’approfondir le sujet.