Dessin de couverture : Etienne Appert
Dessins de l’intérieur : Patrice Courtiade et Etienne Appert

Toutes les marques citées dans cet ouvrage sont des marques déposées par leurs propriétaires respectifs.

© Dunod, 2010, 2022 pour la sixième édition

11 rue Paul Bert, 92240 Malakoff
www.dunod.com

ISBN : 978-2-10-083952-0

La lecture se poursuit sur le blog de l’auteur Scrum, agilité & rock’n roll (www.aubryconseil.com), avec les articles et livres référencés accessibles en un clic. Vous y trouverez aussi le making-off du livre, des dizaines d’articles apportant des compléments de lecture, des supports de conférence, des réflexions sur l’évolution de l’agilité et la possibilité d’échanger avec l’auteur.

Ce document numérique a été réalisé par PCA

DU MÊME AUTEUR

∙ L’Art de devenir une équipe agile, Claude Aubry, Étienne Appert, 2019, 176 pages.

SUR DES SUJETS PROCHES

∙ Kanban, l’approche en flux pour l’entreprise agile, Laurent Morisseau, Pablo Pernot, 2019, 276 pages.

∙ Le Story Mapping, visualisez vos user stories pour développer le bon produit, Jeff Patton, 2015, 264 pages.

∙ Refactoring, comment améliorer le code existant, Martin Fowler, 2019, 432 pages.

∙ Mettre en œuvre Devops, comment évoluer vers une DSI agile, Alain Sacquet, Christophe Rochefolle, 2021, 320 pages.

∙ L’approche Lean pour la transformation digitale, Yves Caseau, 2020, 240 pages.

PRÉFACE

Plusieurs années ont passé, une nouvelle édition de Scrum par Claude sort, et une nouvelle encore. Durant toutes ces années : Scrum ! Scrum outragé ! Scrum déformé ! Scrum martyrisé ! Mais Scrum toujours présent.

C’est la (pas si) nouvelle marotte, Scrum serait has been, obsolète, trop rigide, trop inadapté, trop grossier, trop réducteur. Et l’agile mort, incompris, vendu et j’en passe.

Il faut dire les créateurs eux-mêmes de Scrum, Ken Schwaber et Jeff Sutherland ont abandonné toutes résistances à l’argent facile et ont écrit dans leurs dernières communications une apologie de ce que les grandes multinationales demandent, une apologie qui va à l’encontre même des principes de Scrum. Les plus bienveillants d’entre nous expliquent qu’ils se sont juste mal exprimés. Nous savons cependant tous qu’ils sont hors-jeu.

Eh oui, Scrum s’impose aujourd’hui aux grandes multinationales et, contraintes de faire avec, elles usent de toutes leurs forces, de tous leurs tours pour le vider de sa substance, et n’avoir finalement qu’un effort d’affichage à réaliser.

Mais pourquoi vider Scrum de sa substance ?

Car aujourd’hui ces grandes entreprises historiques cherchent plus à protéger leurs intérêts, leurs parts de marchés, et leurs cadres préfèrent assurer la suite de leurs parcours de carrière que de prendre ce qui apparaît malheureusement comme un risque, de se lancer à la conquête de nouveaux domaines, nouveaux services, nouveaux produits. L’intention première de ces entreprises n’est pas d’être performante, mais de se sécuriser (au risque de découvrir trop tard qu’elles ne sont plus du tout performantes). Et Scrum change assez les règles du jeu pour ne pas apparaître comme sécurisant.

C’est sûr, les principes de Scrum se heurtent de plein fouet aux mécanismes de l’âge industriel qui a façonné nos pensées managériales depuis plus d’un siècle. Et si cette époque est révolue, la « mémoire du muscle », elle, persiste.

Scrum peut être passionnant, mais c’est d’abord pour beaucoup de personnes un lâcher-prise sur leurs habitudes, leurs convictions, sur cette culture de l’âge industriel, de la hiérarchie, de la chefferie qui vont avec. Espérons que les jeunes soient moins marqués que beaucoup d’entre nous, et qu’ils osent.

Lâcher-prise, cette perte de contrôle demande du courage ou d’être au pied du mur (et souvent dans ce cas il est trop tard). Ainsi, autant Scrum est devenu incontournable, autant la résistance s’est organisée pour le décrédibiliser et éviter cet effort, ce risque, quitte à se prendre le mur plus tard.

Le meilleur moyen de piéger Scrum ces dernières années a été de le singer, de le parodier. La meilleure façon de dire non a toujours été d’offrir un faux oui. Une des stratégies est de décider de ne prendre « que ce qui est bon pour nous ». Difficile quand on prône une approche émergente et adaptative d’expliquer que « non, vous ne pouvez pas prendre juste certains morceaux », on passerait pour fou à juste titre. Vous pouvez tout à fait prendre certains morceaux et les adapter à vous. Mais vous devez le faire avec la bonne intention : pas pour vous sécuriser et vider de sa substance l’approche, mais pour réellement adapter l’approche à vos besoins, à vous, et cette adaptation, cette sélection doit être en accord avec la philosophie de l’approche.

