Chapitre 2

Les premiers pas

 

Dans ce chapitre :

• Quantifier les bénéfices de Scrum
• Structurer le rôle de propriétaire du produit
• Élaborer votre vision du produit
• Installer le rôle de Scrum Master
• Appliquer des pratiques communes-

 

« Le travail s’étend dans la durée jusqu’à occuper tout le temps disponible pour l’accomplir »

 

Loi de Parkinson

 

 

 

Comprendre Scrum, c’est plus facile en théorie qu’en pratique. C’est un défi que de changer 70 ans d’habitudes de développement de produit. Pourtant, gagner 30 à 40 % de temps pour lancer sur le marché, et économiser 30 à 70 % des coûts semble plutôt intéressant. Jeff Sutherland a recensé des gains de performance de 1 000 % en utilisant Scrum. Au regard de ce potentiel, cela vaut la peine de sortir de votre zone de confort pour vous attaquer aux dysfonctionnements organisationnels qui vous limitent.

 

Si la tendance numéro 1 dans l’informatique est de se convertir à Scrum ou à d’autres approches agiles (telles que eXtreme Programming), c’est que votre organisation peut entreprendre cette conversion elle aussi. Nombre d’entreprises s’y sont essayées, et s’en sortent bien. Il faut simplement faire preuve d’ouverture d’esprit – ce qui est bon pour tout le monde. À la fin de ce chapitre, vous serez prêt à démarrer votre projet en passant aux étapes Scrum suivantes.

Vous lancer dans Scrum

Il faut tenir compte de deux facteurs si vous décidez de vous convertir à Scrum :

•  La nature du projet
  Il est facile de savoir si la nature du projet permet de recourir à Scrum, car Scrum peut s’appliquer tout simplement à n’importe quel projet. Tout projet durant lequel vous souhaitez évaluer précocement la performance et la qualité peut, et devrait, être géré dans l’approche Scrum.
  
•  La culture dans laquelle baigne le projet

La question culturelle est plus complexe, car les gens sont complexes. Changer les processus, c’est facile ; changer les gens, c’est difficile. Tout individu et tout groupe d’individus ont leurs manières de penser et de faire. Cela permet d’enrichir les conversations lors d’un cocktail, mais cela peut aussi devenir un obstacle à surmonter lorsqu’il s’agit de faire adopter de nouvelles techniques de gestion de projet.

Les gens résistent naturellement au changement, et chacun résistera d’une certaine manière à un certain degré. « Rien dont il soit plus difficile de se saisir, rien qui soit plus périlleux à conduire, rien dont la réussite soit plus incertaine, que de guider l’installation d’un nouvel ordre des choses » – Machiavel.

 

Toutefois, la conversion se déroule plus rapidement et plus facilement lorsque les gens comprennent comment ils vont pouvoir bénéficier des changements.

 

Comme vous le verrez dans les Parties III à V de ce livre, des entreprises générant des milliards de dollars tirent profit de Scrum, tout comme des particuliers. Un de mes collègues a utilisé Scrum pour planifier, jour après jour, ses dernières vacances. Lui-même et sa femme reconnaissent qu’en étant ainsi parvenus à trouver la bonne combinaison de structure et de liberté, ce furent leurs meilleures vacances (voir le Chapitre 17 pour découvrir leur histoire).

 

Je vais maintenant passer en revue quelques-uns des avantages les plus communs qu’il est possible de tirer de Scrum.

Montrez-moi l’argent

Vous connaissez peut-être la formule de calcul de la valeur nette actuelle : un euro d’aujourd’hui vaut, littéralement, plus qu’un euro d’il y a six mois. Le plus gros problème dans l’organisation n’est pas l’efficacité des équipes d’exécution ; c’est la gestion de portefeuille. Les responsables ne parviennent pas à faire preuve d’assez d’autorité pour définir des priorités parmi les projets, si bien que beaucoup trop de projets se retrouvent à être pilotés à un niveau de management qui n’a pas assez de pouvoir pour les refuser (voir le Chapitre 12 pour en savoir plus sur le phénomène).

 

Le dysfonctionnement est ensuite masqué en dispersant les gens sur de multiples projets, afin de donner raison à chaque commanditaire de l’entreprise. Dans ces conditions, il faut beaucoup plus de temps pour parvenir à produire quoi que ce soit ; la direction est tenue au calme en lui livrant des tonnes de documents qui lui expliquent combien son produit sera superbe, si jamais il parvient un jour à l’obtenir.

 

Scrum est tout à l’opposé. Vous vous concentrez, vous produisez des résultats livrables tangibles, puis vous passez à l’étape suivante. Le backlog du produit (décrit en détail au Chapitre 3) vous impose d’être efficace avant de vous soucier de l’efficience.

 

Vous pouvez être une entreprise qui génère des milliards d’euros. Ou alors une start-up dans un garage qui se bat pour mettre une bonne idée sur le marché. Voire même, vous n’êtes qu’un salarié parmi d’autres. Quel que soit votre cas, vous avez l’occasion de prouver qui vous êtes avec le projet qui vous a été confié. Une priorisation rationnelle, une plus grande efficience, et des progrès progressifs systématiquement testés peuvent vous aider à survivre.

 

