La méthodologie SCRUM

Février 2014, 9h02 le téléphone sonne. Un client me dit qu’il est très surpris, car le site que nous lui avons livré la veille ne correspond pas du tout à ce qu’il s’imaginait. Je regarde le cahier des charges avec lui, et me rend compte que ce qui nous paraissait évident il y a un mois est beaucoup plus ambigu aujourd’hui. Nous qui pensions avoir terminé un site, après une période éprouvante de développement sommes en train de repartir à 0...

Et après, nous avons rencontré SCRUM.

Reprenons depuis le début

Nous avons développé nos premières plateformes de crowdfunding avec la méthodologie Waterfall extrêmement classique dans la gestion de projet. Nous avions un cahier des charges prédéfini que l’on retravaillait pour satisfaire au mieux les attentes de nos clients et une date de livraison. Nous procédions alors au développement de la plateforme. Puis, après une phase de recette, nous la mettions en ligne.

Mais très rapidement, nous avons été confrontés aux problématiques suivantes :

• Des cahiers des charges incomplets, ce qui bloquait le développeur ou l’obligeait à faire des choix au sujet de la plateforme,
• Des effets tunnels importants durant la phase de développement avec une absence d’interactions entre l’équipe de développement et le client, ce qui était d’autant plus préjudiciable que nous étions chargés de développer des solutions innovantes réclamant une implication du client dans les choix stratégiques du développement,
• Des phases de recette qui prenaient énormément de temps pour récupérer tous les retours clients et des développements conséquents à replanifier. Nous nous rendions bien compte que de nombreuses modifications auraient été bien plus simples à implémenter avant,
• Un planning ingérable : il était impossible de concilier nos nouveaux développements avec des phases de recettes aux durées imprévisibles.

Nous nous sommes rendus compte que si la méthodologie Waterfall fonctionnait bien pour des produits standardisés, en revanche, elle n’était pas du tout adaptée pour les solutions innovantes que nous développions. Ces applications réclament une implication continue et soutenue du client pour qu’il soit décideur des grandes directions et des grands changements dans le développement de leur plateforme.

Pour éviter de reproduire ces erreurs, nous avons décidé :

• De standardiser le plus possible les fonctionnalités identiques sur nos plateformes,
• Et d’adopter la méthode SCRUM pour les développements sur mesure pour que chaque nouvelle plateforme puisse apporter son lot de fonctionnalités innovantes.

Pourquoi SCRUM ?

SCRUM est la meilleure des méthodes agiles existantes parce qu’elle est la seule à impliquer le client de manière intelligente en le sollicitant régulièrement en tant que décideur sur l’ensemble des fonctionnalités à déployer et sur les grands pivots qui peuvent être nécessaires lors de la réalisation du projet.

En plus de cela, c’est une méthode extrêmement productive puisqu’elle optimise le temps du client et des développeurs. Grâce aux revues quotidiennes du projet par le client, les développeurs savent exactement quelles tâches faire, comment les faire et en combien de temps les faire. Dès les premiers projets, nous avons senti que cette méthode avait donné un boost à notre productivité et à notre organisation.

Qu’est ce qui est important dans la méthodologie SCRUM ?

Adopter une méthodologie ne fait pas tout, encore faut-il la comprendre. Avant de la mettre en oeuvre, nous avons identifié les principaux risques de la méthodologie SCRUM.

Pour le Product Owner

Au cœur de cette méthodologie se trouve le Product Owner. Son rôle est critique car c’est lui qui va planifier le sprint en exprimant ses besoins et définissant ses priorités.

De plus, c’est lui qui va définir la notion de travail accompli en validant les taches de l’équipe de développement. Si nos clients sont exigeants avec nous, nous sommes également très exigeants vis à vis d’eux pour qu’ils soient les meilleurs Product Owner et s’impliquent à 200 % dans leur projet.

Pour l’équipe de développement

Lors des cérémonies, l’équipe de développement a pour principal fonction de traduire et de penser techniquement les attentes du client. Pendant la planification du sprint, elle participe activement à la construction de l’architecture de la plateforme tout en s’assurant que les tâches qui lui sont confiées sont bien définies, faisables et que leur durée de réalisation est juste.

Au moment de la revue du sprint, l’équipe de développement :

• Détaille au client ses dernières réalisations afin de faire converger les désirs du client avec le travail effectué,
• Et lui explique les difficultés techniques potentielles qu’elle a pu rencontrer tout en proposant une solution pour les dépasser.

L’équipe de développement doit savoir exprimer un besoin technique, et sa nécessité au product owner. Nous avons du mettre en place des outils collaboratifs (Slack et Trello) pour faciliter la communication entre le product owner et l’équipe de développement. « La pédagogie est l’art de la répétition » diront certains.

Pour le SCRUM Master

Le SCRUM Master, quant à lui, est le garant du bon déploiement de la méthodologie. Concrètement, il s’assure que toutes les parties prenantes du projet connaissent leur rôle et fait en sorte que les attentes du client soient en adéquation avec les capacités des développeurs. Il peut faire des concessions sur les principes de la méthodologie uniquement lorsque cela permet de mieux impliquer le client.

Par ailleurs, il anime la rétrospective du sprint, cérémonie durant laquelle l’équipe SCRUM procède à une introspection et cherche à s’améliorer pour le prochain sprint.

Les avantages de la méthodologie SCRUM

Rencontrer SCRUM nous a permis d’avoir :

• ‍Un confort de réalisation pour l’équipe de développement puisque l’équipe participe à la spécification des tâches et à l’estimation de leur temps de réalisation. Ceci permet d’être plus attractif en termes de recrutement.‍
• Un suivi des projets plus fréquent et rigoureux qui minimise le risque de gros retards,‍
• Une relation fructueuse entre le client et l’équipe de développement ce qui accroit la compréhension business de nos développeurs et la compréhension technique de nos clients,‍
• Des clients beaucoup plus satisfaits de leur produit car impliqués régulièrement dans les décisions. La phase de recette n’est plus longue et compliquée, mais rapide et faite au fil de l’eau, ce qui permet au client de rectifier le tir dès que la conception de ce dernier commence à s’éloigner de ses attentes.

Aujourd’hui, nous ne sommes plus un simple exécutant technique mais nous avons un rôle important dans la conception du projet ainsi que dans les pivots à effectuer. C’est nous qui optimisons avec le client tant son produit que l’expérience de ses futurs utilisateurs.

Respecter la méthodologie Scrum

Ce que nous avons retenu de la méthodologie SCRUM :

• ‍Il faut la respecter à la lettre pour bénéficier de ses nombreux avantages parce que ce sont ses contraintes qui font qu’elle est aussi efficace.
• Mais il existe un unique cas de figure où nous pensons que l’on peut faire une entorse à la méthodologie : lorsque le client n’est pas assez impliqué dans le processus de développement parce qu’il n’est pas réceptif à la méthodologie, il faut savoir la modeler à la marge pour que le product owner reste au centre du projet.