C’est souvent pour cela qu’on propose souvent de d’abord suivre à la lettre, pour intégrer la philosophie, pour ensuite être équipé pour vos adaptations futures.

Mais souvent l’intention n’est pas la bonne, il s’agit juste de mimer, de faire semblant, sans vraiment s’approprier Scrum pour contrôler et éviter de renverser ses valeurs, de faire cet effort de lâcher prise, de changer de territoire. Soit volontairement, soit aussi involontairement (plus par absence d’effort). Les gens copient les pratiques les plus visibles, les plus évidentes, et souvent les moins importantes d’après Pfeffer et Sutton qui fournissent une étude des pratiques managériales en 2006 (People copy the most visible, obvious, and frequently least important practices », Three Myths of Management, Pfeffer et Sutton).

Et donc fleurissent les appropriations de Scrum qui sont caduques, absurdes, inconsistantes. Elles deviennent majoritaires. Et ces entreprises, grosses, avec pignon sur rue, s’en enorgueillissent et ainsi pullule du Scrum frelaté. Et la vieille antienne revient : Scrum serait has been, obsolète, trop rigide, trop inadapté, trop grossier, trop réducteur. C’est ce que font la majorité des gens de Scrum !

On s’attache parfois à dire : j’en prends les « basiques ». Et là aussi il y a une incompréhension. Basique n’est pas le bon terme. Cela ramène à simpliste (et pas simple). Au lieu de ramener à fondateur, à fondation, à essentiel. Comprenez basique comme les simplistes apparences de l’approche, et fondation comme les bases essentielles. Les fondations sont connues de beaucoup (et sinon vous les découvrirez plus loin dans le livre). L’auto-organisation de l’équipe, son autonomie (les prises de décision relatives à l’équipe sont prises par l’équipe, incluant naturellement le « Product Owner » et le « Scrum Master »). La capacité à découper en petits morceaux autonomes, qui font sens par eux-mêmes de façon à pouvoir les valider, observer leur impact, et apprendre ou engranger régulièrement de la valeur. Prioriser la réalisation de ces éléments par la valeur dont on estime qu’ils sont porteurs. S’interroger régulièrement sur comment s’améliorer. En voilà des fondations. Il est dès lors aisé de vite observer les entreprises autour de nous : les équipes sont-elles maîtresses des décisions les concernant (tant qu’elles respectent le cadre qu’on leur donne), sont-elles auto-organisées, autonomes (dans ce cadre) ? Est-ce que l’on délivre des éléments faisant sens, priorisés par valeur, et est-ce que l’on mesure leur réel impact ? Est-ce que l’on essaye de s’adapter et de s’améliorer ?

La question la plus cruciale, ou du moins celle qui reflète beaucoup cette compréhension de l’approche est : où se prennent les décisions ? Par qui ? Quelles décisions ?

Vous savez ce qu’il se murmure : les entreprises qui font bien du scrum et de l’agile n’en parlent pas, leurs sujets c’est leur impact. Celles qui s’emploient à mimer Scrum et agile ne parlent que de cette mise en scène.

Je noircis à dessein le paysage, pour faire passer mon message.

Il y a bien de nombreuses entreprises, nouvelles et modernes, petites et grandes, françaises et internationales, qui se sont emparées à bon escient de scrum et agile. Elles ne le crient pas sur les toits. D’autant que pour elles, c’est un avantage concurrentiel décisif.

Ce que vous devriez rechercher dans le livre de Claude, notamment dans cette édition où je trouve que cela s’est étoffé, c’est cette glue philosophique, cette cohérence culturelle. Ce que j’exprimais dans la précédente préface c’est que si vous le viviez, vous le sauriez instantanément, car cela remue, cela demande un lâcher-prise. Comme toujours, tout ce qui s’exprime simplement demande beaucoup d’effort, à l’inverse de ce qui s’exprime de façon compliquée ne demande pas nécessairement d’effort. Monter un meuble IKEA c’est tout un manuel à suivre à la lettre, et cela se révèle finalement assez simple. Laisser une équipe s’auto-organiser c’est oser leur dire « débrouillez-vous », et cela se révèle beaucoup plus ardu à suivre, accompagner, manager.

Ainsi non, on ne prend pas uniquement ce qui nous intéresse dans Scrum, c’est trop simpliste. C’est possible de faire une sélection uniquement dans la mesure où vous gardez une cohérence dans l’approche, et/ou ces éléments sont assez importants pour vous apporter ce qu’ils sont censés délivrer.

Ainsi non, on ne prend pas le « basique » qui n’est bien souvent qu’un simulacre, mais on en prend les fondations qui vont nourrir tout le reste.