Grâce à la priorisation dans Scrum, vous pouvez vous consacrer exclusivement aux fonctionnalités à haute valeur ajoutée. Vous ne passez pas votre temps à perfectionner un gadget plutôt qu’une fonctionnalité indispensable. Vous allez à l’essentiel, encore et toujours. Il en résulte que ce que vous produisez au terme de chaque sprint correspond toujours à ce qui est le plus important, le plus pratique et le plus immédiatement désirable. À chaque livraison, vous apportez quelque chose qui présente une valeur pour le marché. C’est Scrum. C’est montrer où va l’argent.

Lorsqu’on a le dos au mur, tout le monde se convertit aux techniques agiles, qu’on en ait conscience ou non. Si votre entreprise n’a plus que 60 jours de liquidités, personne ne s’inquiétera du fait que votre rapport d’avancement n’a pas la bonne couverture. La bureaucratie est un luxe. Mais c’est aussi un luxe qu’on risque de ne plus pouvoir s’offrir du jour au lendemain dans l’économie d’aujourd’hui.

Lors de mes séminaires, j’enseigne qu’« il vaut mieux faire tout d’une partie que des parties de tout ». Si vous attendez que tout soit terminé, il y a de fortes chances pour que cela n’arrive jamais. Suivez plutôt la logique Scrum pour produire un flot de livrables que vous mettez un par un sur le marché, qui génère des réactions et qui fait rentrer de l’argent.

Appliquant mon principe de faire quelque chose avant de faire tout, un de mes clients a accepté de mettre un produit sur le marché en ne proposant au client qu’une seule manière de l’acquérir. Plutôt que d’attendre de pouvoir gérer des transactions avec toutes les cartes bancaires de la terre ou presque, avec PayPal ou même de pouvoir encaisser un chèque, le client a décidé de ne proposer de payer qu’avec une carte bancaire donnée. Le résultat ? Entre octobre et janvier, il a généré un million de chiffre d’affaires. Son site propose maintenant de payer avec diverses cartes, avec PayPal, et même via d’autres options – chacune a été mise en œuvre lors d’un sprint, une fois que le site a commencé à générer des revenus.

 

Scrum a pour objet de permettre la livraison de résultats testés et utilisables, très précocement et plus régulièrement. Vous n’attendez pas pour voir les résultats. Vous les constatez à l’issue de chaque sprint.

 

Scrum peut être un nouveau concept pour beaucoup, mais il est de plus en plus utilisé. En 2008, j’étais tout excité d’apprendre que de plus en plus d’organisations adoptaient des techniques agiles à la place de techniques dites « en cascade » pour développer des logiciels. En 2012, Forrester estimait que 80 % des organisations utiliseraient des techniques agiles pour développer des logiciels. En mai 2012, SimplyHired.com proposait 20 000 jobs nécessitant une connaissance de Scrum, et en mai 2013, le site en proposait 670 000. Nous avons bel et bien passé un cap.

Je le veux tout de suite

Vous avez déjà entendu la formule ? Et pas d’un gamin de trois ans, mais d’un patron, d’un collègue ou même d’une petite voix intérieure ? Nos projets Scrum parviennent généralement à réduire le temps de mise sur le marché de 30 à 40 %. Comment ?

 

C’est simple : en attaquant le développement précocement, et donc en terminant le développement précocement. Vous créez des produits livrables dès le début. Vous n’attendez pas des mois, voire des années, des résultats qui peuvent être entre-temps devenus technologiquement obsolètes. Vous planifiez, créez, évaluez, adaptez, livrez et engrangez les bénéfices rapidement. Lors de ce processus, vous créez de la valeur très tôt et en permanence.

En sciences comme en affaires, nous avons découvert que ce n’est finalement pas la loi du plus fort. C’est plutôt la loi du plus rapide. Celui qui pouvait se mettre à l’abri le plus vite a pu échapper aux griffes du ptérodactyle. Dans le monde des affaires, les innovations déboulent sur le marché à des vitesses qui augmentent exponentiellement. Des marques sont créées et tuées du jour au lendemain. Vous ne pouvez simplement pas vous permettre d’être en retard.

 

Mais ce n’est pas la seule raison pour laquelle le marché s’accélère. Comme vous créez un backlog du produit (la liste des courses du projet), vous pouvez aussi prioriser les éléments. Lorsque vous priorisez, vous devez tenir compte de deux choses :

•  les éléments qui ont le plus de valeur ;
•  les éléments qui présentent le plus de risques.

Ces deux facteurs déterminent quel élément est en haut de la liste.

Nous ne savons pas ce que nous souhaitons

La vaste majorité des gens, des entreprises et des organisations ne réalisent ce qu’ils veulent que lorsqu’ils peuvent interagir avec le produit ou le service directement. Or, c’est tout ce qui sépare l’approche en cascade de celle de Scrum : dans l’un, vous ne touchez que des documents, dans l’autre, vous touchez des réalisations.

 

Dans votre feuille de route de création de valeur (voir Chapitre 1), vous commencez par une vision de ce que vous souhaitez que soit votre produit final. La vision est un phare dans la nuit pour votre équipe. La feuille de route permet de prendre des décisions progressivement – partant de généralités assez floues jusqu’à des petites tâches opérationnelles bien concrètes. Si vous déviez de la vision, vous êtes en train de commencer un projet différent.

 

