En 1995, Ken Schwaber et Jeff Sutherland présentent Scrum lors de la conférence OOPSLA, un événement dédié aux langages de programmation orientés objet. Le cadre naît dans un contexte résolument logiciel. Trente ans plus tard, des équipes marketing, des départements RH et des cabinets de conseil l’utilisent quotidiennement. Cette trajectoire n’est pas le fruit du hasard: elle résulte d’une série de décisions éditoriales délibérées dans le Scrum Guide, le document de référence du cadre.
Sept révisions, une direction claire
Le Scrum Guide a connu sept versions entre 2010 et 2020. Chaque révision a progressivement élargi le champ d’application de Scrum en retirant les références spécifiques au développement logiciel.
En 2010, la première publication écrite formalise un cadre qui existait jusque-là sous forme orale. Les versions 2011 et 2013 apportent des ajustements structurels: le Sprint Planning, jusque-là découpé en deux parties distinctes, devient un seul événement. Le raffinement du Product Backlog (l’activité consistant à détailler et estimer les éléments du backlog) est introduit comme pratique continue plutôt que comme réunion formelle. Le Daily Scrum est recentré sur la progression vers le Sprint Goal au lieu d’un simple tour de table de statut.
La version 2016 marque un tournant culturel avec l’ajout des cinq valeurs Scrum: courage, focus, engagement, respect et ouverture. Loin d’un ajout cosmétique, cette formalisation traduit une prise de conscience explicite de Schwaber et Sutherland: la mécanique seule ne suffit pas et le cadre repose sur des comportements humains avant de reposer sur des processus.
2020: la rupture officielle avec le logiciel
La révision de 2020 est la plus significative. Le guide passe sous 13 pages et supprime systématiquement tout vocabulaire IT. Les termes “testing”, “system”, “design” et “requirement” disparaissent du document. La “Development Team” devient simplement les “Developers”, un terme choisi pour sa neutralité sectorielle plutôt que pour désigner des programmeurs.
Deux changements conceptuels méritent une attention particulière. Le premier est l’introduction du Product Goal, un objectif stratégique à long terme qui donne une direction au Product Backlog. Avant 2020, le cadre ne formalisait pas cette vision d’ensemble, ce qui laissait certaines équipes naviguer Sprint après Sprint sans cap clair. Le second est le passage de “self-organizing” à “self-managing”. La nuance est plus qu’un glissement sémantique: l’auto-organisation avait été interprétée par certaines équipes comme une permission d’éviter tout engagement envers les parties prenantes. L’auto-gestion implique que l’équipe décide du comment, mais reste pleinement responsable du quoi et du quand.
Le Scrum Guide 2020 introduit également trois engagements formels, un par artefact: le Product Goal pour le Product Backlog, le Sprint Goal pour le Sprint Backlog et la Definition of Done (la liste des critères qu’un élément doit satisfaire pour être considéré comme terminé) pour l’Increment. Cette structure clarifie ce que chaque artefact est censé produire, là où les versions précédentes laissaient davantage de place à l’ambiguïté.
Ce que ça change pour les équipes non-logicielles
Le retrait du vocabulaire IT n’est pas qu’un exercice de rédaction. Il traduit une réalité observée sur le terrain: des équipes dans des secteurs très éloignés du logiciel avaient déjà adopté Scrum avec succès, et le guide formel ne reflétait plus cette diversité d’usage.
Pour une équipe marketing qui gère des campagnes en Sprints de deux semaines, le Product Backlog contient des briefs créatifs et des calendriers de publication plutôt que des user stories. Le Sprint Review présente des résultats de campagne plutôt que des fonctionnalités logicielles. La mécanique est identique, seul le contenu change.
Cette universalité repose sur le fondement théorique de Scrum: l’empirisme, c’est-à-dire la prise de décision basée sur l’observation et l’expérimentation plutôt que sur la prédiction. Dans tout environnement complexe où les résultats sont incertains, le cycle inspection-adaptation de Scrum apporte une structure sans imposer de plan détaillé. Que l’on développe un logiciel, qu’on lance un produit physique ou qu’on réorganise un département, la logique reste la même: observer ce qui se passe réellement, puis ajuster.
Les limites de l’universalité
Le minimalisme du Scrum Guide 2020 est à la fois une force et un risque. En réduisant les prescriptions, le guide laisse plus de place à l’interprétation. Pour une équipe expérimentée, c’est une liberté bienvenue. Pour une organisation qui découvre Scrum, l’absence de recettes concrètes peut conduire à un déploiement superficiel où l’on adopte le vocabulaire (Sprints, Daily, Product Owner) sans intégrer la discipline sous-jacente.
Ken Schwaber lui-même, dans son billet Scrum @ 21, alertait dès 2017 sur ce risque: sans les cinq valeurs exercées activement, les équipes “gaspillent de l’argent et ratent des opportunités”. Le cadre est léger par conception, pas par complaisance. Les 13 pages du guide supposent que chaque équipe investira le temps nécessaire pour comprendre pourquoi les règles existent, pas seulement comment les appliquer.
Pour les praticiens qui envisagent Scrum en dehors de l’IT, la question pertinente n’est donc pas “est-ce que Scrum peut fonctionner dans mon contexte?” mais plutôt “est-ce que mon organisation est prête à jouer le jeu de la transparence et de l’empirisme que Scrum exige?”. L’historique des révisions du guide montre que les créateurs du cadre ont passé dix ans à affiner les garde-fous, preuve que la simplicité apparente de Scrum repose sur des fondations exigeantes.