Ainsi non, Scrum n’est pas mort, loin de là (pas plus que agile).

« Avec le Covid on doit vraiment être agile », non c’était le cas depuis longtemps pour faire la différence. « Avec le Covid », c’est probablement le signe que vous n’avez plus le choix si vous ne voulez pas disparaître assez rapidement.

Merci, Claude, de ne pas lâcher.

Je dédie cette préface à Frank Taillandier qui fut un ami. Il me manque.

Pablo PERNOT
pablopernot.fr

AVANT-PROPOS

Quand j’ai écrit la cinquième édition en 2018, je pensais sincèrement que ce serait la dernière. En effet, publier cinq éditions successives en une dizaine d’années me paraissait déjà une belle réussite, au-delà des mes espérances. Et il me semblait qu’il n’y avait plus rien à ajouter sur Scrum.

Et pourtant si…

La première pensée à une nouvelle édition m’est venue quand j’ai écrit L’art de devenir une équipe agile en 2019. Même s’il s’agit d’un livre bien différent, je me suis dit que la façon de présenter, et aussi le vocabulaire, pourraient être repris dans le livre Scrum. C’est ainsi que dans cette édition vous trouverez des parties nouvelles (comme celle sur les boucles) et des mots nouveaux (comme rites).

Le deuxième déclic, que nous ne sommes pas prêts d’oublier, a eu lieu en 2020. Le confinement provoqué par la pandémie a provoqué un bouleversement dans le monde. Le télétravail total a bien sûr eu un impact sur les équipes Scrum. C’est pourquoi j’ai interviewé des acteurs du domaine pour intégrer leurs idées et leurs ressentis – contrastés – dans cette nouvelle édition. Elle sera lue par des coéquipiers qui ne seront pas toujours tout le temps en présentiel, comme on dit désormais.

Au printemps 2021, j’ai donc commencé l’édition 6. Elle aurait pu ne comporter que des modifications mineures si j’étais resté sur les deux déclencheurs évoqués. Mais écrire ce n’est pas définir le plan du livre au début et ensuite rédiger ce qui a été planifié. Comme pour l’agilité, de nouvelles idées émergent.

Le terreau était favorable à leur émergence :

J’ai beaucoup lu ; des livres et articles sur l’agilité mais aussi sur la sociologie et la philosophie qui montrent un foisonnement d’initiatives, réflexions et concepts dont certains m’ont inspiré, au point de les utiliser pour aider à comprendre Scrum. Cela apparait en particulier dans la première partie qui porte sur l’équipe et son écosystème.

J’ai constaté, comme Pablo le pointe dans sa préface, que Scrum était encore et toujours déformé, dévoyé, détourné ou carrément déshabillé ; je me suis dit que j’avais un dernier effort à faire pour contribuer à donner aux équipes plus de concepts et d’outils pour éviter le faux agile. Cela se retrouve notamment dans la partie 3, sur le prélude, c’est-à-dire l’art de bien commencer pour devenir une équipe Scrum.

Voilà donc une sixième édition largement remaniée par rapport à la cinquième (j’estime que les deux tiers du livre sont réécrits, pour avoir un ordre de grandeur). Vous y trouverez toujours les dessins de Patrice Courtiade, qui m’en a offert de nouveaux, le glossaire et le quiz, actualisés, et la préface de Pablo Pernot, mais totalement réécrite pour cette édition.

Patrice et Pablo, merci de me donner avec constance le résultat de votre talent.

J’évoquais les inspirations données par mes lectures. Je vais préciser : par mes lectures mais surtout par les discussions régulières à leur sujet avec Anthony Cassaigne et Jean-Pascal Boignard. Au-delà d’être les piliers du Klub de lecture Agile Toulouse, Anthony et JP sont mes complices pour les réflexions sur l’agilité radicale que nous menons ensemble — en coopérant — depuis mars 2020. Cette édition, dont ils sont les premiers relecteurs, leur doit beaucoup.

J’écris de façon très itérative, avec de nombreuses boucles de feedback. Dès que j’ai un texte que je considère comme lisible je le fais relire. Encore faut-il trouver des volontaires au bon moment pour cela. Je sais l’effort que cela représente.

Pour cette sixième édition, je souhaitais des relectrices et relecteurs différents des éditions précédentes. J’ai eu la chance d’en trouver de très divers, avec une pensée critique affutée, au moment opportun dans ma construction du livre. Certains ont lu des versions très préliminaires, d’autres plus avancées. Certains ont lu une partie, d’autres ont tout lu. Beaucoup m’ont fait des suggestions, notamment sur Scrum en télétravail ; la diversité des expériences et des opinions m’a amené à évoluer vers du modérantisme sur le sujet.

Je remercie du fond du cœur, pour le feedback qu’ils et elles m’ont donné et qui m’a été précieux :

