L’Histoire de Scrum de 1995 à 2022

La première version officielle du Scrum Guide a été publiée en 2010 par Ken Schwaber et Jeff Sutherland. Plus que d’offrir des instructions précises et détaillées, ils envisageaient de rétablir la simplicité du framework Scrum. En effet, Scrum avait énormément évolué entre sa formalisation officielle en 1996 et 2010 et il était temps de remettre son fonctionnement au clair.

Ainsi, au travers de cet article nous allons voir comment Scrum a évolué au fil du temps en énumérant les jalons importants qui ponctuent son Histoire. Parce qu’une touche de conscience historique est plus qu’utile pour profondément comprendre Scrum et prendre soin de son avenir.

Ainsi, dans cet article, pour chaque chapitre, l’évolution de Scrum sera toujours illustrée de la même manière : A chaque fois, les trois mêmes sujets seront abordés :

Cette courte description sera agrémentée d’une représentation graphique et enfin je vous livrerai mes « réflexions » qui soulignent, à mon sens, ce qui était structurant.

1995 – “SCRUM Software Development Process”

Lors de l’événement OOPSLA ( pour “Object-Oriented Programming, Systems, Languages & Applications”) de 1995, Ken Schwaber présente Scrum su sein du workshop “Business Object Design and Implementation”  avec Jeff Sutherland.

A cette époque, Scrum était défini comme ceci :

1. Project Team = Management + Development Teams
2. Backlog (> Release/Enhancements > Packets > Changes > Problems > Risks > Solutions > Issues)
3. Pregame (planning + design) + Game (Development Sprints) + Postgame (closure)

Remarques et réflexions :

Bien que le document contienne le contenu codifié et présenté en 1995, il date en réalité de 1996.

Dans l’article “The New New Product Development Game” de Takeuchi et Nonaka, publié en 1986, on voit clairement apparaitre l’analogie du rugby : Comme dans une mêlée, en utilisant certains outils, toute l’équipe projet pousse le produit dans le même sens. Pierre De Grace et Leslie Hulet Stahl ont initialement suggéré d’appliquer les pratiques de cet article au développement logiciel dans leur livre « Wicked Problems, Righteous Solutions » (1990). James Coplien est reconnu pour avoir décrit le succès d’une méthode de travail Scrum (1994).

A cette époque, Scrum est décrit comme une méthodologie fondamentalement différent des approches existantes :

• Le management est dirigée par le product manager.
• Les « équipes de développement » sont petites, de trois à six personnes et interfonctionnelles.
• La phase « Sprints » sont basés sur l’empirisme.
•  La finalité du ou des livrable(s) des « Sprints » est laissée ouverte.

« Les sprints sont utilisés pour faire évoluer le produit final. […] Sprints itératifs, jusqu’à ce que le produit soit jugé prêt pour diffusion. »

1999 – “SCRUM: An extension pattern language for hyperproductive software development”

Les auteurs ( Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber and Jeff Sutherland ) élaborent et mettent en avant trois patterns Scrum :

• « Scrum Meeting » : une réunion quotidienne de 15 minutes (même heure et lieu) pour les membres de l’équipe.
• « Sprint » : un délai d’environ 30 jours pour créer un livrable visible et utilisable.
• « Backlog » : une liste vivante, dynamique, hiérarchisée et ordonnée des travaux à effectuer sur un produit.

A cette époque, certaines idées importantes sont introduites :

• « Scrum Master » : un rôle de chef d’équipe. Il aide les membres de l’équipe à résoudre les problèmes et corriger les choses qui les ralentissent.
• « Scrum Team » : une structure d’équipe auto-organisée pour produire un livrable utile au sein d’un Sprint, sans être dérangé par les demandes extérieures.
• « Demo » : une session à la fin de chaque Sprint pour montrer les nouvelles fonctionnalités et les réels progrès (réduction du backlog). Vient ensuite une “revue” pour discuter de l’avenir du produit.

Le document n’est pas explicite à ce sujet, mais la définition sous-jacente de Scrum est :

1. Scrum Master + Scrum Team
2. Backlog
3. Sprint + Scrum Meetings + Demo/review

Mes réflexions

Les idées suivantes émergent tout au long de la description des patterns précédemment mentionnés :

• Le backlog « global » se distingue du backlog de sprint, qui, lui, se décomposé en tâches.
• L’équipe sélectionne la partie du backlog qu’elle croit pouvoir terminer au sein du sprint et s’y engage.
• La sélection des travaux doit être cohérente avec l’objectif de sprint.
• Le livrable visible et utilisable démontré dans la démo s’appelle l’incrément.
• Le Product owner est mentionné comme « la seule personne capable de décider des priorités du backlog ».
• Trois questions doivent être abordées lors du scrum meeting : qu’ai-je terminé ? / que vais-je faire ? / Suis-je bloqué ?
  L’objectif général du daily scrum meeting est clairement décrit comme fournissant une solution adaptative.

