Cette semaine, j’ai choisi le guide Scrum édition novembre 2017 de Ken Schwaber et Jeff Sutherland. Une lecture courte (22 pages) et très intéressante sur le sujet d’un « cadre de travail pour résoudre des problèmes complexes d’adaptation, tout en livrant de manière productive ». Je l’ai lu en détail et je me prête au jeu de l’analyser comme s’il avait été écrit récemment.

Un mot sur l’auteur

Mon expérience du Scrum est très limitée. J’ai lu le guide Scrum pour la première fois en diagonale cette année. Ma formation académique est technique et mon expérience professionnelle est essentiellement du côté de la gestion de projet en mode chaotique.

J’explore depuis récemment (2010) le Lean Management, le Kanban et la gestion quantitative. Je lis beaucoup sur l’Agilité depuis les débuts du manifeste, mais j’ai surtout exploré Extreme Programming du temps où je produisais encore de la valeur pour mes clients. Toute opinion comprise dans ce texte est un reflet de ce cheminement.

Avant de commencer

Je crois important de clarifier un point clé concernant la méthode Scrum que j’ai compris très récemment. La méthode n’est pas née de l’Agilité. Scrum existe depuis 1996 (officiellement) alors que le manifeste Agile a été publié en 2001. C’est seulement en 2004 qu’on peut voir une mouture aux teintes d’Agilité dans Agile Software Management with Scrum, et plus tard en 2011 dans le Scrum Guide. La dernière mise à jour (novembre 2017) est celle qui s’approche le plus d’une méthodologie Agile, mais il est difficile de dire que Scrum = Agile, puisque l’Agilité n’est pas son point de départ.

Il est donc plus juste de voir Scrum comme une évolution ou une amélioration de l’approche traditionnelle de gestion de projet mieux adaptée au contexte incertain de la livraison logicielle.

L’excellent

• La légèreté du cadre est probablement son point fort. Je connais peu de cadres méthodologiques qui tiennent dans vingt pages. L’avantage certain, c’est que tous les membres d’un projet ou d’un produit structuré en Scrum peuvent lire le guide et ainsi comprendre. À mon avis, la lecture du guide devrait même être obligatoire pour ceux qui participent au cadre;
• L’idée d’une méthode de contrôle empirique était révolutionnaire dans le monde de 1996 où l’on planifiait tout à l’avance autour de fausses certitudes. Elle est encore révolutionnaire dans certains milieux qui ont peu évolué sur cet enjeu;
• La flexibilité du cadre est un point fort. Même s’il est écrit textuellement que Scrum a été conçu avec une approche produit en tête, on indique aussi qu’on peut s’en servir pour livrer des services. En gros, si le travail exige de réfléchir avant d’agir pour atténuer le risque, Scrum peut améliorer tout;
• La transparence est l’un des piliers de Scrum, et d’à peu près toutes les méthodes de gestion du 21e siècle;
• L’idée d’avoir un facilitateur professionnel (le Scrum Master) dans l’équipe est excellente. Tellement de projets s’effondrent pour cause de mauvaise communication. D’avoir quelqu’un qui stimule et facilite les interactions est probablement la meilleure chance que ça reste un focus tout au long du projet;
• L’auto-organisation de l’équipe est aussi un point fort de la méthode. Il n’y a pas d’efficacité sans auto-organisation;
• Les cadences sont un excellent moyen de rythmer le processus de livraison. On fixe un but, on se coordonne chaque jour, on s’arrête pour examiner nos succès/échecs et apprendre. Personnellement je n’y vois que du bon, tant que ces cadences sont découplées.

Le bon