Rachel Jolin Dubois,

Morgane Eckert,

Aurélie Le Guillou,

Kervin Kuerney,

Grégory Plot,

Sébastien Conilleau,

Souad Hadjiat,

Alexandre Thibaut,

Benjamin Cabanne,

Axel Aguilar,

Riadh Layouni.

Les dernières boucles, je les déroule avec mon feedback et celui de mon éditeur. Jean-Luc Blanc m’a fait confiance depuis l’édition 1, il a toute ma gratitude.

Claude AUBRY
CASTANET-TOLOSAN, le 10 octobre 2021.

1

Scrum, un outil de l’agilité

En 1996, j’étais consultant en génie logiciel. Twitter n’existait pas encore, alors pour faire de la veille technologique, je recherchais les comptes rendus des conférences de l’époque, souvent des mois après l’événement. La tendance d’alors n’était pas l’agilité, c’était l’OO (l’orienté objet). Parmi les nombreuses conférences sur le sujet, il y avait OOPSLA (Object-Oriented Programming, Systems, Languages & Applications). C’est en parcourant les Proceedings de 1995 que je suis tombé pour la première fois sur Scrum. Signé de Ken Schwaber, un article présentait Scrum comme un processus empirique pour le développement de produits complexes.

À sa lecture, je l’ai perçu comme un OVNI dans le paysage du génie logiciel. Bien que l’article fasse beaucoup de références à l’orienté objet (probablement pour être retenu à la conférence…), c’était en rupture avec l’état d’esprit de l’époque.

Mes centres d’intérêt étaient l’architecture de logiciel et la modélisation, un peu moins les process. Cependant j’avais apprécié l’insistance sur l’équipe, et la référence au rugby m’avait attiré. Les idées développées m’avaient intrigué, notamment l’approche empirique à l’opposé de l’industrialisation alors recherchée – mais qui personnellement ne me convenait pas – pour l’appliquer à l’ingénierie du logiciel.

J’étais loin d’imaginer que 25 ans plus tard Scrum serait largement utilisé – et vivant – au point que ce livre fasse l’objet d’une 6e édition.

Avant de nous intéresser en détail à ce que Scrum est devenu aujourd’hui, voyons rapidement de quoi il s’agit.

1.1 SCRUM EST UN OUTIL

1.1.1 Un outil léger

Dans l’article de 1995, Schwaber parlait volontiers de processus et de méthodologie. Par la suite, Scrum a été le plus souvent qualifié de méthode : la méthode agile Scrum.

Bien plus tard Ken Schwaber et Jeff Sutherland, l’autre co-fondateur, ont défini Scrum comme un cadre de processus (process framework). Un cadre, on devine que ce n’est pas un processus complet, ni une méthode et encore moins une méthodologie, mais cela reste difficile à cerner.

Aujourd’hui, je préfère qualifier Scrum d’outil.

Un processus définit une façon de travailler, un outil se contente de rendre la vie plus facile. Un outil, auquel on peut adjoindre le qualificatif de léger, Scrum n’imposant que – relativement aux processus lourds – peu de choses.

1.1.2 Un outil d’équipe

Scrum est donc un outil, dédié au travail en équipe. L’équipe représente le niveau idéal pour coopérer et produire des résultats. Le but de son travail est un résultat destiné à des personnes appelées parties prenantes.

1.1.3 Un outil dont le nom vient d’un jeu

Scrum n’est pas un acronyme. Le mot Scrum vient du rugby : il désigne en anglais la mêlée. C’est pourquoi on n’écrit pas SCRUM. C’est pourquoi on prononce « screum », et non « scrume » ni « scroum ». Il suffit de regarder un match de rugby avec un arbitre anglophone pour l’entendre.

Figure 1.1 – La mêlée.

Au rugby, une mêlée est sifflée par l’arbitre quand une règle n’a pas été respectée (les règles changent souvent, notamment celles concernant la mêlée, c’est ce qui fait le charme du rugby).

La mêlée permet de repartir sur des bases solides, avec une poussée synchronisée de tout le pack. C’est la quintessence de l’effort collectif.

Les fondateurs de Scrum ont choisi cette métaphore, en ajoutant une majuscule pour différencier de la mêlée du rugby.

♦ Pourquoi cette référence au rugby ?

Elle provient d’un article de 19861, rédigé par des Japonais, qui aiment le rugby. Il montre comment des sociétés (Honda, Canon, NEC et Fuji-Xerox) sont performantes avec une approche de co-construction pour le développement de leurs produits, en insistant sur l’importance d’équipes autonomes et autogérées. Les auteurs présentent la métaphore du rugby ainsi :

