Cet article est le premier d’une série destinée aux gestionnaires qui désirent mieux comprendre les méthodes agiles. Fort de sa pratique, notre collaborateur et expert Samuel Tremblay nous explique comment les intégrer efficacement au quotidien.

Dans le monde des organisations qui se considèrent comme agiles, une méthode domine toutes les autres : il s’agit du populaire cadre de développement Scrum. En effet, selon le State of Agile Report de la firme Digital.ai, 87 % des organisations agiles disent l’utiliser. C’est que les bénéfices du Scrum sont nombreux : collaboration renforcée entre les membres de l’équipe, plus grande autonomie de ces employés grâce à la décentralisation des décisions et délais de mise en œuvre grandement réduits.

Depuis la première apparition du terme en 1986 pour désigner une méthode inspirée de la mêlée du rugby (scrummage, en anglais) jusqu’à sa formalisation par Ken Schwaber et Jeff Sutherland en 1995, le Scrum est devenu aujourd’hui un cadre simple, accessible et répandu.

Un cadre de développement léger et peu prescriptif

C’est à la suite de la publication de l’article scientifique ayant codifié la méthode en 1995 que le «manifeste agile» (en anglais : Manifesto for Agile Software Development) a fait son apparition en 2001, signé par Schwaber, Sutherland et 10 autres personnes. Cet exposé mettait l’accent sur les principes suivants :

- Les individus et leurs interactions plus que les processus et les outils;

- Des logiciels opérationnels plus qu’une documentation exhaustive;

- La collaboration avec les clients plus que la négociation contractuelle;

- Et surtout l’adaptation au changement plus que le suivi d’un plan.

Sans directement citer ces principes, quoique parfaitement aligné avec eux, le Guide Scrum, un document d’une dizaine de pages faisant office de référence pour la méthode, a ensuite été publié en 2009. De ce maigre document ont par la suite été dérivés les certifications professionnelles, les implantations de la méthode et les outils informatiques en lien avec cette dernière, entre autres éléments. Au cœur de sa définition, un flou intentionnel des auteurs : «Le cadre de travail Scrum est volontairement incomplet, ne définissant que les parties nécessaires pour mettre en œuvre la théorie Scrum». Il faut donc retenir ici qu‘il est possible de demeurer conforme au Guide Scrum tout en englobant des pratiques, des processus et des méthodes qui existent déjà dans une organisation.

Comprendre les 3 rôles clés d’une équipe Scrum

Le Guide Scrum met de l’avant trois rôles, lesquels forment ensemble l’«équipe Scrum» :

1. Le responsable de produit (product owner) : ayant le rôle de maximiser la valeur (et donc les retombées) du produit développé par l’équipe, c’est lui qui décide des fonctionnalités du produit, les priorise et s’assure que ce qui est développé y répond. La liste de fonctionnalités qui sont favorisées représente d’ailleurs le carnet de produit (product backlog, en anglais). Le responsable du produit en question gère aussi la relation avec le ou les clients du produit ainsi que les différentes parties prenantes de l’organisation.

2. Le chef de mêlée (scrum master) : responsable de l’efficacité de l’équipe ainsi que du climat général qui règne en son sein, le chef de mêlée aide cette dernière, à travers le coaching, à se concentrer sur ce qui produit de la valeur et à respecter les standards minimaux de qualité. Lorsque l’équipe rencontre des problèmes ou se retrouve bloquée, c’est aussi lui qui met en œuvre ce qu’il faut pour qu’elle retrouve son erre d'aller. Ce chef est aussi responsable de la productivité des événements Scrum.

3. Les développeurs et développeuses : engagées à créer à la fin de chaque sprint une version utilisable du produit, ces personnes ne sont pas nécessairement toutes des ingénieurs logiciels ou informatiques, pouvant être des spécialistes variés. Ce sont elles qui font le plan du sprint, l'adaptant chaque jour, puis l’exécutant. Les développeurs ont à cet effet toute l’autonomie requise pour le faire.

Un fait intéressant à souligner ici est qu’il n’est nulle part fait mention du gestionnaire, que ce dernier soit hiérarchique ou plutôt chargé de projet. Bien que la question fasse l’objet de plusieurs articles complets et d’une multitude d’opinions, il est possible de la simplifier en deux théories : soit le gestionnaire joue l’un des trois rôles de l’équipe et l’intègre entièrement, soit il en devient le promoteur, travaillant dans l’ombre à son succès et intervenant lorsqu’on l’interpelle.

Faciliter la collaboration grâce aux 5 événements Scrum

Les événements Scrum sont organisés pour donner lieu à la transparence requise par une saine atmosphère de collaboration. Au centre du cadre de développement vient le sprint, lors duquel les idées deviennent de la valeur. Ce premier événement dure au minimum une semaine et au maximum un mois, une durée fixe dans le but de favoriser la consistance au sein de l’équipe. Chaque sprint se veut également le siège de quatre autres événements obligatoires que voici.

- La planification du sprint, mise en œuvre par le responsable de produit qui fait part aux autres de son ambition pour ce dernier. L’équipe Scrum sélectionne tout d’abord une quantité réaliste d’éléments du carnet de produit qui permettront de s’en rapprocher, détermine comment ces éléments seront effectués, puis formule un objectif pouvant être communiqué aux parties prenantes; le plan (ou carnet) de sprint est alors né.

- La mêlée quotidienne, qui constitue un moment pour que l’équipe Scrum puisse inspecter comment elle progresse vers l’atteinte de l’objectif de sprint. Ce n’est surtout pas une réunion de statut, car elle sert aux développeurs, et ceux-ci peuvent même l’animer (le chef de mêlée demeurant responsable de son efficacité). Typiquement, un tour de table prend au maximum 15 minutes et aborde autant les actions effectuées la veille que le plan de la journée ainsi que les problèmes rencontrés.

- La revue de sprint (ou démonstration de fin de sprint), qui survient à l’approche de la fin du sprint. C’est le moment de gloire de l’équipe puisque cette dernière peut alors montrer le travail dûment accompli tout en récoltant la rétroaction des clients (ou de leurs représentants), des collègues et des différents gestionnaires. Cette rencontre ne se veut pas une présentation, mais plutôt une vraie démonstration accompagnée d'échanges constructifs autour de l’état actuel du produit et des adaptations futures qui seront requises.

- La rétrospective de sprint, qui permettra la clôture du sprint en question grâce à un examen approfondi des processus, des interactions, des individus et des outils. La question à laquelle il faut répondre est la suivante : comment augmenter l’efficacité de l’équipe et le niveau de qualité général? Les bons et moins bons coups du sprint sont alors abordés, et tout problème requérant une discussion franche est amené sur la table par un des membres de l’équipe.