Ce qui va suivre est ma vision personnelle du framework agile Scrum. Je ne revendique en aucun cas l'universalité de cette vision :)
Développeur depuis quelques années, j'ai été dès mon premier stage sensibilisé aux méthodologies agiles. Et comme beaucoup, j'ai commencé en appliquant la méthode Scrum. Il faut savoir que dans ma société – comme dans beaucoup d'autres – il n'est pas rare de croiser des gens pour qui l'agilité, c'est forcément du Scrum.
La promesse initiale de ce framework est simple : on cherche à délivrer rapidement de la valeur, en découpant le backlog en petit packages sur lesquels on va se concentrer durant un sprint. Un sprint est un découpage temporel d'une durée variable selon les projets – de mon côté c'est très souvent deux semaines. Il commence par un Sprint Planning, une réunion pendant laquelle l'équipe prévoit ce qu'elle est capable de réaliser pendant le sprint. Puis il s'achève avec une Sprint Review, une réunion pendant laquelle on revient sur le travail réalisé, ainsi qu'une Sprint Retrospective, une réunion pendant laquelle on cherche à améliorer le fonctionnement de l'équipe en tirant les leçons du sprint écoulé. Tous les matins pendant le sprint, l'équipe se réunit pour une réunion très courte nommée Daily Scrum pendant laquelle chacun partage son avancement, ce sur quoi il prévoit de bosser dans la journée et les éventuelles difficultés rencontrées.
Ce long paragraphe (pour lequel je m'excuse) peut être résumé par ce schéma :
Ces quatre réunions que j'ai citées sont aussi appelées cérémonies ou rituels du Scrum. Et pour chacune d'elle, vous pourrez trouver des règles très précises (bien que fluctuantes selon les sources) sur comment les structurer au mieux.
Et je ne sais pas pour vous, mais tout cela me semble personnellement très rigide : c'est un cadre de travail normalisé avec des règles très précises à suivre pour l'équipe. Des rôles sont également identifiés avec chacun des responsabilités définies. A mon sens, cela s'est toujours opposé à la première valeur de l'agilité :
Individuals and interactions over processes and tools.
Cette citation issue du manifeste agile stipule que les individus et leurs interactions sont à préférer à des processus et des outils. Il semble donc que Scrum ait tout raté à ce niveau-là ! Et c'est ce qui m'a le plus dérangé avant de comprendre le véritable rôle de Scrum dans l'agilité :
Scrum, c'est les petites roues de l'agilité !
Dans l'agilité, on considère que l'équipe va progressivement améliorer son mode de fonctionnement. Elle découvre donc de meilleures manières de procéder et on fait confiance aux membres de l'équipe pour chercher à tendre vers cet idéal.
Mais les débuts d'une équipe sont compliqués : les membres ne se connaissent pas et n'ont jamais travaillé ensemble. A l'image d'un enfant qui n'a jamais pratiqué le vélo, on va leur ajouter des petites roues : un ensemble de règles très précises à suivre et qui les empêcheront de tomber.
Ce cadre de travail permettra à l'équipe de se découvrir durant les premiers sprints. Ils apprendront à travailler ensemble et trouveront progressivement leur équilibre tout en produisant de la valeur. Puis viendra le moment le plus important : celui où l'équipe cherchera d'elle-même à retirer ces petites roues et donc à se libérer de ces règles trop strictes pour évoluer sur un fonctionnement qui leur correspond davantage.
Voici donc pour moi la véritable contribution de Scrum au monde de l'agilité : permettre à des équipes de débuter et produire rapidement un peu de valeur. Puis, une fois que cette équipe a suffisamment mûri, les règles de Scrum sont naturellement remises en question par l'équipe, qui pourra les modifier pour qu'elles lui correspondent parfaitement.
L'agilité dogmatique
Ce qui me dérange aujourd'hui, c'est que Scrum est utilisé par défaut. Parce qu'il faut être agile, que c'est la seule façon de faire réussir un projet et que Scrum est forcément la réponse. En tant que junior, je me suis déjà retrouvé dans des équipes à qui l'on impose le Scrum.
Quand les bonnes pratiques sont élevées au rang de dogme, on perd de vue les raisons et surtout le contexte qui nous ont poussé à adopter ces bonnes pratiques. On perd également la faculté de remettre en question ces pratiques quand le contexte vient à changer.
L'agilité nécessite quelques prérequis, le premier étant que l'équipe est engagée dans la réussite du projet et cherche à s'améliorer. Imposer des règles à une équipe ne lui permettra pas de s'améliorer, de la même façon qu'une équipe dont les membres ne sont pas engagés ne deviendra pas agile parce qu'on leur impose Scrum.
Le plus important est donc d'éduquer sur les valeurs de l'agilité, les problèmes que cela résout et les raisons qui peuvent justifier son adoption. Scrum est un framework pour démarrer l'agilité, mais l'essence même de cette philosophie, c'est d'être fortement adapté au contexte de l'équipe. Un ensemble de règles fixes ne peut donc convenir à toutes les équipes.
Scrum, c'est les petites roues de l'agilité.