L’approche séquentielle traditionnelle, autrement appelée « course de relais », pour développer un produit – illustrée par le système de planification de programme en phases – peut entrer en conflit avec les objectifs de vitesse et souplesse maximum. Au lieu de cela, une approche globale comme au rugby – où une équipe essaye de parcourir la distance en étant solidaire, se passant le ballon de main en main – peut mieux servir les exigences de compétitivité.

Ce lien fort avec le rugby, qui est d’abord un jeu, explique la dimension ludique que possède l’outil Scrum.

Comme le dit Ian Bogost2 :

Jouer, c’est composer avec la réalité : repérer les véritables contraintes du système dans lequel on évolue et les négocier positivement.

C’est pour mettre dans ces dispositions qu’avec Scrum, la mise en scène, l’ambiance dans l’équipe et l’état d’esprit des parties prenantes sont pris au sérieux.

1.1.4 Un outil avec un mode d’emploi et une intention

S’il n’est pas si facile de catégoriser Scrum, il est plus simple d’en expliquer la mécanique de mise en œuvre. Voici comment ça fonctionne :

Le rythme est donné par une série de boucles de feedback, appelées sprints.

Toutes les choses à réaliser sont ordonnées dans le backlog. L’équipe travaille sur la partie du backlog la plus prioritaire. Ce flux de travail est entrecoupé par la cadence régulière des rites du sprint :

au début du sprint, la planification consiste à se mettre d’accord sur un objectif, et à préparer le travail pour y arriver ;

chaque jour, la mêlée est un point de synchronisation, en équipe, pour converger vers l’atteinte de l’objectif ;

à la fin du sprint, lors de la revue, l’équipe présente le résultat qu’elle a obtenu, afin de solliciter du feedback qui va alimenter le backlog ;

enfin, lors de la rétrospective, l’équipe réfléchit à sa façon de travailler en vue de s’améliorer.

Et c’est reparti dans le sprint suivant.

Ce mode d’emploi décrit l’approche empirique de Scrum. Cette mécanique bien huilée qui paraît simple est indissociable d’une intention, celle de la nouvelle philosophie du travail véhiculée par l’agilité.

1.2 SCRUM EST AGILE

1.2.1 Le Manifeste agile

Le terme « agile » est apparu dans le domaine du logiciel avec le Manifeste pour les pratiques de développement agile.

Publié au début de l’année 2001 et inchangé depuis, ce manifeste définit une posture par rapport à des processus lourds et bureaucratiques, en vogue à l’époque (et parfois encore aujourd’hui).

Figure 1.2 – Le manifeste.

Le Manifeste agile représentait à sa publication3 une réaction radicale à la tendance dominante de l’époque, pour promouvoir des processus plus légers.

On peut noter dans les premiers mots « En pratiquant et en aidant les autres… » une référence à la coopération qui est au cœur de l’équipe Scrum.

Scrum se range sous la bannière du Manifeste agile. Ses deux fondateurs font partie des dix-sept signataires.

Le Manifeste définit des valeurs et des principes qui sont universels, mais la façon de les mettre en œuvre sur des projets varie. Cette application se fait par l’intermédiaire de ce qu’on appelle les pratiques. Scrum impose quelques pratiques bien définies, que nous détaillerons dans la suite du livre. Cependant, dans le grand corpus de l’agilité, on trouve bien d’autres pratiques, d’origine différente, qu’on peut aussi utiliser conjointement à Scrum.

1.2.2 Les pratiques agiles

Une pratique est une approche concrète et éprouvée qui permet de résoudre un ou plusieurs problèmes courants ou d’améliorer la façon de travailler lors d’un développement.

Des pratiques maintenant qualifiées d’agiles existaient avant le Manifeste agile et, pour certaines, depuis bien plus longtemps.

Par exemple, depuis le début des années 1980, la communauté du génie logiciel recommande de faire des cycles de développement courts (ce qu’on appelle le développement itératif).

D’autres pratiques sont apparues avec le mouvement agile et sont devenues indiscutables, après avoir été éprouvées sur de nombreux projets, par exemple la tenue d’une réunion quotidienne (la mêlée).

Prises individuellement, les pratiques sont efficaces, et insérées dans le cadre cohérent d’une approche agile, elles se renforcent mutuellement. C’est le cas dans Scrum, dont le cadre est composé d’une dizaine de pratiques majeures et en induit d’autres. C’est pourquoi Scrum est souvent qualifié de « méthode agile », comme on pouvait le lire dans le sous-titre des premières éditions de ce livre !

1.2.3 Les méthodes agiles

Scrum et Extreme Programming (XP) existaient avant le Manifeste. Dès sa publication, on les considéra comme des méthodes agiles, comme d’autres maintenant abandonnées. Kanban fait aussi partie du lot de celles qui comptent.

L’engouement pour Scrum (la Scrum mania !) a mis fin à une hypothétique rivalité entre les méthodes agiles. Les études d’opinion et les tendances des recherches sur le web le montrent : Scrum est de loin la plus populaire.

