Blog

Qu'est-ce que scrum ?

1 – Qu’est-ce que Scrum ?

Posted on by Fabio Panzavolta in Les bases de Scrum
Twitter Linkedin scrum

C’est quoi SCRUM MASTER ?

1. Un peu d’histoire

Scrum Master est un cadre de travail dans lequel les personnes peuvent résoudre des problèmes adaptatifs complexes, tout en fournissant de manière productive et créative des produits de la plus haute valeur possible.

The New New Product Development Game
The New New Product Development Game

Le mot Scrum, la mêlée en rugby, a été choisi par Ken Schwaber et Jeff Sutherland dans les années 1990. C’est un hommage à Hirotaka Takeuchi et Ikujiro Nonaka, les auteurs de l’article « The New New Product Developement Game » qui a fortement inspiré les expérimentations initiales.

Un cadre de travail constitue un ensemble de principes et de règles à suivre pour atteindre un but commun. Les personnes, organisées en équipe auto-organisée et pluridisciplinaire, auront plus de chances d’atteindre l’objectif de chaque Sprint et s’amélioreront continuellement.

The Scrum Guide 2017
The Scrum Guide 2017


Tous les joueurs sur le terrain, les entraineurs et les arbitres, connaissent les règles du rugby. En entreprise, il est préférable que toutes les parties prenantes d’une équipe Scrum comprennent les règles du jeu. En d’autre termes, la compréhension du cadre de travail ne peut pas être superficielle, déléguée ou ignorée !

Une équipe Scrum, avec le temps, deviendra l’équivalent d’une équipe de rugby hyper performante. Par consequence elle sera capable de résoudre des problèmes complexes de manière empirique.

Qu'est-ce que scrum ?

SCRUM – Un cadre de travail

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 la méthodologie du SCRUM MASTER !

2. Les fondations de SCRUM

C’est quoi SCRUM MASTER ? 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.

Les valeurs de SCRUM

Le cadre Scrum est basé sur cinq valeurs fondamentales pour stimuler les comportements adaptés aux défis de création de produits complexes. Ce document est la traduction d’une idée originale de Gunther Verheyen, vous retrouverez la version originale et internationale sur son site web.

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
  • 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 transparence. Aussi appelé « processus de contrôle empirique » (voir lexique Scrum).

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 !

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 compétences sont nécessaires pour créer de la valeur pour les futurs utilisateurs ?

 

3 - Equipe Scrum

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.

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 !

Les 5 évevements Scrum

L’évènement – 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.

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 !

4 - Sprint

L’évènement sprint planning

Évènements Scrum : Sprint Planning

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 !

Le Sprint Planning est le premier évènement d’un Sprint. Son objectif est de collaborer à la planification du travail à effectuer durant le Sprint. C’est un timebox de 8 heures pour un Sprint d’un mois, proportionnellement moins pour un Sprint plus court. Toute la l’Équipe Scrum y participe.

Un Sprint Planning est composé de deux parties principales.

  1. Le Product Owner, présente une proposition de Sprint Goal correspondant à son objectif pour le Sprint et un Product Backlog ordonnancé en cohérence avec ce but.
  2. La partie haute du Product Backlog sera composé d’éléments suffisamment petits, connus et compris par l’Équipe de Développement.

L’Équipe Scrum collabore pour définir un Sprint Goal réaliste et atteignable pour la fin du Sprint.

L’évènement – Daily Scrum

Le Daily Scrum est un évènement quotidien destiné à l’Équipe de Développement et qui a pour but de planifier le travail des prochaines 24 heures. C’est un time-box de 15 minutes.

Le Daily Scrum a lieu toujours au même endroit et à la même heure, pour réduire la complexité. C’est l’Équipe de Développement qui décide de l’organisation.

Le Daily Scrum permet à l’Equipe de Développement de comprendre si le Sprint Goal sera atteint ou pas pour la fin du Sprint. Pour ce faire, l’équipe s’auto-organise pour échanger sur ce qui a été fait, ce qui reste à faire et les obstacles qui empêchent le travail de se réaliser.

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 !

L’évènement – Sprint Review

Sprint Review

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 !

La Sprint Review est l’événement au cours duquel l’Équipe Scrum et les parties prenantes (invitées par le Product Owner) se retrouvent pour inspecter l’Incrément et adapter le Product Backlog. Cette fréquence d’inspection et adaptation du travail effectué est très importante pour comprendre si la direction prise est correcte et ensemble décider de la modifier.

