1 Introduction Le 12 juin 2000, j'étais vice-président exécutif chez Genomica, une société de bio-informatique 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 viceprésident Engineering était au centre des débats. J'étais dorénavant chargé de superviser les efforts à déployer pour améliorer sérieusement 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. Backlog de produit Fonction A Fonction B Fonction C Planification itérative Fonction C Fonction A Fonction B Revue itérative Itération (de une semaine à un mois calendaire) Figure 1.1 Vue 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ération. 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.
Chapitre 1 Introduction 3 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éveloppement. 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 maximales. 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é.
4 Scrum - Management de projet Agile 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éveloppement 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 fondamentaux. 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 utilisateur 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
Chapitre 1 Introduction 5 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
6 Scrum - Management de projet Agile 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 inacceptable", "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 Meilleur retour sur investissement Coûts réduits Avantages de Scrum Résultats rapides Confiance pour réussir dans le complexe. Figure 1.2 Avantages de Scrum. Plaisir au travail. aa
Chapitre 1 Introduction 7 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 situation. 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.
Chapitre 1 Introduction 11 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'apporte 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, activité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.