Figure 1.3 – Être agile avec méthode.

1.2.4 Scrum, la marque de l’agilité

Dans les enquêtes, les trois quarts des répondants disent utiliser Scrum ou des variantes. Au point que Scrum et Agile soient des mots qu’on utilise l’un pour l’autre ou qu’on accole : des offres d’emploi ou des articles parlent d’Agile Scrum.

Scrum est en quelque sorte devenu la marque de l’agilité. Ses rites, ses signes distinctifs et les nombreux retours d’expérience en ont fait l’outil qui incarne l’agilité aux yeux de beaucoup.

Bien sûr, cette place prépondérante de Scrum ne va pas durer éternellement. Elle n’est pas non plus sans provoquer des critiques quant aux responsabilités de Scrum dans les échecs de l’agilité, voire dans le faux-agile.

1.3 SCRUM EST ADAPTÉ AU TRAVAIL DE LA CONNAISSANCE

Scrum n’est pas la solution à tous les problèmes qu’on rencontre. C’est d’abord un outil pour une équipe qui travaille. La nature du travail importe : Scrum, c’est fait pour le travail de la connaissance4.

On le distingue du travail dit industriel basé sur le taylorisme et ses avatars, par ses boucles de feedback rapide qui permettent d’acquérir de la connaissance en validant des hypothèses et en apprenant des retours.

L’agilité est une philosophie du travail adaptée au domaine de la connaissance ; Scrum en est le fer de lance.

Le travail de la connaissance s’identifie avec les cinq critères ci-dessous :

Figure 1.4 – Le travail de la connaissance.

1.3.1 Besoins évolutifs

À la différence des problèmes dont tous les paramètres sont connus au départ, dont la spécification détaillée peut être élaborée très tôt et rester stable, les travaux du domaine de la connaissance portent sur des besoins qui évoluent ; certains ne sont pas connus au départ, mais vont émerger progressivement.

1.3.2 Problème complexe

On rencontre des gens qui pensent que l’agilité et Scrum sont faits pour des problèmes simples. Il n’en est rien, et la crise sanitaire a montré que la complexité ne se traitait pas avec les méthodes traditionnelles de l’industrie.

Scrum est un outil pour attaquer la complexité des systèmes grâce aux boucles permettant de tester rapidement des hypothèses.

Si vous développez des applications simples qui n’ont que des relations de causalité linéaires, Scrum n’est peut-être pas le meilleur choix.

La complexité est quasiment toujours présente dans le développement de services numériques, du fait des nombreuses interactions avec les utilisateurs et des solutions techniques.

1.3.3 Intangible

Le travail de la connaissance porte sur des objets intangibles (immatériels), alors que le travail industriel produit des objets physiques.

Le travail de la connaissance est très présent dans l’industrie, par exemple pour automatiser des process qui contrôlent la production d’objets tangibles.

1.3.4 Solution nouvelle

L’industrialisation a pour objectif de reproduire des solutions connues. On a essayé de l’imposer à tout en définissant des processus qu’on demande aux gens d’appliquer.

Cela ne fonctionne pas pour le travail de la connaissance qui est à chaque fois nouveau. On ne répète pas, on invente à chaque fois.

Il faut donc considérer une équipe comme le regroupement de « cerveaux d’œuvre » qui coopèrent et non pas comme de la main-d’œuvre qui exécute.

1.3.5 Décisions différées

La notion de projet industriel vient avec l’idée que l’on prend les décisions au début pour ensuite dérouler le plan. Dans le domaine de la connaissance, les incertitudes font qu’il serait dangereux de prendre des décisions importantes trop tôt. Elles sont différées jusqu’au moment opportun, celui où la connaissance de la situation le permet.

1.3.6 Capacité de changer radicalement

Si la nature de travail de votre équipe possède la majorité de ses critères, vous êtes dans le domaine de la connaissance et Scrum est donc adapté ; cependant il faut aussi vérifier une condition qui porte sur votre organisation.

Si celle-ci est clairement dans une culture du contrôle et que vous n’êtes pas en mesure de promouvoir le changement radical nécessaire, Scrum n’est pas pour vous tout de suite. Il vaut mieux attendre, ou – mieux – essayer ce qui est décrit dans la partie Prélude.

De même, si vous travaillez continuellement dans l’urgence et que vous n’avez pas la capacité de réduire les perturbations, vous n’arriverez pas à focaliser l’équipe sur un sprint sans qu’elle soit perturbée. Dans ce contexte d’urgence permanente, l’usage de Scrum n’est pas le plus recommandé. Kanban est probablement plus adapté, même si, comme nous le verrons plus loin, il est aussi possible d’utiliser Scrum avec Kanban.

1.4 DE QUEL SCRUM PARLONS-NOUS ?

Scrum est toujours vivant, la preuve c’est que j’écris cette sixième édition, plus de dix ans après la première.