• Le pilier d’adaptation est bon dans un contexte Agile. Par contre, le texte qui accompagne transpire l’inspiration traditionnelle du suivi du plan. Si on veut s’adapter, c’est pour retourner au plan. Que fait-on quand l’écart au plan est souhaitable? Scrum ne nuance pas sur ce point;
• Avoir un Scrum Master qui s’occupe des obstacles, c’est bien, mais pas si le système n’est pas à WIP limité. Résoudre des bloquants représente du travail actif et si c’est le SM qui prend ça à sa charge, il permet à l’équipe de démarrer de nouveaux travaux. On assiste alors à une surcharge du système;
• Scrum veut s’attaquer au problème des dépendances en fixant le périmètre de l’équipe : « Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team« . Personnellement, je n’ai pas rencontré souvent d’équipes qui soient entièrement auto-suffisantes pour livrer un incrément de valeur;
• Le Product Owner est bien placé dans un contexte où il cultive des idées, des objectifs et des options. Il est crucial pour la préparation de ces options en items prêts à développer lorsqu’elles sont sélectionnées. Par contre, s’il gère un backlog itemisé d’avance, son rôle devient tactique (au lieu de stratégique) et il ne sert que de proxy entre l’équipe et le client. Rappelons que les valeurs Agile nous suggèrent de favoriser la collaboration avec le client et les interactions entre les individus. Un contact direct entre l’équipe de développement et le client est clairement favorable. « Customer on site » comme on dit en Extreme Programming.

Le moins bon

• La base fondamentale de Scrum est l’équipe. La petite équipe de développement (3 à 9 personnes selon le guide). Les travaux de Troy Magennis à ce sujet indiquent qu’on devrait favoriser 5 à 9 personnes seulement si les performances de l’équipe sont plus importantes que sa prévisibilité et que l’équipe est plus importante que le système. On devrait augmenter à 15 si on peut couper une dépendance et si on veut un système plus stable et prévisible. Il faut faire attention à l’optimisation locale (l’équipe), qui cause presque toujours une sous-optimisation globale (l’écosystème de projet);
• L’utilisation du mot « complexe » est un peu abusive tout au long du guide. Les travaux de Dave Snowden au niveau du Cynefin framework ont permis de mieux définir la complexité. Peut-être qu’en 1996 développer du logiciel était complexe, mais vingt ans plus tard, on voit plutôt des systèmes de livraison compliqués et simples. L’écosystème de la forêt amazonienne est complexe;
• « The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide« . Nous sommes loin de la valeur Agile « People over Process » si le soucis premier du Scrum Master est le processus Scrum. Le paragraphe qui suit est parfait et le guide gagnerait à retirer cette phrase sans rien perdre de son essence;
• Le sprint à durée fixe est probablement le lieu de toutes les discordes dans le monde Agile. Un excellent article récent de John Cutler résume bien les avantages et inconvénients de cette mécanique. Je sens encore beaucoup l’influence de la charge de projet traditionnelle avec des échéances et des évaluations, juste en plus petit.

Les mythes

• J’avais entendu dire que le « scope » ne devait pas changer durant le sprint. Selon le guide, c’est faux . C’est le « Sprint Goal » qui ne peut pas changer. Le « Sprint Goal » n’étant absolument pas la somme des éléments de « scope » sélectionnés;
• Je n’ai vu à aucun endroit qu’on doit vider le travail en cours (WIP) à la fin d’un sprint. D’un point de vue flow et variabilité, c’est d’ailleurs une très mauvaise idée;
• Je n’ai pas lu une seule fois le mot « User Story« . J’ai personnellement toujours préféré un découpage en « Features« . Les histoires et les épiques viennent de la communauté Agile, et non de Scrum directement;
• Je n’ai pas lu non plus qu’on devait utiliser des « Story Points » ou de la « Vélocité ».

Les perles

Voici quelques phrases que j’aurais aimé voir imprimées sur des affiches lors de mes quelques incursions en territoire Scrum:

• During the Sprint: Quality goals do not decrease;
• The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint;
• À propos du Sprint Backlog: « To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. »

En résumé

Je pense que Scrum tient la route dans sa grande majorité s’il est appliqué comme décrit dans le guide. Il s’agit clairement d’un pas dans la bonne direction en comparaison avec la gestion de projet traditionnelle. À la lecture, on sent le désir des auteurs d’être Agile, mais il y a des relents forts de traditionalisme dans la manière dont les idées sont communiquées. J’aurais tendance à le conseiller si les rôles décrits dans le guide sont déjà présents dans l’organisation sous une autre appellation avec des responsabilités similaires.

J’ajouterais que comme n’importe quelle méthode ou méthodologie, c’est lorsqu’on ajoute des humains avec des expériences et des visions variées que la magie opère. Comme le disent si bien mes collègues, « Scrum, c’est beaucoup plus riche que ce que le guide expose. »