BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Q&R Sur Le Livre a Scrum Book: The Spirit of the Game

Q&R Sur Le Livre a Scrum Book: The Spirit of the Game

Points Clés

  • Les modèles Scrum décrivent Scrum a un niveau plus profond que ce que l'on trouve habituellement.
  • Les modèles montrent des choses intuitives qui fonctionnent, plutôt que des pratiques ésotériques.
  • Il y a une place pour le management dans Scrum pour supprimer les obstacles et faire grandir l'entreprise, pas seulement pour gérer les produits.
  • La valeur vient tout autant de la décision de ce qu'il ne faut pas construire, que de celle de construire plus de ce que le marché a besoin selon vous.
  • Chaque obstacle est une amélioration en attente de devenir, et chaque modèle une solution en attente d'éliminer un obstacle.

Dans A Scrum Book: The Spirit of the Game, Jeff Sutherland et James Coplien explorent comment bien faire du Scrum en utilisant des modèles. Il y a plus de quatre-vingt-dix modèles qui donnent des aperçus sur les blocs de construction de Scrum, comment ils fonctionnent, et comment les équipes très efficaces les utilisent.

Les lecteurs d'InfoQ peuvent télécharger un extrait de A Scrum Book.

InfoQ a interviewé Jeff Sutherland et James Coplien sur la finalité des modèles Scrum et comment nous pouvons les appliquer dans l'adoption de Scrum pour créer des équipes efficaces. Nous leur avons aussi demandé de décrire quelques modèles tirés de ce livre.

InfoQ : Pourquoi avez-vous écrit ce livre ?

Jeff Sutherland : Deux des chefs de file du mouvement originel des modèles voulaient se concentrer sur les modèles de Scrum (Cope et Neil Harrison). Cela faisait un moment que Ken Schwaber et moi-même discutions sur la façon dont nous présentons comment bien jouer à Scrum sans être prescriptifs. Le Guide Scrum met l'accent sur ce qu'est Scrum, mais la vraie magie vient de la façon dont vous l'implémentez. Le concept fondamental d'Alexandre, générer un ensemble complet à partir de modèles, me semble à la fois juste et profond. Je voulais aider à décrire comment créer d'excellentes équipes Scrum qui soient à la fois hyper-productives et qui aient un effet sur la vie de leurs membres. J'ai travaillé en particulier sur les modèles critiques à une bonne implémentation de Scrum. Nous avons écrit un papier avec Neil Harrison dont le titre est « Les équipes qui finissent plus tôt accélèrent plus vite ». Aujourd'hui, j'utilise les modèles pour enseigner Scrum.

James Coplien : J'avais deux motivations. D'abord, en ayant beaucoup travaillé avec des équipes Scrum, j'ai toujours été consterné par le fait que tant de personnes puissent mal comprendre Scrum, même après avoir été formées et avoir lu le Guide Scrum. La grande majorité des gens ne peuvent pas répondre correctement aux questions les plus simples comme « Pourquoi faisons-nous une mêlée quotidienne ? » J'ai pensé qu'il serait bien de créer un standard de facto pour Scrum qui explique le pourquoi derrière ce qu'on fait. La deuxième, c'était que j'étais triste de voir combien la communauté des modèles avait perdu la voie dans ce qu'elle écrivait. Les notions de complétude et de beauté imaginées par Alexander avaient disparu de leurs écrits. On avait perdu toute la générativité indirecte, et beaucoup du programme d'Alexander sur le confort humain. L'initiative des modèles Scrum nous a offert l'opportunité de repartir d'une ardoise vierge avec les modèles existants, et aussi d'amener des chefs de file de la communauté des modèles pour aider celle-ci à retrouver son étoile du nord.

InfoQ : À qui ce livre s'adresse-t-il ?

James Coplien : Il y en a un petit peu pour toutes les personnes qui font des choses. Pour l'essentiel, des Scrum Masters, des praticiens Scrum, d'autres personnes dans leurs organisations, ainsi que des coachs, des formateurs et des consultants. Les managers peuvent se servir du livre pour apprendre qu'ils ne devraient pas se mêler de la production, tout en prenant sérieusement la responsabilité de soutenir ceux qui sont engagés dans cette production, pour apprendre à récolter les bénéfices et à gérer les risques des changements radicaux qui peuvent entraîner les entreprises à un tout autre niveau. Il s'adresse à celles et ceux qui développent des produits complexes, quels qu'ils soient.