Plusieurs des concepts, même sans utiliser leur dénomination finale, ont été reconnus comme de « significatives contributions » pour façonner Scrum dans ses cinq premiers années. Ce document a fondamentalement créé SCRUM comme le framework tel qu’on le connait aujourd’hui.

Au fait l’écriture du mot “SCRUM”  en majuscule a été plus tard abandonné. Ce n’est pas (et n’a jamais été) un acronyme.

2002 – “Agile Software Development with Scrum”

Deux signataires du Manifeste Agile ont écrit le tout premier livre sur Scrum.
En 2002, voici à quoi Scrum ressemblait :

1. Scrum Master + Product Owner + Scrum Team
2. Product Backlog (> Release Backlog) + Sprint Backlog + Product Increment
3. Sprint Planning + Sprint + Daily Scrum + Sprint Review

Mes réflexions

Les phases “Pregame” et “Postgame”, que vous pouviez observer en 1995 sont supprimés. Scrum ne parle plus que des Sprints.

Les six caractéristiques décrites dans l’article « The New New Product Development Game », à savoir, l’instabilité souhaitée et gérée, les équipes auto-organisées,  le chevauchement des phases de développement, l’apprentissage continu, le contrôle subtil et le transmission des apprentissages, sont référencées comme fondamentaux pour “la mise en œuvre correcte de Scrum ».
La taille d’équipe recommandée passe à sept personnes plus ou moins deux.

Les pratiques informelles ont maintenant été officiellement nommées,
tandis que d’autres sont renommés :

• “Product Owner” est ajouté en tant que rôle.
• Les blocages sont désormais appelés « Empêchements ».
• “Scrum Meeting” est remplacé par “Daily Scrum”.
• L’objectif d’un Sprint s’appelle désormais le “Sprint Goal » tout en ajoutant que le Sprint Backlog doit être défini pour atteindre l’objectif du sprint.
• « Démo» est remplacé par « Revue de sprint ».

L’arrêt anormal d’un Sprint est possible s’il n’est pas plus logique de continuer, même si annuler un Sprint « a rarement du sens ».
Scrum Master est décrit comme un nouveau rôle introduit par Scrum.

« En tant que Scrum Master, je suis souvent tenté d’aider une équipe dans la résolution de ses problèmes. L’expérience a m’a appris à ne pas le faire. […] tout est dans les mains des équipiers.”

2004 – “Agile Project Management with Scrum”

Après avoir contribué à lancer la Scrum Alliance et lancement de la formation « Certified Scrum Master », Ken Schwaber publie un deuxième livre sur Scrum. Il le présente alors de cette manière :

1. Product Owner + Équipe + ScrumMaster
2. Backlog de produit (< vision) + Backlog de sprint + Incrément (de la fonctionnalité du produit)
3. Planification de sprint + Sprint + Daily Scrum + Sprint Bilan + Rétrospective Sprint

Outre les modifications apportées à la définition de Scrum, ce deuxième livre contient de nombreuses études de cas.
Scrum y est représenté de cette manière :

Quelques réflexions

• Les trois volets du contrôle de processus empirique (alternative au contrôle de processus défini) sont appelés « visibilité» (pas encore transparence), « inspection » et « adaptation ».
• La vision, de laquelle nait le Product Backlog, est présentée comme le début du « Scrum Flow ».
• Le terme « artefacts » est introduit.
• La planification de sprint est formalisée tandis que “Rétrospective” est ajouté en tant qu’évènement timboxé.
• La planification de sprint comporte deux parties, la première partie se concentrant sur le Product Backlog (What) et une partie deux sur Sprint Backlog (Comment).
• L’engagement sur un Sprint est reformulé : L’équipe s’engage « à faire de son mieux ».

Le terme « ScrumMaster » est plus décrit pour souligner à quel point il est différent d’un chef de projet traditionnel. L’autorité d’un Scrum Master est décrite comme « largement indirect ».

2007 – “The Enterprise and Scrum”

Le troisième livre de Ken Schwaber aspire à décrire pourquoi et comment adopter Scrum, quels sont les défis de cette adoption et quel est l’impact attendu.

1. Product Owner + Team + ScrumMaster
2. Product Backlog (< vision) + Sprint Backlog + Increment (of Product Functionality)
3. Sprint Planning + Sprint + Daily Scrum + Sprint Review + Sprint Retrospective

Quelques réflexions

La vélocité apparait enfin comme le sens que nous lui donnons actuellement et non plus comme une mesure de la capacité de production d’une équipe.

