Le Product Owner, la Team et le ScrumMaster

Dans des organisations ankylosées, l’aspect « poil à gratter » de Scrum représente la thérapie miracle. Le mode d’emploi de la blague est simple : essayez de mettre en œuvre les trois rôles décrits ici en chargeant un ayatollah de la méthode de remettre dans le rang les récalcitrants de la ligne droite officiellement tracée par Scrum.

Comme vous l’avez certainement constaté à la lecture des précédents articles, je ne suis pas un inconditionnel de Scrum. Néanmoins, j’utilise  sans état d’âme sa partie « utile » puisqu’elle n’est en fait qu’un simple sous-ensemble des  premières méthodes Agiles (le pilotage du lotissement). Ayant participé depuis 1991 à de nombreux projets en mode incrémental-itératif-adaptatif (les trois concepts nécessaires aux développements agilisés des systèmes d’information), on comprendra aisément que je ne puisse me contenter d’une approche ne mettant réellement en œuvre que la notion d’incrément et faisant l’impasse sur tout le reste. Pourtant, exceptionnellement, je vais faire l’apologie de Scrum en tentant d’expliquer en quoi ses trois rôles sont relativement utiles – surtout lorsque de vrais ayatollahs de la méthode en défendent le principe.

Sur le fond et dans la forme

La notion philosophique d’équipe englobant à la fois le responsable métier, l’animateur et l’équipe de développement par elle-même est une chose magnifique. Mais… il est de notoriété que « lorsqu’une chose semble trop belle pour être vraie, c’est généralement qu’elle est fausse ».  Notre trio de rêve n’échappe malheureusement pas à ce dicton –  car  la qualité applicative (qu’elle soit fonctionnelle ou technique) est antagoniste de la performance du projet. C’est évident et particulièrement compréhensible lorsque la réalisation fait l’objet d’un forfait traitée en externe. Si vous ne me croyez pas jetez un œil sur les greffes des tribunaux de commerce ou même de grande instance qui statuent ensuite sur les responsabilités des échecs de projets exécutés en « faux Scrum » ou en mode Agile « dégradé ».

Chercher dans Scrum des solutions concrètes à ce genre de difficultés est illusoire. Par contre, si vous aimez les problèmes organisationnels, vous ne serez pas déçus. Mais attention, tout problème induit généralement une réflexion et c’est ce principe qui anime la grande force de Scrum.   Pour le reste, toutes les autres méthodes Agiles (RAD, FDD, ASD, etc.) utilisaient déjà les réunions quotidiennes, le découpage en incréments, l’optimisation de la valeur, les rétrospectives et même d’autres techniques additionnelles à la maitrise des projets de développement applicatif. Donc, ce n’est pas là qu’il faut chercher la révolution, au contraire vous ne trouverez qu’une régression.

Le point indiscutablement révolutionnaire de Scrum, se situe dans la mystique de ses « rôles » – lorsqu’ils sont réellement compris   –  et dans la puissance et l’efficacité de son inénarrable sac de « poil à gratter » organisationnel. C’est aussi à ce niveau que l’aspect « biblique » des interventions des vrais ayatollahs de la méthode se justifie par les crispations qu’elles induisent. Détaillons la chose appliquée aux trois rôles définit par Scrum : l’équipe, le Product Owner et le ScrumMaster.

1 - L’équipe (La team pour les puristes du franglais).

Pas grand-chose à dire sur ce sujet. Tous ses membres ont le même statut. N’ayant plus de chef, elle s’auto-organise.  Ne vous réjouissez pas trop vite de cette simplicité, la suite arrive et, en l’attendant, allez-donc expliquer cette finesse à vos chefs de projets. De plus, lorsque l’on parle d’auto-organisation, cela impliquait pour Schwaber un groupe soudé, motivé, extrêmement compétent et parfaitement rodé (comme son équipe quoi…). En clair, surtout dans les grandes organisations aux processus standardisés, ce droit ne s’applique sérieusement qu’aux experts après plusieurs projets réussis.

 2 – Le métier et les utilisateurs finaux (the Product Owner, le PO)

