Qu'est-ce que l'essence de Scrum · Scrum se fonde sur un jeu limité de valeurs, de principes et de pratiques (ce qui constitue le cadre Scrum). Une entreprise qui veut adopter Scrum

Préface

Ce livre est consacré aux principes essentiels de Scrum, c'est-à-dire les choses que vous devez connaître si vous voulez réussir dans l'adoption de Scrum pour créer des produits et des services innovants.

Qu'est-ce que l'essence de Scrum ?

Scrum se fonde sur un jeu limité de valeurs, de principes et de pratiques (ce qui constitue le cadre Scrum). Une entreprise qui veut adopter Scrum doit prendre en compte ce cadre Scrum dans sa totalité, mais peut-être pas dans toutes les équipes de l'entreprise à la fois. En tout cas, cela doit être le cas pour celles qui vont adopter Scrum en premier. Cette adhésion totale et entière aux principes Scrum ne signifie pas que les entreprises doivent mettre Scrum en mouvement à partir de formules génériques. Chaque entreprise doit rester fidèle aux principes Scrum en sélectionnant la combi-naison d'approches la plus appropriée.

Ce livre met en regard les valeurs, principes et pratiques Scrum avec toute une série d'approches éprouvées qui sont cohérentes avec le cadre Scrum, sans qu'aucune ne soit obligatoire. Certaines de ces approches conviendront à votre situation, et d'autres pas. Chaque approche doit être inspectée et adaptée pour vérifier son adéquation aux circonstances.

Origines de ce livre

En tant que formateur et coach Agile/Scrum, on me demande souvent de préconiser un livre de référence Scrum, un livre qui offrirait une présentation complète du cadre Scrum et des approches les plus usitées pour son application. Mais je n'ai trouvé aucun ouvrage abordant tous ces sujets de façon suffisamment détaillée pour qu'il soit vraiment utile dans la pratique. Je me suis vu conseiller une collection de livres. Certains présentent le cadre Scrum mais sont dépassés ou incomplets. Plusieurs livres très réputés dans le domaine Agile ne sont pas assez spécifiques à Scrum. Enfin, certains abordent un point particulier de Scrum ou une approche spécifique, mais ne couvrent pas en détail tout le cadre Scrum. Il en résulte une véritable bibliothèque alors que la question posée était de citer une ressource unique et indépendante présentant l'essence de Scrum !

Les inventeurs de Scrum que sont Jeff Sutherland et Ken Schwaber ont bien rédigé un document spécifique à Scrum intitulé Le Guide Scrum. Ce bref document d'environ quinze pages est présenté par ses auteurs comme le "Livre officiel des règles Scrum et de documentation" (Schwaber et Sutherland, 2011). Ils comparent leur document à la liste des règles d'un jeu d'échecs "en décrivant comment les pièces peuvent se déplacer, comment passer son tour, ce qu'est une victoire, etc.". Ce guide est effectivement utile pour une présentation de Scrum ou un rappel des règles, mais il n'a jamais été conçu

© 2013 Pearson France – SCRUM – Kenneth S. Rubin

XXX Scrum - Management de projet Agile

pour devenir une source de savoirs Scrum fondamentaux. En conservant l'analogie choisie par les auteurs, si vous ne donnez que le guide Scrum à une nouvelle équipe Scrum, c'est un peu comme si vous attendiez de bonnes performances d'un nouveau joueur d'échecs à partir des seules règles en quinze pages, en espérant qu'il atteigne un bon niveau après cette lecture. Ce n'est donc pas une ressource suffisante.

Ce livre constitue une tentative de procurer enfin la source unique des connaissances essentielles sur Scrum. Il contient une description détaillée des principes, des valeurs et des pratiques, qui sont dans la plupart des cas en ligne avec d'autres grands principes Agile et avec le guide Scrum. (Lorsque ce livre propose un autre point de vue que celui communément admis, je le souligne et m'en explique.) Les approches présentées dans le livre restent en cohérence avec le cadre Scrum et ont été effectivement appliquées avec succès par moi-même et par les équipes que j'ai conseillées. Je n'ai pas eu l'intention avec ce livre de remplacer d'autres ouvrages qui proposent une analyse plus verticale d'une pratique ou d'une approche Scrum en particulier. Ces autres livres viennent compléter et prolonger celui-ci. Considérez-le plutôt comme le point de départ d'un voyage dans l'univers de Scrum pour satisfaire encore mieux vos clients.

Lectorat visé

Les milliers de personnes qui ont assisté à mes formations abordant le travail en équipe Scrum et les certifications Scrum comme ScrumMaster et Product Owner, ainsi que les nombreuses équipes que j'ai conseillées, vont trouver en ce livre un rappel et peut-être une clarification de certains sujets que nous avons débattus ensemble. Quant au vaste monde des gens que je n'ai pas encore eu le plaisir de rencontrer, ce livre constituera une première approche de Scrum et d'Agile, ou bien l'occasion d'envisager Scrum sous un nouvel éclairage, avec peut-être la possibilité d'améliorer leur manière de l'utiliser.