La longévité de Scrum est exceptionnelle dans ce domaine du digital (l’informatique) où bien souvent une nouveauté chasse l’autre.

Comment se situe le Scrum dont je parle dans ce livre ?

Le Scrum de mon livre est loyal, indépendant, en français, élargi et se veut convivial comme le montreront les paragraphes qui suivent.

1.4.1 Un Scrum loyal vis-à-vis de la référence

Pendant longtemps, il n’y a pas eu de référence pour Scrum. Après l’article de Schwaber de 1996, il y a eu quelques livres, de nombreux articles mais aucun n’a atteint le statut de référence.

La création de la Scrum Alliance vers 2005 a fourni des éléments de présentation, mais son objectif était surtout la mise en place d’un système de certification lucratif (qui a bien fonctionné).

Entre 2005 et 2010, Mike Cohn a, par ses écrits et sa fameuse présentation distribuable sous licence Creative Commons, fortement contribué à la diffusion de Scrum.

C’est finalement en 2010 que Schwaber (qui avait quitté la Scrum Alliance avec fracas) et Sutherland ont publié la première version du Guide Scrum.

J’ai donc écrit la première version de ce livre Scrum avant que le Guide Scrum n’existe.

♦ Le guide Scrum

Le Guide Scrum est un petit document d’une vingtaine de pages. Il est écrit par les fondateurs de Scrum qui le présentent comme le guide officiel : official Scrum Body of Knowledge.

Depuis sa première parution en 2010, il a fait l’objet de mises à jour en 2011, 2013, 2016, 2017 et 2020. La dernière version, que ses auteurs ont voulue simple, comporte seulement treize pages.

♦ Ma position par rapport au guide Scrum

Dès 2006, j’avais traduit en français la présentation Scrum de Mike Cohn5.

Quand le guide Scrum est sorti, j’ai naturellement participé au travail collectif de traduction des premières versions. J’ai ensuite suivi et commenté les évolutions entre les versions successives.

Je considère le guide Scrum comme la référence. Cependant je ne le tiens pas pour le dogme absolu (ce qu’il ne cherche pas à être) et prends quelques libertés avec :

la première raison est que j’écris en français alors que le guide est en anglais. La traduction est un art difficile, le sens des mots n’est pas équivalent d’une langue à l’autre. J’ai réalisé de nombreuses traductions et je revendique le droit, pour mon livre, d’utiliser les mots qui me paraissent les plus adaptés6 ;

la deuxième raison porte sur des différences de point de vue. Le guide est focalisé sur Scrum et ne parle que de ça, tandis que j’aborde l’usage de Scrum bien plus en détail dans des contextes variés, en incorporant de nombreuses notions non Scrum ;

enfin, j’ai quelques divergences sémantiques, en particulier sur ce qui a été ajouté dans la dernière version. Je ne manquerai pas de préciser le moment venu ce qui nous sépare.

1.4.2 Un Scrum indépendant

Certains estiment que si Scrum s’est diffusé aussi largement, c’est grâce au mécanisme de certification mis en place par la Scrum Alliance. Je n’en suis pas sûr. Cependant il est indéniable que les certifications ont une place importante dans la formation à Scrum.

Je ne compte plus les personnes qui m’ont sollicité pour obtenir leur certification Scrum. Quand l’objectif premier n’est pas d’être bien formé mais d’être certifié, on est entré dans un système d’évaluation perverti.

Ce système est entretenu par les organismes de formation qui délivrent eux-mêmes leur propre certification, ce qui va à l’encontre de l’évaluation indépendante qui devrait en régir l’obtention.

Après la Scrum Alliance et sa certification CSM, Ken Schwaber a fondé Scrum.org qui a repris ce principe pyramidal en remplaçant le C de certifié par le P de professionnel, et en multipliant les offres pour chaque rôle et différents contextes. Alléchés par l’appât du gain, d’autres ont essayé de trouver leur place dans ce marché de la formation certifiante.

Il existe donc une offre pléthorique de certifications, qui ne se limitent pas à Scrum.

De nombreux formateurs et coachs Scrum font partie du système, ils en sont même dépendants, ce qui limite forcément leur esprit critique.

Si je désapprouve ce système de pseudo-certification, je suis plus indulgent avec celles et ceux qui, découvrant Scrum, y voient simplement une façon de valider leurs compétences.

Ils trouveront dans mon livre, en plus des connaissances sur Scrum leur permettant – s’ils y tiennent vraiment – d’obtenir leur certificat, de quoi développer leur esprit critique.

1.4.3 Un Scrum en français

La première rencontre que l’on a avec une nouvelle culture se fait avec les mots utilisés. Et Scrum utilise un vocabulaire particulier.