Votre vision peut être de développer un site Web sur lequel les gens peuvent commander des plats préparés par un restaurant spécialiste en allergies. Ou alors de construire une résidence pour patients atteints d’Alzheimer sous surveillance, avec tout un système d’alertes de sécurité ? Ou de vendre des recettes de gâteaux de grand-mère dont vous êtes convaincu qu’elles balayeront la mode des cupcakes ? Comment pouvez-vous réaliser chacun de ces projets, si différents ?

 

La manière dont ces idées prendront corps reste encore à déterminer. La bonne nouvelle, c’est qu’adopter Scrum, c’est emprunter la route la plus sûre pour progresser. La création, l’évaluation et l’adaptation sont les outils qui vous permettront de créer le produit dont le marché que vous visez a besoin.

Ce bogue est-il un problème ?

Tout ce que l’équipe de développement achève est testé et intégré pour s’assurer qu’il fonctionne. Le propriétaire du produit a la responsabilité d’accepter ou de rejeter chaque exigence réalisée quand elle lui est livrée. Autrement dit, si ça ne fonctionne pas, ça ne doit pas sortir du sprint.

 

Bien entendu, une fois qu’un produit a été mis en production, des problèmes peuvent survenir dans l’intégration, la montée en charge, etc. Mais le cycle d’amélioration continue est tellement au cœur du développement qu’aussitôt qu’un défaut ou qu’une faiblesse est repéré, il peut immédiatement être corrigé. La correction survient dans le sprint, mais elle peut aussi être injectée dans le backlog du produit pour être priorisée dans le futur.

La culture de votre entreprise

Les salariés découvrent vite comment Scrum améliore la communication et la collaboration, crée un esprit d’équipe visant l’excellence, entretient un cycle de vie naturel, contribue à créer un contexte d’honnêteté et de transparence, et responsabilise. Cela impacte grandement la culture d’entreprise, d’une manière très positive.

 

Le niveau de résistance au changement varie selon la culture d’entreprise. Comme pour bien des choses, la solution, c’est de démontrer que ça marche (souvenez-vous : personne ne peut contester un véritable succès !). Identifiez ce dont les gens ont besoin – plus de profits, plus de qualité, mettre sur le marché plus rapidement, ou retenir les talents plus efficacement – et montrez-leur ce que Scrum peut apporter en la matière.

 

Dans tout groupe de personnes, vous trouverez des personnes influentes. Ce sont celles qui ont du poids, et qui peuvent faire changer les choses. Faites-les monter à bord pour vous faciliter le travail. Parfois, cela signifie que vous devrez solliciter un niveau de management supérieur, mais ce n’est pas systématique.

Pour être engagé, il faut s’être impliqué. Vous devez bâtir une équipe qui y croit pour actionner la roue du changement.

Le pouvoir du propriétaire du produit

Le propriétaire du produit joue un rôle essentiel pour actionner la roue du changement. Sa mission première est de s’occuper de tous les aspects business du projet. Il doit maximiser la valeur du produit en assurant le meilleur retour sur investissement (ROI) à l’entreprise. Le propriétaire du produit n’est qu’une seule personne, pas un comité, et c’est un membre à temps plein de l’équipe Scrum. Il ne possède pas littéralement le produit, mais il prend à sa charge toutes les tâches relatives au business, en tant que représentant des parties prenantes et des clients.

 

Voici quelques-unes des responsabilités du propriétaire du produit :

•  Fixer les objectifs et la vision du produit, et notamment rédiger la vision.
•  Créer et maintenir la feuille de route du produit, qui donne une vision générale du produit et permet d’établir son backlog initial.
•  Définir les priorités au fil de l’eau et effectuer des arbitrages.
•  Assurer la visibilité du backlog du produit.
•  Optimiser le travail réalisé par l’équipe de développement.
•  Prendre la propriété et endosser la responsabilité entière du backlog du produit.
•  Accepter les exigences proposées (attentes client) et les prioriser dans le backlog du produit.
•  Fixer les objectifs des livraisons et des sprints.
•  Déterminer quels éléments du backlog du produit feront l’objet du prochain sprint.
•  Gérer tous les aspects business du projet, dont le ROI et les risques pour le business, et assurer l’interface avec les parties prenantes et les clients.
•  Être disponible toute la journée pour travailler directement avec les membres de l’équipe de développement, améliorant l’efficacité grâce à une communication claire et immédiate.
•  Accepter ou rejeter le produit d’un sprint, si possible le jour même où il est livré.

Je suis souvent choqué que des organisations qui songent à investir des millions dans un projet prétendent ne « pas disposer des moyens » de lui allouer un propriétaire du produit pour veiller à l’alignement des priorités du business et de la technique, et s’assurer que le produit réalisé sera bien celui souhaité. Beaucoup d’organisations ont un chef de projet pour diriger le projet. Comme le rôle de chef de projet n’existe pas dans Scrum (les tâches qui lui incombent sont distribuées entre les trois rôles de Scrum), l’argent nécessaire pour financer un propriétaire du produit pourrait venir de là.

 

Un propriétaire du produit clarifie, priorise et contribue à créer un environnement qui permet de se focaliser. Il s’assure que l’équipe Scrum est efficace. Le propriétaire du produit détermine quelles exigences doivent être satisfaites et quand il convient de les satisfaire, c’est-à-dire le « quoi et quand », mais pas le « comment et combien ». Le « comment et combien » est de la responsabilité de l’équipe de développement.