Je n'ai pas rédigé ce livre en visant un rôle en particulier. Ce livre n'est pas consacré aux Product Owners, ni aux ScrumMasters, ni aux membres de l'équipe de développe-ment. Il est destiné à fournir à toute personne concernée par Scrum une compréhension commune de Scrum, aussi bien pour les membres des équipes Scrum que pour ceux qui doivent interagir avec les équipes Scrum dans une entreprise. Le livre se fonde sur un ensemble de concepts et cherche à employer un vocabulaire clair pour en discuter. Je souhaite qu'au moyen de ces fondations bien partagées, votre entreprise soit encore mieux placée pour utiliser Scrum avec succès dans le but de livrer de la valeur à ses clients.

J'imagine que chaque membre d'une équipe Scrum pourrait avoir un exemplaire du livre ouvert sur son bureau au chapitre correspondant au travail qu'il est en train de réaliser. J'imagine également que les managers à tous les niveaux d'une entreprise le liront pour comprendre comment Scrum peut constituer une approche efficace dans la gestion d'une production et pour connaître les changements à prévoir dans l'organisation afin de pouvoir utiliser Scrum de façon optimale. Les entreprises qui l'utilisent déjà ou prévoient de recourir à une approche Agile autre que Scrum y trouveront des infor-mations pertinentes et utiles, quelle que soit la manière dont elles adoptent l'approche Agile.


Préface XXXI

Structure du livre

Le livre s'ouvre par une courte introduction à Scrum (Chapitre 1) et se referme par une discussion des pistes que vous pouvez envisager pour la suite (Chapitre 23). Tous les chapitres intermédiaires ont été rassemblés en quatre parties :

■ Partie I, Concepts fondamentaux (Chapitres 2 à 8) : infrastructure de Scrum, prin-cipes Agile, les sprints, exigences et User Stories, Backlog de produit, estimations, vélocité et dette technique.

■ Partie II, Rôles (Chapitres 9 à 13) : Product Owner, ScrumMaster, équipe de déve-loppement, structure des équipes et les managers.

■ Parties III, Planification (Chapitres 14 à 18) : principes de planification Scrum, planification à plusieurs niveaux, planification de portefeuille, de produit (création de vision) et de release.

■ Partie IV, Sprints (Chapitres 19 à 22) : planification de sprint, exécution de sprint, revue de sprint et rétrospective de sprint.

Approches de lecture du livre

Comme vous pouvez vous y attendre, j'ai écrit ce livre en supposant que la majorité des lecteurs va le lire du début à la fin. Si vous découvrez Scrum, c'est l'approche que je vous recommande parce que les chapitres sont fondés les uns sur les autres en séquence. Ceci dit, si vous avez tout d'abord besoin d'une vision globale de l'infrastructure Scrum (une sorte de bréviaire visuel de Scrum), commencez par le Chapitre 2.

Ceux qui ont déjà une certaine connaissance de Scrum se serviront de ce livre comme d'une référence. Si vous êtes concerné par les rétrospectives de sprints, allez directe-ment au Chapitre 22. Si vous avez besoin d'en savoir plus sur les nuances au niveau du Backlog de produit, voyez le Chapitre 6. Je conseille cependant à tout le monde, même les connaisseurs de Scrum, de lire attentivement le Chapitre 3. Les principes qui y sont présentés constituent les bases de l'infrastructure Scrum et du reste du livre. Il ne s'agit pas simplement d'une reformulation des valeurs et principes du manifeste Agile (Beck et autres, 2001) que l'on retrouve dans de nombreuses autres descriptions de Scrum.

Les illustrations Visual AGILExicon

Je suis fier d'avoir pu introduire dans ce livre le langage Visual AGILExicon, un langage permettant de décrire et de communiquer les concepts fondamentaux Agile et Scrum sous une forme graphique attrayante et efficace. Cet outil a servi à créer les plus de deux cents illustrations de ce livre. Ce langage visuel se fonde sur un vocabulaire d'icônes conçues en sorte de bien illustrer les rôles, les artéfacts et les activités Scrum essentiels. C'est un moyen efficace de communiquer les concepts et donc de favoriser une compré-hension partagée de Scrum.


XXXII Scrum - Management de projet Agile

Si vous souhaitez réutiliser les images en couleurs de Visual AGILExicon (ce livre est imprimé en noir et blanc), visitez le site www.innolution.com qui offre toute une série de ressources et de discussions en rapport avec le livre.

L'heure est venue d'y aller

Quel que soit votre rôle ou votre situation, si vous avez ce livre entre les mains, c'est pour une bonne raison. Prenez un peu de temps pour découvrir Scrum. Dans les pages qui suivent, vous allez peut-être découvrir une approche puissante que vous pourrez vous approprier afin d'améliorer sensiblement la manière dont vous développez et livrez des produits et des services à la plus grande satisfaction de vos clients.

Adresses Web Scrum

Ces adresses ont été ajoutées dans la version française du livre.

■ http://www.scrumalliance.org/

■ http://www.frenchsug.org

■ http://www.aubryconseil.com/


1Introduction

Le 12 juin 2000, j'étais vice-président exécutif chez Genomica, une société de bio-infor-matique de Boulder, dans le Colorado. Je m'en souviens bien puisque c'est ce jour-là, à 1 heure du matin, qu'est né mon fils Asher.

Sa naissance a constitué un excellent début de journée. Asher est en effet né exactement le jour prévu (ce qui arrive dans 5 % des cas aux États-Unis). Nous avions donc (surtout ma femme Jenine) achevé notre "projet" de neuf mois dans les temps. Et pour couronner le tout, Asher nous a gratifiés d'un score d'Apgar très élevé, ce qui prouve que le résultat était de haute qualité ! Notre autre actionnaire principal, notre fils aîné Jonah, était enthousiasmé à l'idée d'avoir un petit frère. Livraison dans les délais d'un résultat de grande qualité et actionnaires heureux : c'était vraiment une belle journée !