Dans le respect de la méthode Scrum, nous ne considèrerons plus les problématiques d’un « projet » (ce qui justifie la disparition du chef), mais focaliserons uniquement sur la problématique du « Produit », d’où l’apparition d’un PO. Il découle de cette révolution, d’une part que l’équipe aura pour seule responsabilité les aspects techniques de la qualité de production. Et, que d’autre part, la planification et le pilotage de la réalisation deviendront la responsabilité exclusive du Product Owner (donc du métier). Cela inclut bien évidemment le reporting d’avancement sur la base d’un graphe  (généralement un Burn Up Chart). Il vous faudra donc former vos représentants métier à ces techniques.

Ps. Dans le cas où vous arriveriez à leur faire accepter tout cela, n’hésitez pas à m’en informer, à pavoiser et, pourquoi pas, à le publier.

Bien évidemment, cet aspect « reporting » n’est qu’un détail. Les  changements les plus importants pour le métier se situent dans l’aspect « Spécifications générales des besoins ». Elles seront exprimées sous la forme idyllique de « récits utilisateurs ». Lesquels seront d’un niveau assez léger pour être « agile », tout en étant suffisamment détaillés pour en permettre la compréhension et obtenir une évaluation par l’équipe de réalisation. Le tout sera néanmoins exhaustif car il engagera moralement les parties sur la promesse d’un périmètre justifiant un « contrat projet ». Ce dernier point est important, car il en découle la taille de l’équipe, la durée et le nombre de sprints (faudra m’expliquer comment faire cela avec des points de complexité n’ayant pas d’équivalent jour). Pour finir, comme aucun développement de récit utilisateur ne pourra être débuté par l’équipe si les cas de tests fonctionnels n’ont pas été formalisés par le Product Owner en préalable, il faudra donc former le métier à ces aspects qu’il ignorait joyeusement jusqu’ici. Membre à part entière de l’équipe, c’est en permanence que ce PO devra spécifier avec les développeurs le détail de son besoin et surtout d’en tester régulièrement la conformité. Rappel : en théorie, c’est encore lui  qui fait évoluer le graphe d’avancement. 

Ps. Dans le cas où vous arriveriez à leur faire accepter tout cela, n’hésitez pas à m’en informer, à pavoiser et, pourquoi pas, à le publier.

3 - Le ScrumMaster

Premier postulat Agile :  le ScrumMaster, appelé plus modestement mais plus précisément « Animateur » ou « Facilitateur » par les autres méthodes Agiles, doit être indépendant des deux parties engagées dans le projet (selon la théorie de Scrum, elles ne feraient plus qu’une, tant tout le monde il est beau et tout le monde il est gentil). Première question : en admettant qu’il est été correctement formé, de qui dépend l’animateur et qui le paie ? C’est à partir de ce simple point que le déraillement à ce niveau commence. Parmi les autres errances on verra apparaitre la récupération de ce rôle par l’équipe de développement. Plus généralement, comme Scrum a remplacé la notion de chef de projet (généralement celui qui réglait  les problèmes) par celle de responsabilité collective de l’équipe, le chef de projet ayant réussi à survivre s’attribue généralement ce rôle. Autre option originale : les membres de l’équipe se partage le titre lors d’une rotation plus ou moins régulière. Résumons, sur la base d’un vocabulaire franglisant, nous avons créé un titre mais rien changé de l’organisation. En clair, l’indépendance critique de l’analyse des rapports entre les deux parties – qui a toujours été le seul intérêt de ce rôle –  à disparue.

Comme je le répète depuis le début des méthodes adaptatives et surtout depuis 2001 avec PUMA, notre métier est complexe et nécessite une permanente évolution des outils, des compétences et des organisations. Comme généralement ces organisations sont ankylosées, voire paralysées, l’aspect « poil à gratter » de Scrum va devenir la thérapie miracle. Le mode d’emploi de la blague est simple : essayez de mettre en œuvre les trois rôles qui viennent d’être décrit en chargeant notre ayatollah de la méthode de remettre dans le rang les récalcitrants de la ligne droite officiellement tracée par le Guide de mise en œuvre de Scrum. Le plus drôle arrive alors, et tous les diables de l’organisation sortent des boites où ils étaient bien cachés !

En matière de thérapie organisationnelle, Scrum ce n’est pas de l’aspirine pour soigner la gangrène, c’est  un choix entre l’amputation acceptée ou la fuite « sauve qui peut » du genre de la fin des émissions de Benny Hill.