Supposons que votre passion soit de créer des choses. Dans Scrum, vous seriez membre de l’équipe de développement. Le propriétaire du produit sera alors pour vous un don du ciel. Il excellera dans la gestion du portefeuille, car il aura été investi du pouvoir de prendre des décisions, de clarifier, de prioriser et de se battre pour s’assurer que les membres de l’équipe puissent se focaliser sur un projet à la fois. Grâce à un propriétaire du produit efficace, les membres de l’équipe de développement sont isolés de tout ce qui pourrait venir les distraire et peuvent donc consacrer toute leur attention à faire leur travail.

 

Tant le propriétaire du produit que le Scrum Master travaillent pour créer le meilleur environnement possible pour l’équipe de développement afin qu’elle produise un travail de la meilleure qualité. Le propriétaire du produit intercepte tous les signaux provenant du business, tandis que le Scrum Master s’assure qu’aucun signal provenant de l’organisation ne vient gêner l’équipe de développement dans son travail.

 

Le bouclier créé par le propriétaire du produit et le Scrum Master ne signifie pas que le business n’a pas voix au chapitre : cela signifie que, la plupart du temps, ce n’est pas l’équipe de développement qui a affaire à la direction.

 

D’un autre côté, un membre de l’équipe de développement peut contacter les parties prenantes ou d’autres personnes directement lorsqu’il a besoin de clarifier un point sur lequel il travaille. Ce modèle, qui consiste à repousser les demandes de l’extérieur qui pourraient bouleverser les priorités à l’intérieur sans pour autant interdire à l’intérieur de s’adresser à l’extérieur, est un peu comme celui d’une membrane cellulaire conçue pour laisser passer certains fluides dans une direction, mais pas dans l’autre.

 

Il en résulte que l’équipe de développement est protégée des interférences extérieures, mais qu’elle n’est pas bloquée lorsqu’elle cherche des informations. Préserver la frontière est essentiel pour garantir le succès de l’équipe de développement.

Pourquoi les propriétaires du produit adorent Scrum

Un propriétaire du produit adore Scrum pour les raisons suivantes :

•  Le développement et le business sont dorénavant alignés et rendent compte comme un seul homme, plutôt que d’être à couteaux tirés comme dans les méthodologies antérieures.
•  Les plannings et les coûts sont anticipés sur une base pragmatique et vous disposez d’une vision quotidienne de l’avancement.
•  À l’issue de chaque sprint, le propriétaire du produit sait qu’il va pouvoir obtenir les éléments les plus attendus, fonctionnels et livrables.
•  Le client fournit un retour très tôt, et en permanence.
•  Il est possible de mesurer la rentabilité (ROI) après chaque sprint.
•  Scrum s’adapte aux changements des besoins du business, ce qui garantit la souplesse requise pour s’adapter aux réalités du marché.
•  Le gaspillage est limité du fait que le développement des priorités du produit prend le pas sur celui des artéfacts du processus (en général, le dossier d’analyse détaillée).

Le trait particulier du propriétaire du produit doit être sa capacité à décider. Il devra prendre des décisions difficiles et pragmatiques chaque heure de chaque jour. Il devra créer un environnement où la confiance règne, et où il est possible de pivoter lorsqu’il faut procéder à des changements. Il doit commencer par faire ce qu’il pense être bien, puis faire évoluer son jugement sur la base de preuves empiriques.

L’option agent du propriétaire du produit

En cette période de mondialisation, il n’est pas toujours possible de disposer d’un propriétaire du produit sur site. Vous pouvez parfaitement avoir votre siège à Paris ou Montréal et conduire des projets à Hyderabad, en Inde. Au fil de mon expérience de consultant, j’ai dégagé une solution controversée, mais praticable : le rôle d’agent du propriétaire du produit. C’est une personne se trouvant sur site qui est responsable de la communication et de la prise de décision au jour le jour. L’agent est un représentant physique du propriétaire du produit, parlant et agissant en son nom, puisque ce dernier n’est pas sur site.

 

L’agent du propriétaire du produit se présente ainsi :

•  Ce n’est pas un rôle officiel de Scrum.
•  Même si je ne recommande pas de recourir à un tel agent, je l’ai utilisé avec succès dans certains cas où l’organisation était assez mature.
•  Ce rôle n’est que temporaire ; c’est une phase d’apprentissage, le temps que la personne qui l’endosse prouve sa compétence pour devenir propriétaire du produit.

Grâce à l’agent du propriétaire du produit, vous disposez de quelqu’un qui peut fournir les clarifications et prendre les décisions exigées par Scrum. Toutefois, tout comme c’est le commettant qui assume la responsabilité des actes de son préposé, le propriétaire du produit basé au siège est responsable des décisions de son agent. La responsabilité ne se partage pas.

 

Plutôt que d’avoir un pied à chaque endroit et de générer des résultats marginaux, une meilleure solution consiste à installer le propriétaire du produit sur le site. Le coût peut sembler élevé à première vue, mais si vous tenez compte des gains de vitesse et de qualité du résultat, vous réaliserez que le coût global de votre projet s’en trouve réduit.