Après une courte sieste, j'ai vérifié mes courriels et vu que le CEO de Genomica m'avait envoyé un message urgent dans lequel il me demandait d'être présent à une réunion de direction le jour même à 8 heures du matin. J'ai quitté l'hôpital de mauvaise grâce et me suis rendu à cette réunion.

En arrivant, j'ai appris que le vice-président Engineering avait été licencié la nuit précé-dente et que j'avais hérité de son équipe de 90 ingénieurs. Cela ne m'a pas surpris, car voilà plusieurs mois que la direction de Genomica s'inquiétait de l'incapacité de la société à livrer des produits dans les délais et avec une qualité suffisante. Le vice-président Engineering était au centre des débats.

J'étais dorénavant chargé de superviser les efforts à déployer pour améliorer sérieuse-ment les résultats de notre département de développement de produits. Je me souviens d'avoir été frappé par l'ironie de cette journée : une livraison réussie et la nouvelle responsabilité de mieux livrer des produits.

Mais j'étais déjà fort occupé avec ma supervision des ventes et du marketing. On m'a donc autorisé à embaucher un nouveau vice-président Engineering. J'ai choisi Mike Cohn (Cohn, 2004 ; Cohn, 2006 ; Cohn, 2010), et nous avons décidé d'adopter l'approche Scrum.


2 Scrum - Management de projet Agile

Qu'est-ce que Scrum ?

Scrum est une approche de type Agile pour développer des produits et des services innovants. La Figure 1.1 en schématise une version simplifiée et générique.

Fonction A

Backlog de produit

Fonction BFonction C

Fonction A

Planification itér

ative

Rev

ue ité

rative

Fonction B

Fonction C

Itération (de une semaine à un mois calendaire)

Figure 1.1Vue générale du développement Agile.

Dans l'approche Agile, vous commencez par établir un Backlog de produit (un carnet de travaux), c'est-à-dire une liste priorisée des fonctions et capacités requises pour réaliser le développement d'un produit réussi. Vous vous servez de ce Backlog de produit pour travailler en priorité sur les éléments les plus importants, ceux ayant la plus grande priorité. Lorsque vous tombez à court de ressources (de temps, par exemple), tout ce qui n'a pas eu le temps d'être réalisé sera nécessairement moins prioritaire que ce qui a pu l'être.

Les tâches correspondent à des itérations clairement limitées dans le temps et d'une durée unitaire comprise entre une semaine et un mois calendaire. Tout le travail de chaque tâche (conception, construction et tests) est effectué par une équipe restreinte, auto-organisée et multifonctionnelle, suffisante pour réaliser des fonctions complètes pouvant être exploitées telles quelles.

En général, le volume de travail que représente le Backlog de produit est largement supérieur à ce que peut réaliser une équipe en une seule itération dont la durée est par définition assez courte. En début d'itération, l'équipe sélectionne dans le Backlog le sous-ensemble d'éléments ayant la plus haute priorité pour alimenter la prochaine itéra-tion. La Figure 1.1 montre par exemple que l'équipe a décidé qu'elle était en mesure de produire les fonctions A, B et C.


Introduction 3Chapitre 1

Arrivée en fin d'une itération, l'équipe évalue les fonctions réalisées avec les parties prenantes afin d'obtenir leur avis. Le Product Owner et l'équipe peuvent ensuite se fonder sur cet avis pour modifier l'ordre des prochaines tâches et la façon dont l'équipe doit planifier la suite des travaux. Si par exemple les parties prenantes constatent qu'une fonction a bien été réalisée mais qu'une autre fonction encore jamais considérée doive absolument être intégrée, le Product Owner peut créer une nouvelle entrée dans le Backlog de produit à l'endroit le plus approprié pour la faire prendre en compte dans une prochaine itération.

En fin de chaque itération, l'équipe doit avoir réalisé un produit (ou une mise à jour du produit) dans un état potentiellement livrable, c'est-à-dire qu'il devra pouvoir être livré si cette décision apparaît pertinente. Lorsque ce n'est pas le cas, l'état potentiellement livrable doit pouvoir être atteint à partir du regroupement des fonctions produites par plusieurs itérations.

Une fois qu'une itération est terminée, l'ensemble du processus est relancé en commen-çant par la planification de la prochaine itération.

Origines de Scrum

La riche histoire de Scrum remonte à l'année 1986 avec un article du magazine Harvard Business Review intitulé "The New New Product Development Game" (Takeuchi et Nonaka, 1986). Cet article s'intéressait à la façon dont des entreprises telles que Honda, Canon et Fuji-Xerox parvenaient à produire des résultats de classe mondiale à partir d'une approche basée sur des équipes à géométrie variable avec un développement de produit en tâches parallèles (all-at-once). L'étude soulignait l'importance des équipes auto-régulées et responsabilisées et le rôle du management dans le processus de déve-loppement.