2009, 2010 – “The Scrum Guide”

En mai 2009, alors qu’il était encore à la Scrum Alliance, Ken Schwaber crée un document appelé « ScrumGuide », une version préliminaire de ce qui devenir « le guide Scrum ».
La première version officielle est publiée en février 2010 avec Jeff Sutherland comme co-auteur. Entre-temps, Ken Schwaber a fondé Scrum.org.
La structure et le contenu des deux documents sont en grande partie identiques. Cependant, la version 2010 ajoute que Scrum Master est un « servant leader».

1. Scrum Team = ScrumMaster + Product Owner + Team
2. Release Planning + Sprint Planning + Sprint + Daily Scrum + Sprint Review + Sprint Retrospective
3. Product Backlog + Release Burndown + Sprint Backlog + Sprint Burndown

Mes observations :

• La première étape de l’empirisme est renommée “Transparence”.
• Seul le Product Owner est habilité à annuler un Sprint.
• Bien que “Incrément” ne soit pas encore défini comme un artefact, le but des Sprints est expliqué comme « transformez le Product Backlog en incréments de fonctionnalité potentiellement livrable ». Incréments
  doit adhérer à une définition de travail de « fait ».

2011, 2013, 2016, 2017 – “The Scrum Guide”

Dans toutes ces mises à jour du Scrum Guide, Scrum est
toujours défini comme cela :

1. Scrum Team = Product Owner + Development Team + Scrum Master
2. Sprint + Sprint Planning + Daily Scrum + Sprint Review + Sprint Retrospective
3. Product Backlog + Sprint Backlog + Increment

Le Scrum Guide n’a JAMAIS eu de visuel représentant Scrum.
La représentation suivante est tirée du livre « Software in 30 Days » des mêmes auteurs (2012).

Quelques réflexions

Bien que la définition de base de Scrum soit restée stable, ce qui suit a été changé tout au long de la différentes mises à jour du Scrum Guide :

• « Équipe » est renommée « Équipe de développement » avec
  une taille recommandée de trois à neuf personnes. (2011)
• “Incrément” devient le troisième artefact (2011) et « un pas vers une vision ou un objectif » (2016).
• « Expédiable » est renommé en « Libérable ». (2011)
• S’engager dans un Sprint est remplacé par faire une prévision pour un Sprint. (2011)
• Les burndown charts sont supprimés en tant que pratique. (2011)
• La métaphore des cochons et des poulets pour illustrer
  l’engagement et la responsabilité sont abandonnés. (2011)
• Le Product Backlog doit être « ordonné» au lieu de “priorisé”. (2011)
• “Product Backlog Grooming” est ajouté en tant que
  pratique (2011) mais est renommé « Raffinement du backlog » (2013).
• La planification de sprint est un événement avec quoi et comment comme deux sujets à discuter plutôt que de faire
  deux parties distinctes de l’événement. (2013)
• Les trois questions du Daily Scrum sont reformulé pour mettre l’accent sur l’équipe plutôt que sur l’individu (2013) et deviennent une option au lieu d’une pratique obligatoire (2017).
• Les valeurs Scrum sont ajoutées. (2016)

2020 – “The Scrum Guide”

La version 2020 du scrum guide est la dernière version disponible au moment de la publication de cet article. On y représente scrum comme :

1. Scrum Team = Product Owner + Developers + Scrum Master
2. Sprint + Sprint Planning + Daily Scrum + Sprint Review + Sprint Retrospective
3. Product Backlog (< Product Goal) + Sprint Backlog (< Sprint Goal) + Increment (=Done)

Bien que le Scrum  Guide n’ait toujours pas de visuel représentant Scrum, le seul changement notable par rapport à la représentation précédente est la confirmation explicite qu’un Sprint peut livrer plusieurs incréments… et qu’on peut biensur livrer plusieurs fois par sprint !

Mes remarques

• “Équipe de développement” est remplacé par “Développeurs”.
• L’équipe Scrum est censée être responsable de créer un incrément et sa taille est “de 10 ou moins de personnes ».
• « Libérable » est remplacé par « Utilisable ».
• Les trois questions en suggestion pour le daily Scrum sont complètement supprimées.
• La notion de Product Goal est introduite.
• On insiste plus sur la notion de Sprint Goal.
• La Definition of Done est l’engagement pour l’incrément.
• Le sujet “Pourquoi” est ajouté aux sujets “Quoi” et “comment” lors de la planification du sprint.
• « Rôle » est remplacé par « responsabilité ».
• « Auto-organisation » est remplacé par « autogestion ».

Et voila, c’est tout pour l’histoire de Scrum de 1986 à nos jours.
Vous pouvez télécharger le livre original directement ici :