Pour vous aider à comprendre le sens des termes, j’ai ajouté un glossaire à la fin du livre. Beaucoup de mots nouveaux, qui sont arrivés en anglais. Dans sa diffusion en France, quelques-uns sont restés en anglais, d’autres ont été traduits.

Le vocabulaire a évolué en dix ans et continue de changer.

♦ Termes non traduits

Des mots de Scrum comme sprint et feedback sont dans le dictionnaire français depuis un bout de temps. C’est le même mot en anglais et en français.

Dans ce livre certains termes anglais du « Scrum/Agile » ne sont pas traduits. Cela ne veut pas dire qu’il n’y a pas eu de tentatives. Pour la plupart, des traductions ont été proposées mais n’ont finalement pas été retenues par les utilisateurs.

Dans cette liste, on trouve : backlog, story, Product Owner, Scrum Master, burndown. J’explique dans les chapitres concernés pourquoi j’ai choisi de ne pas les traduire.

♦ Termes traduits

D’autres termes Scrum sont utilisés dans leur traduction française. Pour certains, leur usage est important, mais, malheureusement de mon point de vue, n’est pas généralisé. Dans le langage courant, et parfois même dans des écrits, on trouvera : definition of done, daily scrum, sprint planning meeting, sprint review, timebox, impediment. Je défends vigoureusement l’usage du français, avec respectivement : définition de fini, mêlée quotidienne, réunion de planification du sprint, revue du sprint, boîte de temps, obstacle.

Parfois, on entend des locutions franglaises comme définition de ready ou test d’acceptance, au lieu de définition de prêt et test d’acceptation.

Le vocabulaire évolue avec des termes qui prennent plus d’importance et les retours du terrain.

Comme le français est une langue vivante, on peut penser que certains mots de Scrum seront bientôt adoptés, comme backlog.

1.4.4 Un Scrum élargi

C’est bien normal qu’en une quinzaine de pages le guide Scrum se concentre sur la mécanique du sprint, et ne puisse qu’effleurer les valeurs et les principes.

Mais cela peut amener à considérer Scrum davantage comme un processus (un cadre de processus, si on veut) que comme un outil appelant une nouvelle philosophie du travail. La nature radicale de Scrum – en particulier l’auto-organisation – peut être diluée dans l’application mécanique d’éléments de méthode.

Élargir Scrum, c’est se poser la question du commencement, tout ce qui concerne les conditions initiales pour rendre possible l’auto-organisation.

Élargir Scrum, c’est aussi se poser la question de la finalité, c’est-à-dire se préoccuper de ce qui sera réalisé, les produits ou services pour les utilisateurs. Considérer Scrum comme une technique neutre d’optimisation de travail en équipe n’est pas à la hauteur des enjeux actuels.

L’auto-organisation donne à réfléchir sur la façon de travailler ensemble ; il est temps d’élargir cette réflexion, et la quête de sens qui va avec, aux résultats du travail.

1.4.5 Faire de Scrum un outil convivial

Scrum est un outil d’équipe ; c’est à ce niveau que se conjuguent de façon optimale l’efficacité et l’autonomie avec la capacité donnée à chacun de façonner son propre avenir.

Le Scrum que je défends n’est pas un outil neutre, il est mis au service d’une intention, celle de peser sur les innovations en prenant en compte les aspects sociaux et les enjeux climatiques.

Pour finir cette introduction, reprenons la citation d’Ivan Illich pour l’appliquer à Scrum :

L’outil convivial est celui qui me laisse la plus grande latitude et le plus grand pouvoir de modifier le monde au gré de mon intention.

En résumé

Scrum est un outil destiné à faire coopérer une équipe afin qu’elle donne un résultat de valeur pour ses parties prenantes. Son nom vient du rugby, c’est la mêlée en anglais. Scrum est devenu en quelque sorte la marque de l’agilité, la philosophie du travail adaptée au domaine de la connaissance. Si Scrum est parfois victime de son succès et trahi, l’intention est qu’il soit un outil convivial.

1. L’article a été traduit : https://wikiagile.cesi.fr

2. Ian Bogost, Play Anything : The Pleasure of Limits, the Uses of Boredom, and the Secret of Games, Basic Books, 2016.

3. Traduit dans de nombreuses langues, il est disponible en ligne : http://agilemanifesto.org/iso/fr/manifesto.html.

4. La notion de travail de la connaissance (knowledge worker, à lire sur Wikipedia en anglais) vient initialement de Peter Drucker, un gourou du management.

5. Chercher sur un moteur : Reusable Scrum Presentation.

6. En lisant la dernière version française du guide Scrum, on découvre à la fin ce texte qui énonce des obligations que je ne respecte donc pas, heureusement pour mes lecteurs : « Conformément aux directives de Scrum.org, les termes suivants (Scrum, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Scrum Team, Scrum Master, Product Owner, Developer, Product Backlog, Sprint Backlog et Increment) ne doivent pas être traduits dans le document final.