Jeff Sutherland : Toute personne qui implémente Scrum et qui rencontre des difficultés devrait trouver une solution potentielle dans les modèles de ce livre. Ces modèles sont passés par un processus rigoureux d'ateliers. Ils ont du prouver qu'ils fonctionnaient bien dans de nombreuses organisations et cela de façon répétée, qu'ils étaient cohérents avec l'ensemble des modèles Scrum, facilement compréhensibles et implémentables par les équipes Scrum, et approuvés par un groupe d'experts internationaux de Scrum. On a montré que quelques-uns des modèles les plus importants sur la performance ont fonctionné 100% du temps dans des douzaines de sociétés. Il n'y a pas d'autre livre comme celui-ci. Je ne mettrais pas en place un Scrum sans lui.

InfoQ : Quelle finalité servent les modèles de Scrum ?

Jeff Sutherland : Quand j'ai créé Scrum, je me suis concentré sur la documentation de ce qui fonctionne constamment dans des équipes hautement performantes. Par exemple, les équipes chez Bell Labs ont fait des choses contre-intuitives. Qui pourrait dire qu'une équipe ne devrait pas compter plus de quatre ou cinq personnes ? Seulement les gens qui ont inventé le langage C et Unix. Qui pourrait se débarrasser des titres des fonctions parce qu'ils ne font que ralentir les choses ? Les recherches de Cope dans le Projet Pasteur, et d'innombrables autres données de recherche, ont prouvé par la suite la justesse de ces concepts fondamentaux. Mais il y a encore des équipes qui pratiquent « Scrum » dans des équipes trop grandes comprenant trop de spécialistes avec des titres à rallonge. Les bases ne sont pas évidentes pour un groupe classique de technologies de l'information. J'ai compris qu'il faudrait plus d'une vie pour que la plupart des organisations comprennent les bases. Le Guide Scrum est trop concis pour montrer les styles de jeu gagnants. De nombreuses équipes dysfonctionnelles continueront à être mauvaises tant qu'elles ne mettront pas en place ces modèles.

James Coplien : Nous sommes tous nés avec du sens commun. Nous nous sommes appuyés sur ce câblage inné toute notre vie pour développer un sens profond de ce qui marche et de ce qui ne marche pas. Les équipes pourraient tirer profit de cette profonde connaissance collective pour construire de grandes choses ensemble. Mais les formalismes du management, les normes culturelles dépassées, le désir de pouvoir et la culture d'entreprise et son histoire, tout cela frustre nos penchants pour suivre ces chemins intuitifs. Les modèles Scrum nous aident à nous souvenir ce que nous savons déjà, peut-être seulement de manière tacite, sur la façon d'organiser le travail. En tant que tels, ils s'opposent à ce que la plupart des pratiques de développement professionnelles et académiques nous enseignent. Il ne s'agit pas d'instructions à suivre littéralement, mais plutôt des conseils qui peuvent réveiller la grandeur au sein de chaque groupe pour créer des équipes et des produits d'excellence.