Le rôle de propriétaire du produit dans Scrum est très différent de celui d’un chef de projet traditionnel. Imaginez-vous dire à un golfeur qu’il doit réussir en un coup en partant de 100 mètres. S’il échoue, vous le menacez de le frapper avec son club. C’est un peu comme cela que fonctionne l’informatique traditionnelle. Avec Scrum, le golfeur frappe la balle, évalue les résultats, et s’adapte à la réalité pour parvenir au résultat de la meilleure manière possible selon l’endroit où il se trouve, et non celui où il devrait se trouver.

De petites équipes réunies au même endroit, couvrant plusieurs domaines fonctionnels, sont moins coûteuses que des équipes délocalisées lorsqu’on considère le coût de l’appropriation, plutôt que le coût par personne.

L’objectif et la stratégie de l’entreprise – Étape 1

La déclaration visionnaire ne fait pas partie de Scrum. Toutefois, le concept de déclaration visionnaire est utile et largement adopté. Les entreprises, les associations et les individus formulent souvent une déclaration de leur vision.

Lorsque je coache mes clients, je leur demande toujours de formuler une déclaration visionnaire pour que leur objectif leur apparaisse clairement. Je demande une déclaration courte, claire, frappante, qui peut être faite entre le rez-de-chaussée et le quatrième dans l’ascenseur où vous croisez quelqu’un qu’il faut convaincre.

Figure 2-1 : La déclaration de vision est l’étape 1 de la feuille de route de création de valeur.

Les déclarations visionnaires sont si utiles que j’en ai fait l’étape 1 de notre feuille de route de création de valeur. Reportez-vous à la Figure 2-1. Pensez à votre déclaration visionnaire comme à une destination repérée par un phare. Vous avez peut-être 100 manières d’arriver là, et peu importe celle que vous empruntez ; le tout, c’est d’arriver. Avec cette déclaration visionnaire, vous savez toujours où vous vous dirigez – vous avez le but en vue. De là, vous pouvez mettre en œuvre une infinité de tactiques.

 

Une déclaration visionnaire, c’est :

•  Focaliser sur l’essentiel, sans verbiage marketing.
•  Ajuster aux objectifs du marché et aux besoins du client final.
•  Stratégique par nature. Montrer quoi, plutôt que comment.
•  Réviser chaque année quand le projet s’étale sur plusieurs années.
•  Pour le propriétaire du produit, vraiment en prendre possession.

Votre déclaration visionnaire doit être communiquée à l’organisation ou au groupe de personnes avec qui vous travaillez. Que vous conceviez un nouveau modèle de voiture de sport ou que vous planifiez un mariage, chacun doit comprendre clairement l’objectif. La déclaration détermine les attentes et donne le ton du projet.

Structurer votre vision

Dans l’excellent livre de Geoffrey Moore, Sur la ligne de faille (publié par Maxima), l’auteur préconise une méthode efficace pour élaborer votre déclaration visionnaire. J’applique souvent son modèle, et cela produit toujours d’excellents résultats :

•  La déclaration ne doit pas dépasser deux ou trois phrases.
•  Geoffrey Moore recommande ce modèle :
  • • Pour <client cible>
  • • qui <expression du besoin>,
  • • le <nom du produit>
  • • est un <catégorie du produit>
  • • qui <avantages du produit, raison convaincante de l’acheter>
  • • contrairement à <alternative concurrente principale>.
  • • Notre produit <déclaration finale sur ce qui différencie le produit>
•  Je recommande d’ajouter cette conclusion :
  • • qui sert notre stratégie pour <stratégie de l’entreprise>.

Voici des exemples de ce que ce modèle permet de produire concrètement :

•  Chauffe-eau sans réservoir :
  • • Pour les propriétaires qui désirent disposer d’eau chaude en permanence et mieux conserver l’énergie, le chauffe-eau sans réservoir Acme Tankless est un chauffe-eau « à la demande » ou « instantané » qui chauffe efficacement l’eau lorsque vous l’utilisez. Contrairement aux chauffe-eau à réservoir, notre produit délivre un flot à température constante pour un coût de fonctionnement inférieur de 94 %.
  • • Qui sert notre stratégie pour servir les générations de demain en réduisant le gaspillage d’énergie aujourd’hui.

Cette déclaration visionnaire est fonctionnelle. La mention supplémentaire à la stratégie permet de lui ajouter une touche d’émotion. Donnez du sens à votre projet en l’inscrivant dans une stratégie d’entreprise qui vise le bien-être de chacun. La stratégie de votre entreprise n’est jamais d’enganger de l’argent ; c’est de faire quelque chose qui a tellement de valeur qu’il est possible d’en tirer de l’argent.

 

Lorsque je travaille avec mes clients, je leur demande de formuler leur déclaration visionnaire avant de les rencontrer pour la première fois. Je passe alors une heure avec ses auteurs pour lui donner une forme à partir de laquelle il est possible de travailler. Il ne faut guère de temps pour créer cette profession de foi.

S’appuyer sur le collectif

La déclaration visionnaire est créée et détenue par le propriétaire du produit et relève totalement de l’aspect business du projet. Toutefois, une personne n’est jamais que cela – une personne seulement. Le propriétaire du produit possède peut-être la déclaration visionnaire, mais il a tout intérêt à la produire et à la peaufiner avec l’aide d’une intelligence collective. Pour cela, le propriétaire du produit peut solliciter un retour de l’équipe de développement, du Scrum Master, de parties prenantes internes ou externes, et même des clients finaux en personne. C’est au propriétaire du produit de choisir, et il en est responsable.

 