Il s’agit d’un événement informel, qu’il n’a donc pas besoin de préparation, car on inspectera un Incrément « fini » et par définition en état de marche et sans anomalies, prêt à être mis en production si le Product Owner le décide.

L’évènement – Sprint Retrospective

Une Sprint Rétrospective est une opportunité, pour l’équipe Scrum, d’inspecter le déroulement du Sprint et créer un plan d’amélioration à adopter lors du prochain Sprint.

Il s’agit d’un timebox de trois heures pour un Sprint d’un mois, proportionnellement moins pour un Sprint plus court.

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 !

Sprint Retrospective

Artefact Scrum – Product Backlog

Product Backlog

Le Product Backlog est une liste ordonnée et évolutive de tous les travaux jugés nécessaires par le Product Owner pour créer, publier, maintenir et entretenir un produit.

Chaque Produit a un et un seul Product Backlog, géré par un et un seul Product Owner.

Un Product Backlog est en évolution constante, grâce au feedback fourni par les parties prenantes au fil du temps et en Sprint Review.

Un Product Backlog existe jusqu’au retrait du Produit du marché.

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

SUR LE Même thème

Product Backlog

9 – Artefacts Scrum : Product Backlog

Posted on by Fabio Panzavolta in Les bases de Scrum

Le Product Backlog est une liste ordonnée et évolutive de tous les travaux jugés nécessaires par le Product Owner pour créer, publier, maintenir et entretenir un produit.

Chaque Produit a un et un seul Product Backlog, géré par un et un seul Product Owner.

Un Product Backlog est en évolution constante, grâce au feedback fourni par les parties prenantes au fil du temps et en Sprint Review.

Un Product Backlog existe jusqu’au retrait du Produit du marché.

Pour rendre transparent le Product Backlog, le Product Owner veillera, entre autres, à :

  • Ordonnancer son contenu : de telle sorte qu’il reflète sa vision
  • Rendre le contenu du Product Backlog accessible à tous dans l’entreprise
  • Assurer une compréhension partagée du contenu Product Backlog. Souvent, par exemple, chaque élément du Product Backlog aura les informations suivantes : un titre, une description, des critères d’acceptation, une valeur métier, une estimation de complexité.
Product Backlog
Product Backlog

Adaptation du Product Backlog

L’adaptation du Product Backlog est fondamentale pour maximiser la valeur délivrée, mais en quoi consiste exactement cette adaptation ?

  • Ré-ordonnancement du contenu, suite au feedback des parties prenantes en Sprint Review et au fil du temps
  • Ajout de nouvelles idées
  • Retrait d’idées passées qui ne correspondent plus à la vision (et n’ont plus de valeur)
  • Toute autre action qui permet de rendre le Product Backlog correctement ordonnancé

La valeur est le seul critère pour ordonnancer le Product Backlog ?

Non. En effet, la valeur est un concept subjectif. Le Product Owner ordonnance le Product Backlog en discutant avec les parties prenantes. D’autres paramètres sont à prendre en compte pour ordonnancer le Product Backlog comme, par exemple :

  • La valeur métier : le problème le plus urgent à résoudre pour les utilisateurs, une contrainte réglementaire, une fonctionnalité qu’aucun concurrent possède, etc.
  • Le risque : en Scrum le risque ne se gère pas, il est traité en premier. Cela a un impact sur l’ordonnancement
  • La taille de l’élément du Product Backlog : les éléments de plus haute valeur auront une taille jugée par l’équipe de développement comme réalisable en un Sprint

En aucun cas, l’ordonnancement est dicté par la difficulté de réalisation. Le Product Owner prend en compte l’avis de l’équipe de développement, sans pour autant faire un focus sur « le facile à faire » d’abord, car cela ne correspond pas à la maximisation de la valeur.

Quel niveau de détails doit avoir un élément du Product Backlog

Un niveau suffisant pour permettre à tous de comprendre et se souvenir du sujet à discuter, le jour venu.

Souvenez-vous d’un des quatre principes de l’Agile Manifesto : « les individus et leurs interactions plus que le processus et les outils ». Il s’agit de marquer l’idée dès qu’elle se présente et en suite la développer au moment ou elle devient « prioritaire ».

Nul besoin de passer des heures à écrire des spécifications détaillées, car cela serait une perte de temps et d’énergies qui pourraient être consacrées à des sujets à valeur immédiate pour les utilisateurs.

Agile Estimating and Planning
Agile Estimating and Planning

On privilégiera la collaboration de toutes les personnes compétentes sur le sujet, au moment opportun.

Vous souhaitez aller plus loin au sujet des estimations et de la planification Agile ? Le livre « Agile Estimating and Planning » de Mike Cohn est un bon début.

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.

Sprint Retrospective

8 – Evénements Scrum – Sprint Retrospective

Posted on by Fabio Panzavolta in Les bases de Scrum

Une Sprint Rétrospective est une opportunité, pour l’équipe Scrum, d’inspecter le déroulement du Sprint et créer un plan d’amélioration à adopter lors du prochain Sprint.

Il s’agit d’un timebox de trois heures pour un Sprint d’un mois, proportionnellement moins pour un Sprint plus court.

Imaginez vous comme une équipe de Rugby, n’ayant jamais joué à ce jeu. L’efficacité des premiers matchs sera moindre. A chaque fin partie, l’équipe discutera les actions d’amélioration à implémenter pour le prochain match, comme, par exemple :

  • Le niveau de comprehension des valeurs et des règles du jeu par les joueurs;
  • L’efficacité du processus mis en place pour satisfaire le but du jeu;
  • Les outils utilisés quotidiennement, sont ils efficaces pour atteindre l’objectif, ils nous simplifient la vie ou ils nous la compliquent ?
  • Les relations entre joueurs et avec les parties prenantes de l’équipe

Le Scrum Master s’assurera que toute la Scrum Team participe à l’événement et que le but à atteindre est clair pour tous.

Il pourra faciliter la session, à la demande de l’équipe, ou y participer en contribuant à l’émergence de nouvelles idées d’amélioration.

Sprint Retrospective
Sprint Retrospective

Trois heures c’est beaucoup trop pour une réunion !

Scrum vous aide à créer un processus empirique pour délivrer un Produit ou Service innovant. Le temps dédié à la recherche de la performance n’est pas du temps perdu, il s’agit de temps investi pour l’avenir. Souvent cette phrase est prononcée dans les environnements de travail ou :

  • Il y a la réunionnite : maladie connue dans beaucoup d’entreprises et qui consiste à organiser des réunions qui n’ont pas un but précis, dans lesquelles on s’ennuie. Dans ces contextes, et c’est compréhensible, les personnes avant de s’engager sur trois heures font très attention;
  • Tout le monde est tout le temps débordé : il y a un manque de focus pour pouvoir se dédier pleinement à un sujet;
  • Individualisme : un processus empirique requiert de la transparence. Ne pas participer aux événements Scrum équivaut à regarder à travers d’une vitre opaque. Comment s’améliorer ensemble si on ne prends pas le temps de se retrouver ?

Le Product Owner doit participer à la Sprint Retrospective?

Bien sur ! Elle/il est membre de l’équipe Scrum, à ce titre sa participation est fondamentale. Si elle/il ne participe pas, comment savoir si les relations entre les autres parties de l’équipe sont correctes ? Comment améliorer la manière que vous avez de travailler ensemble ?

Une des forces de Scrum consiste à abattre les silos… alors si le/la Product Owner est une personne du métier elle doit comprendre que faire partie d’une équipe Scrum nécessite de l’implication et de la collaboration !

Nous sommes en retard, nous allons gagner du temps en annulant la Sprint Retrospective !

Combien de fois j’ai entendu cette phrase… vous aussi ?

Imaginez vous une équipe de Rugby qui décide de ne pas aller dans les vestiaires à la mi-temps pour marquer plein d’essais pendant que l’équipe adverse n’est pas la, c’est possible ?

C’est un discours qui est souvent motivé par :

  • Une pression externe à l’équipe Scrum, poussée à délivrer toujours plus et plus vite… pour la qualité on repassera. On privilégie la quantité à la valeur crée.
  • Un Product Owner qui pousse l’équipe de développement à faire toujours plus, quitte à utiliser les heures des événements pour développer plus de fonctionnalités.
  • Un Scrum Master qui est dans l’incapacité de balancer les forces externes à l’équipe (ou qui n’est pas prévu au budget ?) et qui ne peut pas reveler les dysfonctionnements dans l’application de Scrum. (Je rappelle qu’une équipe Scrum sans Scrum Master ne joue pas à Scrum, c’est comme jouer aux échecs avec un pion en moins). Voir cette vidéo pour approfondir le sujet.

Scrum est très peu prescriptif, c’est un cadre de travail très simple, avec des règles du jeu claires décrites dans le Scrum Guide. Si vous voulez délivrer un Produit ou Service complexe de manière empirique vous devez jouer selon les règles Scrum, sinon changez le nom du jeu.

La Sprint Retrospective est un des cinq événements Scrum, elle est obligatoire et toute la Scrum Team doit y participer !

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.