InfoQ : Dans le première modèle du livre, Spirit of the Game (l'esprit du jeu), vous dites que « Scrum nécessite un esprit d'interaction entre les personnes qui peut être difficile à définir. » Pourquoi Scrum en a-t-il besoin ? Comment peut-on vérifier si cet esprit existe réellement dans une équipe et dans une organisation ?

James Coplien : Nous nous sommes inspirés de L'esprit du cricket de Rob Smyth, qui raconte comment des arbitres de cricket ont obligé un joueur à retirer une oreillette qui lui servait à recevoir les instructions de son coach pendant la partie. Il n'y a pas de règle explicite qui interdit une communication électronique comme celle-ci au cricket, mais il y en a une qui indique que tout ce qui viole « l'esprit du jeu » est une infraction aussi importante que si la règle était écrite. La même chose s'applique à Scrum. Le Guide Scrum est le livre des règles qui définit le Scrum canonique. Mais Scrum, c'est comme les petites roues d'un vélo : les équipes apprennent en n'étant pas à la hauteur du Guide Scrum, en déviant de la trajectoire, en tombant de leur vélo et en se faisant quelques bleus. C'est comme cela que les équipes apprennent à suivre une mesure spécifique du Guide Scrum, ou, à l'occasion, à découvrir que leur propre façon de faire est peut-être meilleure. Vous n'aurez pas de médaille si vous suivez les règles à la perfection. Ce qui compte, c'est le résultat. Une vision qui va au-delà de Scrum pour atteindre les notions plus profondes de résultat, de valeur, de passion et d'accomplissement, voilà ce qui devrait piloter les décisions d'une équipe Scrum. Vous voulez la mesurer ? Regardez comment l'équipe s'engage dans son travail, ou regardez les résultats.

Jeff Sutherland : L'esprit de Scrum est d'éliminer les obstacles qui bloquent la productivité ou la capacité de l'équipe à accomplir des choses, ce qui inclut tout ce qui peut impacter de manière négative le bonheur de l'équipe. L'esprit de Scrum, c'est mettre le client en premier, l'enchanter, lui délivrer des produits formidables qui changent sa vie à un coût si réduit que tout le monde peut en profiter. L'esprit de Scrum, c'est d'améliorer la performance de l'organisation pour créer des emplois, développer du leadership, et rétribuer les investisseurs. Ce qui n'est pas dans cet esprit et que des gens appellent « Scrum » n'est qu'une parodie.

InfoQ : Comment Scrum voit-il le rôle du management ? Comment peut-on impliquer les managers quand Scrum est adopté ?

James Coplien : La plus grande partie de Scrum concerne le développement de produit. Scrum est inébranlable sur le fait que les managers ne doivent pas interférer avec les décisions de développement quotidiennes, qu'ils ne doivent pas garder le contrôle sur les décisions affectant le produit. À cet égard, l'équipe Scrum se gère elle-même. L'équipe continue de s'améliorer de façon incrémentale grâce au kaizen, à l'amélioration continue. Cependant, il y a des opportunités d'amélioration hors du périmètre du développement de produit. Par exemple, quand on lance un nouveau produit, allouer des fonds pour des initiatives d'amélioration, ou trouver des économies d'échelle et de périmètre pour plusieurs produits. Un manager pourrait améliorer la valeur globale délivrée aux clients par l'entreprise (ainsi que la profitabilité correspondante), en supprimant un produit existant qui sous-performerait et en redirigeant les actions de la société sur un autre produit plus profitable. Google a mis fin à des douzaines de produits de cette façon au cours de la dernière décennie. Ce sont des changements discontinus, brutaux, que les japonais appellent kaikaku. Voilà le travail du management. En plus de cela…

Jeff Sutherland : Ken et moi-même avons suivi les travaux du professeur John Kotter sur le changement pendant des décennies. Dans l'un de ses récents ouvrages, XLR8 (NDT : paru en français sous le titre « XLR Accélérez ! »), il dit qu'il n'a encore jamais vu une transformation agile réussie à moins qu'un système opératoire séparé n'ait été mis en place suivant les principes agiles, et géré par des managers agiles. Dans mes dernières conférences, j'ai demandé à des milliers de personnes combien d'entre elles avaient une gestion en cascade de leur pratique agile. Plus de 90% ont répondu que c'était un problème majeur dans leur organisation. J'ai donc documenté dans le Guide Scrum@Scale comment créer un écosystème agile dirigé par une Executive Action Team (EAT) qui protège la bulle agile de toute bureaucratie en cascade qui pourrait compromettre la performance des équipes agiles. Cela inclut de changer toutes les règles, principes, procédures et politiques qui ont besoin de l'être, voire de les éliminer pour maximiser l'agilité de l'entreprise. C'est le rôle des managers dans Scrum. Ils deviennent des leaders agiles, des coachs de coachs, ils écoutent les équipes, et ils suppriment tout ce qui peut se mettre sur leur chemin. Les cadres supérieurs des sociétés de la Silicon Valley me disent qu'il s'agit d'un travail à temps plein. D'ailleurs, des équipes de management senior qui ont travaillé avec moi après avoir été dans des équipes Scrum ont simplement supprimé toutes les réunions et tous les rapports ne faisant pas partie de Scrum, pour eux-mêmes comme pour les autres. Les artefacts de la cascade ne délivrent aucune valeur et sont contre-productifs.

InfoQ : Explorons quelques modèles du livre, en commençant par le Scrum Master Incognito. À quoi ressemble ce modèle ? Quels avantages apporte-t-il ?

James Coplien : Il peut ressembler à cela lors de la mêlée quotidienne :

Le modèle avise les Scrum Masters que les développeurs vont trop souvent les traiter comme leurs anciens managers, leur faisant des rapports et attendant qu'ils leurs disent quoi faire ensuite. Les Scrum Masters devraient se désengager de façon visible et claire, c'est-à-dire passer incognito, quand ils s'en rendent compte. Cela envoie le message que les équipes sont responsables de leurs propres décisions et qu'elles devraient se gérer elles-même et organiser leur propre travail.

Jeff Sutherland : Ce modèle est implémenté par quelques-uns des meilleurs coachs agiles avec lesquels j'ai pu travailler lorsqu'ils prennent le rôle de Scrum Master. Par exemple, si vous lisez mon article avec Scott Downey (J. Sutherland, S. Downey et B. Granvik, « Shock Therapy: A Bootstrap for a Hyper-Productive Scrum » à Agile 2009, Chicago, 2009), l'une des stratégies clés utilisées pour créer des équipes hyper-productives est un Scrum Master qui se déplace hors du cercle lors de la mêlée quotidienne Scrum et se place derrière eux. Cela n'arrive que lorsque l'équipe est mature et en a assez compris pour s'auto-organiser afin d'atteindre l'objectif de sprint.

James Coplien : « Lorsque l'équipe est mature », c'est ce qu'on appelle un contexte dans le langage des modèles. Certains modèles ont besoin que d'autres soient déjà en place avant de pouvoir être actionnés. Le livre aide à comprendre quel contexte doit être en place pour que chaque modèle fasse sens. Il explique aussi quels contexte et contexte résultant d'un modèle s'articulent ensemble dans le réseau des modèles environnants pour qu'une équipe puisse définir un plan ordonné de kaizen.

InfoQ : Qu'est-ce que le Organizational Sprint Pulse (pouls de sprint organisationnel), et comment les organisations peuvent-elles appliquer ce modèle ?

Jeff Sutherland : En 2006, j'ai commencé à travailler avec OpenView Venture Partners. Scott Maxwell, fondateur et partenaire senior, a développé un programme de formation pour les sociétés de notre portefeuille. Il disait que tout travail était le résultat d'un incrément délivrable à la fin de chaque Sprint et qu'il devait être intégré à la fin du Sprint si plusieurs équipes y participaient. C'est la raison pour laquelle les opérations ont besoin d'avoir un Scrum intégré, ainsi que des données financières hebdomadaires, mensuelles, trimestrielles et annuelles. Toutes les composantes de l'organisation travailleront ainsi à un meilleur niveau de performance en suivant ce pouls organisationnel commun. Nous avons près d'un milliard de dollars investis dans une douzaine d'entreprises. Cette approche a été le premier programme de formation complètement documenté pour ce qui est devenu à présent Scrum@Scale. Notre dernier fond, qui comprend une douzaine d'entreprises utilisant cette approche, a vu sa valorisation augmenter de moins de 200 millions à plus de 500 millions au cours de l'année 2018. Le pouls de sprint fonctionne vraiment !

James Coplien : Scrum, et la vie humaine en général, tournent autour du rythme. La pratique de base ici est que les équipes travaillent en cycles avec une cadence régulière. Les équipes Scrum devraient se synchroniser entre elles et avec le rythme de l'organisation qui les englobe. Si plusieurs équipes qui coopèrent se désynchronisent, alors ce que produit une équipe peut rester dans les stocks le temps de pouvoir être combiné avec ce que produit une autre équipe et créer de la valeur. Les japonais diraient que nous voulons réduire les irrégularités (mura) pour éviter ces biais d'alignement. Des rythmes synchronisés créent aussi un contexte cohérent entre les équipes, lissant le flux et réduisant le stress des activités de développement local (réduisant le muri).

InfoQ : Comment le modèle High Value First (haute valeur en premier) nous aide à livrer les éléments du backlog produit les plus essentiels en premier ?

Jeff Sutherland : Nous découvrons encore et encore qu'il est essentiel de prioriser par la valeur toutes les initiatives au sein d'une organisation pour apprécier pleinement que le tiers inférieur des projets, sorties et initiatives n'ont aucune valeur et devraient être annulés. Par exemple, une société de service en TI a découvert que 30% de ses employés faisaient du support pour Windows 7 alors que la plupart de ses clients étaient déjà passés sur Windows 10. Ils ont libéré le temps de centaines d'employés en un après-midi. Si on regarde les fonctions et fonctionnalités, on a beaucoup de données, autant du côté logiciel que matériel, qui indiquent que les deux tiers de ces fonctionnalités ne servent que rarement, voire jamais, pour les utilisateurs, même si celles-ci ont été spécifiées dans les projets par les clients. L'un des premiers défis pour un Product Owner est de ne pas développer ces fonctionnalités, et de concentrer tous les efforts sur celles qui seront utilisées par les clients. Éviter de développer ces fonctionnalités permet de terminer plus tôt tous les projets. C'est la base des stratégies de nouveaux projets comme Money for Nothing and Your Change for Free (voir « Update 2018: Agile 2008 – Money for Nothing and Your Change for Free » sur scruminc.com). Scrum@Scale permet le High Value First en spécifiant un Metascrum d'entreprise, qui est une réunion régulière entre une Product Owner Team et les parties prenantes pour s'aligner sur les priorités. Le Metascrum et la Product Owner Team sont deux modèles de ce livre.

James Coplien : Même si ce modèle est optimisé pour le cas spécifique d'un développement de produit à coût et périmètre fixes, il est encore trop souvent vrai que les équipes priorisent en fonction de la personne qui parle le plus fort, ou sur la base d'une « priorité ». La plupart des équipes veulent livrer de plus en plus, au lieu de livrer les bonnes choses dans le bon ordre. Pourtant, Taichi Ōno note que la surproduction est la première cause de déchet (si le lecteur n'y croit pas, il peut modifier son code pour découvrir quelle part n'est jamais ou rarement exécutée). Dans Scrum, on trie le backlog par ordre de livraison pour atteindre la valeur la plus élevée, plutôt que selon un classement indépendant de chaque élément par ordre d'importance, puis en commençant par les éléments les plus sexy ou ceux qui bénéficient aux clients qui parlent le plus fort. Quand vous construisez une maison, une humble fondation de béton doit être en place avant d'installer cette cuisine qui vous plaît tant.

InfoQ : Qu'est-ce qu'une Enabling Specification (spécification habilitante) ? Comment aide-t-elle l'équipe de développement à rester dans le flux ?

Jeff Sutherland : J'ai travaillé au premier projet Scrum en conformité avec la FDA en 1997. Ken Schwaber en était le Scrum Master. Nous avons éliminé 95% du coût de la conformité FDA. Pour y arriver, nous avons tout retracé jusqu'à la conception pour obtenir l'agrément de la FDA. Je voulais une « spécification agile » qui soit courte, claire et exécutable rapidement. L'un de nos collègues signataire du Manifeste Agile, Alistair Cockburn, a vigoureusement objecté, disant qu'il n'existait pas de « spécification agile ». Puisque j'avais été impliqué dans de nombreux dépôts de brevet, je savais qu'ils avaient une longueur moyenne de six pages et étaient assez spécifiques pour qu'une tierce partie puisse les implémenter sans avoir à parler avec l'inventeur. Ils devaient donc être assez clairs. La loi sur les brevets des États-Unis les définit comme des « Enabling Specifications » (spécifications habilitantes). Je lui ai alors dit de quoi il s'agissait, ajoutant qu'elles pouvaient être arbitrées en cour de justice. C'est ce dont nous avons besoin comme documents de conception. Il y a quelques temps, alors que je travaillais avec le responsable de Samsung TV dans la Silicon Valley, il m'a confié : « Je déteste nos spécifications de 300 pages. Elles sont difficiles à lire, difficiles à comprendre, et difficiles à mettre à jour. J'ai dirigé Apple TV pendant 10 ans et je n'ai eu que quatre spécifications de six pages chacune ! » Un produit principal ne devrait avoir que quelques spécifications, et celles-ci ne devraient avoir que six pages en moyenne.

James Coplien : Que pourrais-ajouter à cela ? ;-)