Cet article fondateur de 1986 a joué un grand rôle dans la consolidation de plusieurs des concepts qui sont à l'origine de Scrum. Notez que Scrum n'est pas (une fois n'est pas coutume) un acronyme, mais un terme emprunté au monde du rugby. C'est le terme anglais pour la mêlée qui consiste à faire s'opposer deux groupes de joueurs pour remettre le ballon en jeu suite à une faute ou une sortie de jeu. Même si vous n'êtes pas fanatique de rugby, vous avez sans doute déjà vu ce genre de regroupement de forces, bras dessus, bras dessous, tête baissée, cherchant à reprendre possession du ballon jeté entre leurs jambes.

Takeuchi et Nonaka se sont emparés des métaphores du rugby et de la mêlée pour décrire le cycle de développement d'un produit :

L'approche classique de type "course de relais" appliquée au développement de produit (...) peut entrer en conflit avec les objectifs de vitesse et de souplesse maxi-males. Au lieu de cela, l'approche globale, holistique, ou approche "rugby", dans laquelle une équipe cherche à rester unie tout au long du processus, en faisant des passes de balles en avant et en arrière, peut mieux convenir aux attentes actuelles en termes de compétitivité.



En 1993, Jeff Sutherland et son équipe chez Easel Corporation ont développé le processus Scrum dans l'optique du développement de logiciels en combinant les concepts de l'article de 1986 avec ceux issus de plusieurs autres domaines : développement en programmation orientée objets, contrôle empirique de processus, approches de dévelop-pement itérative et incrémentale (progressive), recherches en processus logiciels et en productivité et, enfin, systèmes adaptatifs complexes. En 1995, Ken Schwaber a publié le premier article présentant Scrum lors de la conférence OOPSLA 1995 (Schwaber, 1995). Depuis lors, Schwaber et Sutherland, soit ensemble, soit indépendamment, ont publié plusieurs livres consacrés à Scrum, parmi lesquels Agile Software Development with Scrum (Schwaber and Beedle, 2001), Agile Project Management with Scrum (Schwaber, 2004) et The Scrum Guide (Schwaber and Sutherland, 2011).

L'approche Scrum est d'abord utilisée pour produire des logiciels, mais ses concepts et principes peuvent et sont exploités pour d'autres catégories de produits ou pour organiser les flux dans divers types de travaux. J'ai par exemple collaboré avec des organisations qui ont employé Scrum de façon profitable pour gérer et structurer le développement de matériels informatiques, de campagnes de marketing et d'opérations commerciales.

Pourquoi Scrum ?

En quoi une approche de type Agile telle que Scrum a t-elle constitué un choix pertinent pour la société Genomica ? Au départ, il a bien fallu constater que l'ancienne approche de développement de Genomica n'était pas fonctionnelle. C'était la mauvaise nouvelle, mais la bonne était que quasiment tout le monde était d'accord sur ce point.

Le domaine d'activité de Genomica était complexe, avec une part d'inconnu plus grande que la part de connu. Nous devions créer des produits réellement nouveaux, sans précédents. L'objectif était de produire des plates-formes informatiques capables d'une évolution permanente, toujours à la pointe de la technologie afin d'offrir aux chercheurs les outils avec lesquels ils pourraient découvrir la prochaine molécule chimique à fort potentiel commercial. Il nous fallait trouver une approche de développement permettant d'explorer rapidement de nouvelles idées et de faire vite le tri entre les solutions viables et les autres. Notre partenaire stratégique devait être maintenu informé de l'avancement de nos travaux toutes les trois à cinq semaines, parce que notre produit devait pouvoir s'intégrer à sa ligne de matériels de séquençage d'ADN. Cette contrainte d'exploration et d'évaluation rapide se mariait mal avec la planification détaillée préalable que nous pratiquions.

Nous voulions aussi éviter de devoir figer dès le départ les choix d'architecture fonda-mentaux. Lors d'un précédent projet de création de la prochaine génération de produits d'infrastructure de Genomica, l'entreprise avait consacré quasiment une année entière à travailler sur l'architecture en vue d'obtenir une vaste plate-forme de bio-informatique unifiée. Mais le jour où la première application utilisateur destinée aux scientifiques a été mise en place dans cette architecture, il nous a fallu valider des choix de conception faits bien des mois auparavant. Résultat : il fallait par exemple 42 secondes pour passer d'un champ de saisie au suivant par la touche Tab ! Si vous considérez qu'un utilisa-teur lambda est par nature impatient, imaginez la réaction d'un docteur en biologie moléculaire quand vous lui faites gaspiller 42 secondes de son temps précieux et de sa



concentration ! C'était un beau désastre. Il nous fallait trouver une autre approche de conception, plus équilibrée, combinant un minimum de conception initiale et une bonne dose de conception au fil de l'eau.

Nous voulions en outre que nos équipes soient plus polyvalentes. De par son histoire, la société Genomica était structurée comme la plupart des entreprises. L'équipe de développement transmettait son travail à l'équipe de test seulement quand elle avait totalement terminé le développement. Dorénavant, nous voulions que tous les membres du projet aient de fréquentes opportunités de resynchronisation, si possible au quotidien. Dans le passé, les erreurs s'accumulaient car les points fondamentaux n'étaient débattus que trop tard dans le cycle de développement. Les gens des différents domaines ne communiquaient pas assez souvent.

C'est pour ces raisons, entre autres, que nous avons décidé que l'approche Scrum serait appropriée aux besoins de Genomica.

Résultats chez Genomica

Lorsque nous avons choisi d'adopter Scrum, cette approche n'était pas encore bien connue. Le premier livre au sujet de Scrum n'allait apparaître qu'un an plus tard (Schwaber and Beedle, 2001). Nous avions alors choisi de réunir toutes les informations disponibles et de faire au mieux avec, et les résultats ont été sensiblement meilleurs qu'auparavant (voir Tableau 1.1).

Tableau 1.1 : Résultats Scrum chez Genomica

Mesure Cascade Scrum

Effort 10x 1x

Rapidité 1x 7x

Satisfaction client Faible Excellente

En termes d'efforts, le développement Scrum nous a demandé dix fois moins (en nombre d'hommes/mois) que nos expériences précédentes en approche planifiée en cascade pour le même volume fonctionnel à produire. Non moins important, la rapidité de progression avec Scrum s'est avérée sept fois supérieure à celle de l'approche en cascade ; autrement dit, dans le même laps de temps, le développement Scrum permettait de produire sept fois plus de fonctions que le développement en cascade. Enfin, nous avons pu livrer le logiciel à notre partenaire en respectant les délais qui lui ont permis de lancer sa nouvelle plate-forme matérielle. Cela a renforcé notre partenariat à long terme et donc augmenté sensiblement la valeur actionnariale de l'entreprise Genomica.

Est-ce que Scrum peut vous aider ?

Le vécu de Genomica avant l'adoption de Scrum (produire des fonctions dont personne n'avait plus besoin et les livrer avec des défauts et hors délais) n'est pas si rare. Comme



bien d'autres entreprises, Genomica y a survécu simplement en n'étant pas pire que ses concurrentes. J'ai constaté les mêmes problèmes dès que j'ai commencé à travailler dans le secteur du développement de logiciels au milieu des années 1980. Dans la plupart des cas, trente années n'ont pas suffi à améliorer la situation.

Supposez que vous réunissiez vos commerciaux et vos développeurs pour leur poser des questions du genre : "Êtes-vous satisfaits des résultats de nos développements de produits ?" ou encore "Pensez-vous que nous apportons de la valeur à nos client dans le respect des délais, de la rentabilité et de la qualité ?". Que croyez-vous qu'ils vous répondent ?

Les personnes que je rencontre lors de mes sessions de formation et de conseil dans diverses parties du monde répondent assez souvent par la négative à ces deux questions et poursuivent par une litanie d'arguments : "Le taux d'échec des projets est inaccep-table", "Nous livrons en retard", "Le retour sur investissement est souvent inférieur aux prévisions", "La qualité logicielle est faible", "La productivité est médiocre", "Personne n'est considéré responsable des résultats", "Le moral des employés est mauvais" ou "Le turnover est trop important". La confidence se termine alors par cette remarque ironique : "Il doit pourtant y avoir moyen de mieux faire".

Malgré tout ce mécontentement, la plupart des gens semblent résignés à accepter que la frustration fait partie de la réalité en développement de logiciels. Ce n'est pourtant pas le cas.

Les entreprises qui ont appliqué l'approche Scrum de façon posée ont découvert une autre réalité (voir Figure 1.2).

Clients satisfaits

Confiance pour réussir dans le complexe

Avantages de Scrum

Meilleur retour sur investissement

Coûts réduits

Résultats rapides

Plaisir au travail

.

. aaFigure 1.2Avantages de Scrum.



Ces entreprises enchantent leurs clients de façon répétée en leur livrant ce dont elles ont vraiment besoin et pas seulement ce qui a été défini au lancement du projet, époque pendant laquelle les connaissances des besoins étaient les moins complètes. Le retour sur investissement est meilleur, car les releases (livraisons) sont plus fréquentes et de moins grande ampleur. Enfin, par une traque permanente des causes de gaspillage et de dérèglement de l'organisation, ces entreprises réussissent à réduire leurs coûts.

Scrum permet de livrer rapidement des résultats tangibles en se concentrant sur des itérations, chacune ayant pour objectif un état fonctionnel du projet intégré et testé. Scrum est bien adapté pour aider les entreprises à réussir dans un contexte complexe et changeant qui demande de s'adapter vite à un faisceau d'initiatives lancées par les concurrents, les clients, les utilisateurs, les organismes de régulation et les parties prenantes. Et Scrum apporte plus de satisfaction à toutes les personnes concernées, aux clients bien sûr, mais aussi aux acteurs du processus ! Ils collaborent fréquemment et de façon profitable, ce qui améliore leurs relations et renforce la confiance mutuelle entre membres de l'équipe.

Ne nous méprenons pas. Même si Scrum est une excellente solution dans la plupart des situations, ce n'est pas une sinécure. Voyons le modèle de conceptualisation Cynefin (Snowden et Boone, 2007) (un mot gallois à prononcer "qunevinn"). Ce modèle permet de se situer au niveau opérationnel afin de choisir l'approche la plus adaptée à la situa-tion. Il définit et compare les caractéristiques de cinq domaines : les quatre domaines simple, compliqué, chaotique et complexe qui entourent le domaine du désordre dans lequel on se trouve lorsque l'on ne parvient pas à se situer dans l'un des quatre autres (voir Figure 1.3). Je vais exploiter le modèle Cynefin pour passer en revue les situations dans lesquelles Scrum est approprié et celles dans lesquelles il ne l'est pas.



Scrum et Kanban sont tous deux fondés sur la philosophie Agile et chaque modèle a ses points forts et ses faiblesses. Vous en tiendrez compte une fois que vous aurez déterminé le domaine de votre projet. Certaines entreprises combinent Scrum et Kanban pour répondre au mieux aux divers besoins d'un système. Scrum pourra ainsi servir pour le développement des nouveaux produits et Kanban pour le support et la maintenance.

Conclusion

Scrum n'est pas la recette miracle mais il peut vous aider à garder sous contrôle les changements qui accompagnent tout développement de produit complexe. Scrum a été bénéfique pour des entreprises telles que Genomica qui ont décidé d'adopter une approche du développement de logiciel mieux adaptée à leurs besoins.

Le cadre formel de Scrum est assez simple, mais ce serait une erreur de penser que Scrum est applicable aisément et sans efforts. Scrum ne donne pas de réponse prédéfinie aux questions qui se posent dans vos processus ; en revanche, il dote les équipes des moyens de poser les questions essentielles et de trouver de bonnes réponses. Scrum n'ap-porte pas à chacun un livre de remèdes à tous ses soucis d'organisation ; il rend visibles les dysfonctionnements et déperditions qui empêchent les organisations d'atteindre leur plein potentiel.

Constater ces défauts peut s'avérer douloureux dans bien des entreprises, mais une fois passée la période initiale d'inconfort, il suffit de s'attaquer à la résolution des problèmes mis en lumière par Scrum pour jouir d'une nette amélioration dans les processus de développement de logiciels et de produits et dans le niveau de satisfaction des employés comme des clients.

Toute la suite de ce livre se consacre à la description détaillée des points essentiels de Scrum. Je vais commencer par une présentation globale du modèle Scrum : rôles, acti-vités, artéfacts et règles. Qui sait : si vous adoptez Scrum de la bonne manière et dans les bonnes conditions, vous pourrez vous aussi livrer beaucoup de valeur ajoutée dans les délais, comme y est parvenue ma femme en ce fameux jour de l'année 2000.


2Le cadre de Scrum

Ce chapitre vous propose un aperçu du modèle Scrum en présentant d'abord les rôles, les activités et les artéfacts. Les chapitres suivants entreront dans les détails de chaque pratique, sans omettre de discuter en détail les principes sous-jacents.

Vision générale

Scrum ne constitue pas un processus standardisé qui vous demanderait de suivre passi-vement une série d'étapes successives en vous promettant d'aboutir à un produit de haute qualité censé ravir vos clients sans dépassement ni de budget, ni de délais. Scrum est un modèle pour vous aider à organiser des travaux et à en gérer le déroulement. Le modèle Scrum se fonde sur un jeu de valeurs, de principes et de pratiques qui deviennent une infrastructure sur laquelle votre organisation va pouvoir asseoir ses propres choix de pratiques d'ingénierie et sa manière personnelle de mettre en mouvement les pratiques Scrum. Le résultat sera un modèle Scrum qui vous sera propre.

Pour vous faire une idée plus précise du concept, vous pouvez comparer le modèle Scrum au plancher et aux murs porteurs d'un bâtiment. Les valeurs, principes et pratiques Scrum sont les composants structurels que vous ne pouvez pas ignorer, ni modifier en profondeur sans risquer d'effondrer tout l'édifice. En revanche, vous avez toute liberté pour personnaliser les aménagements dans la structure Scrum, en déplaçant des cloisons et en ajoutant des équipements jusqu'à obtenir un processus qui vous convienne.

Scrum est une approche étonnamment simple et orientée vers l'humain qui prône des valeurs telles que l'honnêteté, l'ouverture aux autres, le courage, le respect, la concen-tration, la confiance, la responsabilisation et la coopération. Le Chapitre 3 présente en détail les grands principes Scrum en liaison avec l'approche Agile ; les chapitres suivants montreront comment les pratiques s'articulent avec ces principes et valeurs.

La pratique de Scrum se fonde sur des rôles, des activités, des artéfacts et les règles associées (voir Figure 2.1).

La suite de ce chapitre présente les principaux points pratiques de Scrum.



Activités

Rôles

Pratiques Scrum

Product Owner

Backlog de produit

Décrites tout au long du livre

Sprint

Scrum quotidien

Exécution de sprint

Revue de sprint

Rétrospective de sprint

Artéfacts

Règles

Backlog de sprint

Incrément de produit potentiellement livrable

Planification de sprint

Scrum Master

Équipe de développement

Grooming du Backlog de produit

aaaa

Figure 2.1Pratiques Scrum.

Les rôles Scrum

Les efforts de développement en approche Scrum sont déployés par une ou plusieurs équipes Scrum. Chaque équipe comporte trois rôles Scrum : le Product Owner (proprié-taire du produit), le ScrumMaster et l'équipe de développement (voir Figure 2.2). D'autres rôles peuvent s'y ajouter, mais le modèle Scrum ne rend que ces trois rôles incontournables.


Le cadre de Scrum 17Chapitre 2

Product Owner

Équipe scrum


Scrum Master

Figure 2.2Les rôles Scrum.

Le Product Owner est responsable de ce qui doit être développé et dans quel ordre cela doit l'être. Le ScrumMaster se charge de guider l'équipe dans ses efforts de création en l'aidant à mettre en pratique son processus spécifique et à rester fidèle aux principes Scrum. Enfin, l'équipe de développement est responsable de la production et des moda-lités de livraison de ce qui a été demandé par le Product Owner.

Si vous êtes manager, ne soyez pas étonné de ne pas voir ce rôle apparaître dans la Figure 2.2 ; les managers conservent néanmoins une fonction importante dans les processus basés Scrum (voyez à ce sujet le Chapitre 13). Le modèle Scrum se limite à définir les rôles qui lui sont spécifiques, et non tous les rôles qui peuvent et doivent être présents dans une organisation adoptant l'approche Scrum.

Product Owner

Le Product Owner est le point central du pilotage du produit. Il représente l'unique autorité pouvant décider quelles fonctions il faut réaliser et dans quel ordre. Le Product Owner est le garant de la vision globale de ce que l'équipe Scrum doit réaliser ; il se charge de communiquer cette vision à tous les autres participants. En conséquence, c'est le Product Owner qui est responsable du succès global de la solution à créer ou à maintenir.

Note

Dans ce livre, nous maintenons la parité hommes/femmes en représentant dans les figures un homme pour le rôle de Product Owner et une femme pour celui de ScrumMaster.

Que l'objectif soit un produit destiné à un client ou une application interne, le Product Owner doit s'assurer que le travail produit offre le maximum de valeur ajoutée (et ce travail peut comprendre un aspect uniquement technique). Pour garantir que l'équipe produise rapidement ce qu'il attend, le Product Owner coopère activement avec le ScrumMaster et l'équipe de développement : il se tient disponible pour répondre au plus vite à toutes les questions. Le Chapitre 9 donne une description détaillée du rôle de Product Owner.



ScrumMaster

Le ScrumMaster est le gardien de l'esprit Scrum : il aide tous les membres à comprendre et adopter les valeurs Scrum, ses principes et ses usages. Il agit comme un entraîneur sportif ou un coach, en guidant le processus et en aidant l'équipe Scrum et d'autres membres de l'organisation à mettre en pratique de façon efficace l'approche Scrum spécifique à l'entreprise. Le ScrumMaster doit par ailleurs soutenir l'organisation dans l'important processus de changement dans le management que l'adoption de Scrum peut déclencher.

En tant que facilitateur, le ScrumMaster aide l'équipe à résoudre les problèmes et à améliorer son utilisation de Scrum. Il doit aussi protéger l'équipe des interférences extérieures et devenir un meneur dans la suppression des obstacles qui menacent la productivité de l'équipe (lorsque les individus de l'équipe n'y parviennent plus de façon autonome). En revanche, le ScrumMaster ne détient aucune autorité sur l'équipe, ce en quoi ce rôle ne se confond pas avec le rôle classique de Project Manager ou Develop-ment Manager. Le ScrumMaster est un animateur, un facilitateur, pas un manager. Je rappelle les rôles de Manager fonctionnel et de Project Manager dans le Chapitre 13. Le Chapitre 10 détaille le rôle de ScrumMaster.


L'approche classique de développement logiciel réunit plusieurs profils : architecte, programmeur, testeur, administrateur de bases, concepteur d'interface IHM/GUI, etc. Scrum ne définit qu'un rôle collectif d'équipe de développement, qui constitue un regroupement polyvalent de ces différents types de compétences (conception, réalisa-tion et test) indispensables pour aboutir au produit désiré.

L'équipe de développement s'organise elle-même pour décider de la meilleure manière d'atteindre l'objectif défini par le Product Owner. Cette équipe réunit de cinq à neuf personnes ; elle doit disposer de toutes les compétences requises pour produire un logi-ciel fonctionnel et de qualité. Rien n'empêche d'appliquer Scrum à une équipe de plus grande taille, mais il est conseillé de constituer trois ou quatre équipes de moins de dix personnes plutôt qu'une seule grande équipe de, par exemple, 35. Le Chapitre 11 entre dans les détails du rôle de l'équipe de développement et le Chapitre 12 présente les tech-niques pour coordonner plusieurs équipes.

Activités et artéfacts Scrum

La Figure 2.3 donne une vue d'ensemble des activités et artéfacts principaux de Scrum avec leurs interactions.



Exécution de sprint

Revue de sprint

Planification de sprint

Incrément de produitpotentiellementlivrable

Scrum quotidien

Backlog de produit

Grooming

Rétrospective de sprint

Backlog de sprint

Figure 2.3Vue globale du cadre Scrum.

Passons ce schéma en revue en commençant par la gauche et en progressant dans le sens horaire.

Le Product Owner détient la vision de ce qu'il veut voir produire (symbolisé par le gros cube). Ce projet pouvant être vaste, il est décomposé en plusieurs blocs fonctionnels par une activité appelée Grooming et ces blocs sont placés par priorités décroissantes dans la liste appelée Backlog de produit.

La production d'un bloc fonctionnel correspond à une itération appelée sprint qui débute par la planification de sprint, englobe toute la séquence de développement (l'exécution de sprint) et se termine par les deux étapes de revue de sprint et de rétrospective de sprint. Dans le schéma, le sprint correspond à la grande boucle horizontale. Puisque le nombre d'éléments dans le Backlog de produit est en général bien supérieur à ce qu'il est possible de produire dans un cycle de sprint, l'équipe de développement doit sélectionner dans le Backlog de produit au début de chaque sprint un sous-ensemble d'objectifs. Cela correspond à l'activité de planification de sprint. Elle est montrée du côté gauche, juste à droite du cube du Backlog de produit.

Je profite de l'occasion pour un bref aparté. En 2011, le livre de référence The Scrum Guide de Schwaber et Sutherland avait déclenché un débat passionné autour du terme approprié pour décrire le résultat de la planification de sprint : était-ce une estimation ( forecast) ou bien un engagement (commitment) ? Les partisans du terme "estimation" pensaient que même si l'équipe de développement faisait de son mieux pour estimer l'ef-fort au départ, le fait de recueillir des informations pendant le déroulement des travaux rendait immanquablement cette estimation obsolète. Les mêmes redoutaient aussi qu'un engagement pousse l'équipe à rogner sur la qualité pour être certaine de tenir son enga-gement ou se montrer conservatrice en s'engageant moins loin vers le même but.



Je pense que toutes les équipes de développement doivent établir des estimations de ce qu'elles pourront livrer pendant chaque sprint. Ceci dit, de nombreuses équipes tireraient profit de la transformation de cette estimation en un engagement. Les enga-gements matérialisent la relation de confiance entre le Product Owner et l'équipe de développement et au sein de cette équipe. Ils favorisent une planification et une prise de décision dans des délais raisonnables. Lors d'un projet avec plusieurs équipes de développement, les engagements aident à synchroniser la planification : une équipe peut prendre certaines décisions en s'appuyant sur ce à quoi une autre équipe s'est engagée. Au cours de ce livre, je privilégie le terme "engagement", mais j'utilise parfois le terme "estimation" quand il me semble plus pertinent dans son contexte.

Pour renforcer sa confiance dans l'engagement pris collectivement par l'équipe de déve-loppement, ses membres construisent un second backlog lors de la phase de planification de sprint : c'est le Backlog de sprint qui décrit de façon détaillée les tâches lui permet-tant de concevoir, réaliser, intégrer et tester le sous-ensemble fonctionnel sélectionné dans le Backlog de produit pour le sprint considéré.

Vient ensuite l'exécution de sprint proprement dite. L'équipe de développement réalise les tâches pour créer les fonctions prévues. Pendant l'exécution de sprint, une réunion quotidienne appelée scrum (mêlée) permet aux membres de l'équipe de garder le contrôle du flux de tâches. Ce scrum quotidien sert à synchroniser, inspecter et faire une planification adaptative. En fin d'exécution de sprint, l'équipe doit avoir abouti à un incrément fonctionnel livrable du produit qui incorpore une portion de la vision définie par le Product Owner.

L'équipe Scrum clôture le sprint par deux activités successives d'inspection et adapta-tion. La première est la revue de sprint. Elle réunit les actionnaires/parties prenantes et l'équipe Scrum pour inspecter le produit résultant du sprint. La seconde réunion est la rétrospective de sprint. Elle s'intéresse au processus adopté pour réaliser le produit. Les conclusions de ces activités peuvent dégager des besoins d'adaptation qui pourront se propager jusqu'au Backlog de produit ou être incorporées dans le processus de dévelop-pement standard de l'équipe.

Après ces deux réunions, nous avons atteint la fin du cycle de sprint Scrum et pouvons en démarrer un autre. L'équipe de développement sélectionne les prochains éléments prioritaires du Backlog de produit pouvant être réalisés. Au bout d'un certain nombre de sprints, la vision définie par le Product Owner est concrétisée et la solution complète peut être diffusée.

La suite de ce chapitre décrit en détail ces activités et artéfacts.

Backlog de produit (carnet de production)

Dans Scrum, vous réalisez toujours en premier les travaux offrant le plus de valeur. Le Product Owner recueille les avis du reste de l'équipe Scrum et des parties prenantes, mais il reste responsable de l'ordonnancement et de la gestion de la séquence du travail et de sa communication sous la forme d'une liste ordonnée qui correspond au Backlog de produit (voir Figure 2.4). Pour les développements de nouveaux produits, les éléments



du Backlog de produit sont les fonctions requises pour concrétiser la vision produit du Product Owner. Pour les produits à faire évoluer, le Backlog de produit réunit des nouvelles fonctions, des changements de fonctions existantes, des correctifs, des amélio-rations techniques, etc.

Refactor X

Fonction D

Fonction E

Fonction F

Eléments très prioritaires

Eléments peu prioritaires

Fonction AFonction BFonction CDéfaut 23

Figure 2.4Backlog de produit.

Le Product Owner collabore avec les parties prenantes internes et externes pour collecter et définir les éléments du Backlog de produit, puis il classe ces éléments en ordre décroissant de valeur (avec comme critères la valeur résultante, le coût de produc-tion, la connaissance apportée et le risque). Le Backlog de produit est un document (artéfact) en évolution constante : des éléments sont ajoutés, supprimés, déplacés et révisés par le Product Owner en réaction aux changements du contexte économique ou suite aux nouvelles informations dont dispose l'équipe Scrum au sujet du produit visé (suite aux comptes-rendus de produit obtenus lors de chaque sprint).

Les activités de création, d'estimation, de classement et de peaufinage des éléments du Backlog de produit sont regroupées sous le terme collectif de Grooming (voir Figure 2.5).


Documents

Qu'est-ce que l'essence de Scrum · Scrum se fonde sur un jeu limité de valeurs, de principes et de pratiques (ce qui constitue le cadre Scrum). Une entreprise qui veut adopter Scrum