Grâce à ces retours, il est possible de prendre conscience de nuances, de fonctionnalités et d’angles d’attaque du marché auxquels une personne seule n’aurait jamais songé. Le propriétaire du produit ferait bien de solliciter ces retours, puis de les filtrer soigneusement en fonction du sens qu’il donne au projet.

Le Scrum Master

Dans Le Manager Minute de Ken Blanchard (publié par Eyrolles), l’auteur explique comment les managers les plus efficaces qu’il ait rencontrés manquent parfois des compétences techniques détenues par leurs subordonnés. C’est amusant, mais ils ont aussi plein de temps disponible à ne rien faire. S’ils ne savent pas faire le travail eux-mêmes, à quoi donc peuvent-ils servir ?

 

Ces managers sont capables de déblayer le chemin pour que leurs subordonnés puissent faire leur travail. C’est le rôle d’un Scrum Master. Si le propriétaire du produit est un rôle de direction, le Scrum Master est un rôle de facilitation. Le Scrum Master a pour responsabilité de créer l’environnement propice au succès.

Le trait le plus fondamental du Scrum Master, au-delà de sa grande expertise de Scrum, c’est son influence. Diplomatie, compétences en communication et capacité à manager sont des atouts, mais le Scrum Master doit avant tout inspirer le respect et disposer d’assez d’influence pour résoudre les situations difficiles. L’influence est quelque chose que vous avez ou que vous n’avez pas. Peu importe d’où vous la tenez – expertise, longévité, charisme, empathie – du moment que vous en avez pour tenir le rôle de Scrum Master.

 

En tant que leader serviteur, le Scrum Master forme, encourage, aplanit les obstacles, et plus important : il fait disparaître les obstacles stratégiques pour que les obstacles tactiques ne réapparaissent pas. Comme pour tout rôle, celui de Scrum Master est mieux tenu lorsqu’il l’est par quelqu’un qui s’y consacre à temps plein, surtout dans les équipes, les projets et les organisations qui ont peu d’expérience.

Si le propriétaire du produit est le capitaine qui oriente le jeu et l’équipe de développement est l’avant qui progresse, le Scrum Master est le pilier. Tous sont engagés pour atteindre un même objectif.

 

Dans mon expérience, les développeurs qui jouent aussi les Scrum Masters et les Scrum Masters qui s’occupent de multiples équipes font perdre à l’équipe sa capacité à extrapoler la performance passée pour déterminer la performance future. Leur disponibilité varie, et cela empêche de protéger correctement l’équipe. Quantitativement, cela fait peu de sens, car une amélioration mineure dans la vitesse de l’équipe Scrum (j’en parle au Chapitre 4) a souvent un impact énorme sur le projet. Si votre équipe sait faire face à des changements dans son organisation et si elle est tellement mature qu’elle ne peut plus progresser, faites-moi signe ; je vais écrire sur votre cas miraculeux.

Une équipe de développement est idéalement composée de cinq à neuf personnes. On dit qu’un Scrum Master peut améliorer les performances d’au plus neuf personnes. De même, une réduction mineure de la performance aura un effet x9.

 

En plus de coacher l’équipe Scrum sur la manière de jouer au mieux le jeu de Scrum, le Scrum Master facilite les évènements Scrum – les réunions de planification de sprint, la revue de sprint et la rétrospective de sprint. Pensez-y : votre équipe est composée de membres intelligents, engagés dans ce qu’ils font. Rassemblez-les le temps d’une réunion, et leur énergie créatrice peut les faire exploser, ou du moins les faire partir vers des pistes divergentes. C’est au Scrum Master qu’il revient de diriger toute cette énergie.

Le concept de leader serviteur remonte aux environs de 500 ans avant J.-C, dans la Chine de Lao-Tseu, qu’on pense être l’auteur du Tao Te King. Il est aussi mentionné dans toutes les religions importantes et constitue un modèle populaire de leadership.

 

Le leader serviteur pense aux autres avant lui pour qu’ils puissent faire leur travail. Ce leader aide les gens à faire preuve de créativité plutôt que de leur présenter une solution toute faite sur un plateau d’argent. Si quelqu’un dit « J’ai faim », le leader serviteur ne lui donne pas un poisson. À la place, il dit « Comment puis-je t’aider non seulement pour ne plus avoir faim aujourd’hui, mais aussi demain et l’année prochaine. » Le Scrum Master aide une personne à acquérir des compétences et à trouver la solution qui lui convient le mieux, que la réponse se trouve dans le projet ou hors du projet.

Si vous prenez des décisions en tant que Scrum Master, c’est que vous ne faites pas votre travail. Une équipe de développement ne saura jamais s’auto-organiser si elle n’apprend pas à prendre elle-même des décisions. Un Scrum Master doit savoir s’extirper de la prise de décision au jour le jour et plutôt chercher à créer un environnement propice et protéger l’équipe des interférences.

 

L’influence du Scrum Master s’étend à toute personne impliquée, y compris les parties prenantes du projet et le propriétaire du produit. Le Scrum Master est un coach pour tout le monde, car chacun a besoin d’être en permanence formé et de voir son travail facilité dans Scrum.

Des études montrent qu’il faut 15 minutes pour atteindre le niveau de concentration optimal pour produire – pour « rentrer dedans ». Une interruption de seulement 2 ou 3 secondes suffit à faire exploser la bulle, si bien qu’il faut de nouveau 15 minutes pour revenir dedans. Une interruption de 5 secondes triple le nombre d’erreurs commises lors d’une série de tâches.

 

Si le Scrum Master protège l’équipe de développement des interférences extérieures, la vélocité de cette dernière croît considérablement. Songez comme vous travaillez bien lorsque la porte est fermée, le téléphone décroché, et tout le monde parti ou endormi, en comparaison des moments où vous êtes constamment interrompu par vos collègues, les membres de votre famille ou votre chien ?

L’enjeu des interférences

On trouve trois sources d’interférences majeures au travail.

 

Les interruptions personnelles sont les emails, les appels téléphoniques de tante Yolande et les messages avec liens renvoyant sur des vidéos YouTube. La solution, c’est de se discipliner. Coupez toutes ces technologies pour vous concentrer sur votre travail. Reportez-vous à la technique Pomodoro, présentée plus loin dans ce chapitre.

 

Les interruptions collectives sont le fait de vos collègues. La clé, c’est de faire la part entre le temps pour collaborer et le temps pour se concentrer. Ces temps doivent être déterminés en fonction de la dynamique du groupe et des besoins du projet :

•  Le temps pour collaborer correspond aux moments où vous pouvez être interrompu, parler et échanger des idées. C’est un temps sain et productif, et il doit représenter l’essentiel de votre journée.
•  Le temps pour se concentrer peut être matérialisé à l’aide d’indicateurs ostensibles : le port d’un casque antibruit, un panneau Ne pas déranger, et ainsi de suite. Ils vous aident à rester concentré et à produire.

Les interruptions externes sont le domaine du Scrum Master. Ces interruptions peuvent survenir à tout instant et tous les jours. Le Scrum Master est là pour en protéger les membres de l’équipe.

 

D’où viennent généralement ces interruptions ? De la hiérarchie qui court-circuite les urgences tactiques de l’équipe pourtant responsable de la qualité du produit. C’est une des raisons pour lesquelles le rôle de Scrum Master devrait être à temps plein, et pour lesquelles il devrait avoir pleine influence sur l’organisation.

Même lorsque les interférences extérieures sont réduites au minimum, la densité sociale étant plus importante dans Scrum, il n’est pas inhabituel que les conflits soient plus intenses. La pression intrinsèque pour parvenir à fournir des produits fonctionnels dans le bref temps des sprints avec des personnes qui sont physiquement proches peut être usante. C’est pourquoi le Scrum Master a aussi pour mission de gérer les conflits au bon niveau :

•  Les conflits professionnels sont sains (vouloir se battre pour ce que vous pensez être bien).
•  Les conflits personnels ne sont pas sains (lorsque le conflit dégénère de la remise en question d’une idée à la remise en question de celui qui la défend).

La technique Pomodoro

La technique Pomodoro est une technique de gestion du temps développée vers la fin des années 80 par Francesco Cirillo. Elle consiste à conduire des sprints personnels de 25 minutes (mais vous pouvez ajuster la durée) pour parvenir à faire votre travail :

1. Créez votre liste de tâches et priorisez les points les plus importants.
2. Travaillez sur l’élément prioritaire durant 25 minutes.
3. Faites une pause de 5 minutes.
4. Reprenez votre travail sur l’élément prioritaire jusqu’à l’avoir terminé, puis passez à l’élément de priorité suivante.

Après quatre Pomodoros, faites une pause prolongée de 15 à 30 minutes pour récupérer votre capacité à vous concentrer.

 

Faites cela toute la journée pour accomplir toutes les choses importantes que vous devez faire.

Pourquoi les Scrum Masters adorent Scrum

Les Scrum Masters adorent Scrum pour plusieurs raisons :

•  Ils peuvent chercher à avoir un impact quantifiable plutôt que de se consacrer à des tâches administratives – une plus grande vitesse de production a un effet direct sur la valeur ajoutée que l’équipe Scrum peut produire.
•  Ils coachent les gens au lieu de leur servir de managers générateurs de formulaires d’avancement.
•  Ils libèrent le potentiel des personnes plutôt que de les diriger.
•  Ils participent à moins de réunions, et les réunions auxquelles ils participent durent moins longtemps.
•  Ils facilitent la construction d’équipes autonomes, qui savent se motiver toutes seules, qui pensent par elles-mêmes et qui agissent avec autorité.
•  Ils n’ont pas à rendre compte des performances (par exemple, « Hello Jean, quel est le statut des tâches sur lesquelles Marie travaille ? ») ; ce sont les personnes qui doivent rendre directement des comptes.

La devise d’un bon Scrum Master, c’est Ne Jamais Déjeuner Seul. Il doit toujours chercher à créer et à développer des relations. L’influence est votre outil de travail, alors veillez à créer un environnement où vous pouvez facilement décrocher le téléphone, aller voir quelqu’un à son bureau, et obtenir des informations.

Les bons rôles hors de Scrum

Le propriétaire du produit et le Scrum Master sont des rôles essentiels de Scrum. Ils ont été conçus par les fondateurs de Scrum et sont présents dans tout projet Scrum. Bien entendu, le troisième rôle est l’équipe de développement elle-même. J’en parlerai plus en détail au Chapitre 4. Toutefois, comme toute bonne chose, la gestion de projet évolue et se développe. Scrum demeure un cadre solide. Quelques pratiques courantes et prouvées peuvent l’enrichir.

 

Durant mes années de travail avec Scrum, j’en ai inventé quelques-unes et j’en ai emprunté d’autres. Quoique les deux rôles suivants ne figurent pas dans Scrum, j’ai trouvé qu’ils apportaient énormément de valeur et de clarté lorsqu’ils étaient utilisés à bon escient.

 

Prenez en considération les deux rôles suivants dans votre projet ; ils pourraient rendre vos efforts plus efficaces.

Les parties prenantes (stakeholders)

Les parties prenantes peuvent être internes ou externes ; ce sont des personnes qui impactent ou qui sont impactées par votre projet :

•  Les parties prenantes internes font partie de votre entreprise ou de votre organisation.
•  Ce peut être des personnes du juridique, du commercial, du marketing, du management fonctionnel, des achats ou de tout autre service, branche ou division de votre groupe.
•  Les parties prenantes externes peuvent être des investisseurs ou des clients.

Quoique Scrum ne préconise pas la création de ce rôle, les parties prenantes existent et interagissent avec l’équipe Scrum. Aussi préférons-nous accepter la réalité et leur donner un rôle pour mieux pouvoir les gérer.

Le propriétaire du produit est l’interface business de l’équipe Scrum, si bien que les parties prenantes ne devraient travailler avec l’équipe de développement que via le propriétaire du produit. Les parties prenantes peuvent communiquer directement avec l’équipe de développement lors des revues de sprints, ou lorsqu’un membre de cette équipe les contacte directement pour obtenir des clarifications, mais les parties prenantes interagissent généralement avec le propriétaire du produit.

 

Qui gère les parties prenantes ?

•  Si elles se trouvent du côté du business (par exemple, des clients, des équipes commerciales ou marketing), le propriétaire du produit est généralement responsable.
•  Si elles se trouvent de l’autre côté (par exemple, des vendeurs ou des sous-traitants), c’est généralement le rôle du Scrum Master.

L’essentiel est de reconnaître leur influence et de s’appuyer dessus, tout en protégeant l’équipe de développement d’interférences qui pourraient en résulter.

Faire des trous pour réussir

Il y a des années, je me suis mis au golf pour le business, et je me suis épris de ce sport. Je l’ai adoré, je l’ai travaillé, et j’ai amélioré mon niveau. Pourtant, je devais toujours lutter contre mon inconsistance. Si rien ne pouvait m’arrêter certains jours, je me débrouillais d’autres jours comme un singe échappé d’un zoo, incapable de la moindre bonne frappe.

 

J’ai donc fait ce que bien d’autres font : je me suis offert les services d’un coach. Admettons-le : j’avais de gros doutes sur cet individu qui gagnait des centaines d’euros par heure et qui clamait pouvoir corriger mes défauts. Si j’avais pratiqué des années sans faire de progrès, que pouvait m’apporter quelqu’un qui ne m’avait jamais vu jouer ?

 

Lors de ma première session, il a placé une balle sur le tee, et je l’ai frappée. Un swing, c’est tout, et il a dit « Je sais quel est votre problème ». J’ai ri. Comment pouvait-il savoir ce que je faisais mal en n’ayant observé qu’un de mes swings ? J’étais persuadé d’avoir perdu mon argent. Puis il a dit, « Vous jouiez au base-ball, non ? » Ooops. Oui, j’avais joué au baseball des années. Il était parvenu à le deviner en observant ce seul swing.

 

En fait, mon swing de golfeur était mon swing de joueur de base-ball – une habitude que j’avais développée durant des années dans mon ancien sport, et que j’avais importée dans le nouveau. Lorsque vous vous convertissez à Scrum, vous importez de vieilles habitudes, certaines que vous ne réalisez même pas avoir développées au fil d’une vie à gérer des projets différemment, souvent en appliquant une approche en cascade.

Le mentor Scrum

Je vais illustrer ce que je veux dire exactement lorsque j’affirme que Scrum est un cadre simple en théorie et difficile en pratique. On peut dire la même chose du golf. Théoriquement, vous frappez une balle immobile avec un bâton pour la faire tomber dans un trou, en le moins de coups possibles. Pourtant, ce n’est pas facile. La raison en est que le golf est, comme Scrum, tout en nuances. Des petits facteurs peuvent générer une énorme différence dans la performance.

 

L’intérêt du mentor Scrum, c’est qu’il n’est pas aussi focalisé par l’urgence de sortir le produit. Ses lunettes ne sont pas teintées par les jeux politiques dans l’organisation. Tout comme le coach de golf, il sait prendre du recul et voir ce que vous faites mécaniquement. Il peut identifier non seulement les vieilles habitudes, mais il peut aussi mettre un coup d’arrêt aux « modifications » apportées à Scrum qui consistent en fait à retomber dans une vieille méthodologie.

 

Vous réussirez d’autant mieux avec Scrum que vous en préservez la pureté. Le travail d’un mentor Scrum, c’est de vous aider justement en cela. Tout comme un coach de golf, il peut se tenir à côté, observer vos vieilles habitudes improductives ; et vous aider à adopter de nouvelles habitudes qui vous permettront de réussir.