InfoQ : Comment le modèle Testable Improvement (amélioration testable) permet-il de mesurer l'amélioration dans les équipes ?

James Coplien : L'amélioration continue est le point de mire principal de Scrum, tout comme les décisions basées sur l'expérience empirique. Scrum reconnaît aussi que les systèmes complexes voient leur performance varier au cours du temps. Ce qui fait que même en ne faisant rien, la performance peut parfois augmenter, ou alors augmenter alors que l'équipe a fait un choix arbitraire. Il faut d'abord mesurer si la performance s'améliore selon un axe particulier, ce qui implique que le résultat doit être mesurable. Ensuite, mesurer si l'équipe a bien réalisé l'activité qu'elle supposait être capable d'améliorer sa performance. Enfin, mesurer si cette amélioration perdure dans le temps. Cette préoccupation apparaît aussi dans d'autres modèles comme Updated Velocity (vélocité mise à jour), bien qu'elle mette plus l'accent sur le fait que l'équipe dise ce qu'elle fait et fasse ce qu'elle dit. On retrouve une notion similaire dans le concept japonais d'ibai, qui est la conformité à la norme de travail.

Jeff Sutherland : Aujourd'hui, je forme les nouveaux Scrum Masters dans le Kata Toyota, la pensée kaizen. Tout obstacle est une amélioration en attente de devenir. C'est à chaque sprint qu'une équipe a besoin de prioriser l'amélioration qui va lui apporter le plus de bénéfices au moindre coût. Cette amélioration devrait être assez petite pour qu'on puisse mesurer son effet au sprint suivant. C'est fondamental pour le Lean, et Scrum dérive du Lean, via le papier de Takeuchi et Nonaka qui ont inventé le mot « Scrum ». Le modèle Testable Improvement montre à une équipe comment cela peut être mis en œuvre.

InfoQ : Comment peut-on appliquer les modèles pour adopter Scrum et créer des équipes efficaces ?

James Coplien : Plongez dans les modèles, laissez-les parler à votre moi le plus profond et à l'enthousiasme de l'équipe sur ce qui pourrait être amélioré. Essayez-en un à la fois en mesurant les résultats. Vous pouvez commencer par les modèles qui traitent vos faiblesses les plus criantes, ou par ceux qui engagent la passion de l'équipe. Ou vous pouvez simplement les appliquer les uns après les autres, un à la fois. Laissez chacun d'eux vous guider et vous inspirer au lieu de contraindre votre intuition sur la façon de mettre en place une solution.

Jeff Sutherland : Scrum est un ensemble de modèles, pas une méthodologie. C'est un cadre pour implémenter des modèles que les équipes excellentes ont utilisé de façon répétitive dans le monde entier, que ce soit dans le sport, l'industrie, le gouvernement, et même dans le milieu universitaire. Le Scrum Pattern Group a fait un magnifique travail en restant concentré pendant 9 ans pour livrer les modèles les plus importants afin qu'une équipe puisse les sélectionner et les mettre en pratique. Alors si vous rencontrez un problème, jetez un œil au livre Scrum Patterns. La solution sera peut-être dans l'un de ses modèles !

À propos des auteurs

James "Cope" Coplien (que l'on voit ici pratiquant une Amélioration Testable) est contributeur et Product Owner du livre « A Scrum book ». En tant que consultant, coach et éducateur, il sert les entreprises dans leur parcours lean et agile à tous les niveaux, des comités de direction aux bureaux de pair programming. Il fait aussi de l'architecture logicielle, et a co-créé le paradigme objet Données, Contexte et Interaction. Quand il sera grand, il voudrait être anthropologue.

Jeff Sutherland est un ancien pilote de combat et professeur de radiologie. C'est en utilisant la conception opérationnelle de sa formation de pilote de chasse et sa recherche sur les super-ordinateurs en médecine qu'il a co-créé Scrum et créé Scrum@Scale. Là où il est le plus heureux, c'est quand il appuie sur l'accélérateur de sa Tesla P100D et qu'il atteint les 100 km/h en 2,4 secondes.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT