N’interprétez pas mal ce titre, je suis fan du framework Scrum et je n’ai absolument rien contre les autres méthodes Agile. En fait, j’utilise Scrum pour mes projets web et techniques depuis 2 ans maintenant. J’ai récemment effectué quelques recherches et j’ai remarqué qu’internet regorge déjà d’introductions à Scrum et de présentations pour les débutants mais il n’y a quasiment aucun retours d’expérience concrets.
J’ai pensé qu’il était grand temps pour moi de prendre du recul et, avec l’objectif d’être encore meilleur lors de mon prochain projet, j’ai eu envie de lister chaque problème que nous avons rencontré avec l’équipe durant le développement de notre produit.
Donc, intentionnellement, cet article sera un peu pessimiste au sujet de Scrum et présentera davantage ses imperfections et ses faiblesses plutôt que ses bénéfices et atouts.
Avec Scrum, il est presque impossible de respecter des échéances.
Eh bien, après 2 ans de Scrum, je considère ce framework parfait pour démarrer un produit complètement nouveau avec absolument aucune date butoire.
Quand nous démarrons un projet de zéro, nous avons le temps de pivoter, d’itérer, de refaire certaines choses éventuellement. Personne n’attend un résultat spécifique en ce qui concerne l’interface graphique ou les fonctionnalités du projet. Scrum est alors formidablement redoutable dans ce cas précis, la backlog produit peut changer et les itérations façonneront graduellement le produit.
Malheureusement, ça devient vraiment difficile et presque impossible de respecter des “deadlines”. Avoir une échéance à respecter nous force toujours à définir des spécifications fonctionnelles et techniques claires et définitives. Une fois que nous avons rédigé ces spécifications, nous sommes obligés d’estimer le temps nécessaire à leur développement et aux tests afin d’annoncer une date cible à nos clients et faire de notre mieux pour ne pas être en retard dans les délais annoncés. Nous sommes donc directement, sans le vouloir, en train de basculer vers une méthode en cycle en V plutôt qu’une méthode agile.
Dès que les spécifications et les chiffrages sont terminés, même si nous tentons d’intégrer les tâches et les stories dans la backlog produit, les itérations Scrum seront systématiquement influencées par les délais et les spécifications. Ainsi, le contenu des itératons finit par ne pas être guidé uniquement par les retours utilisateurs mais beaucoup trop par les retards et les fonctionnalités nécessaires pour respecter les spécifications.
Scrum n’est pas toujours compatible avec une approche Lean.
Pour ceux qui connaissent l’univers des startups, la philosophie Lean tourne autour du “release often, release early”. Cette méthode consiste à développer un MVP “Produit Minimaliste Viable” et de ne surtout pas en être fier lorsqu’on confronte le produit pour la première fois sur un marché. L’important étant d’obtenir des retours d’utilisateurs rapidement et de pivoter si nécessaire.
En pratique sur mes projets, les “product owners” avec qui j’ai travaillé ont tendance à corriger les bugs et anomalies à tout prix pour obtenir des fonctionnalités tournant à la perfection.
Après chaque itération, le produit livré n’était pas composé de beaucoup de fonctionnalités mais la plupart du temps, juste une fonction parfaitement opérationnelle. Cette tendance à parfaire tout au cours des itérations Agiles repousse petit à petit le lancement officiel d’un premier produit.
Scrum n’est pas compatible avec un mode support/TMA.
Plus nous avons de rapport bugs de la part de nos utilisateurs et clients, plus il devient difficile de maintenir une backlog produit. Le fait est que notre SLA “Software Level Agreement” mentionne que nous répondrons systématiquement à toutes les demandes maximum X heures après les avoir reçu et aussi que nous les corrigerons maximum après X heures ou jours.
Quand nous recevons un rapport d’anomalie au statut “MAJOR” ou “BLOCKING” (disons de la part d’un client), nous devons corriger l’anomalie le plus rapidement possible pour respecter notre engagement et nous ne pouvons attendre le prochain “Sprint” cycle itératif de Scrum (ayant lieu toutes les 2 ou 3 semaines) pour respecter notre SLA.
Conclusion, il est préférable d’avoir 2 équipes distinctes pour chaque produit. Une équipe pas toujours pressée avec aucune échéance qui sera compatible avec une méthode Agile telle que Scrum, et une autre équipe dédiée au support client avec quelques fois des correctifs rapides à appliquer.
Les cérémonies Scrum ne sont pas toujours faciles à respecter rigoureusement à la fin des projets.
Pour les raisons mentionnées ci-dessus, parfois les poker plannings et les sprint plannings ne sont pas exécutés de façon aussi neutre qu’ils devraient l’être et certaines priorités peuvent être arbitrées à cause de “mauvaises” raisons (clientes).
A la fin de chaque sprint, durant les démos de sprint, juste avant les rétrospectives, parfois, nous n’avons pas beaucoup d’éléments à mettre en avant.
Je sais que même les stories techniques et les corrections de bugs sont censés être mis en avant durant ces cérémonies. Mais en pratique, j’ai remarqué que les membres des équipes étaient beaucoup plus engagés et excités au démarrage de chaque projet. Au début, ils étaient ravis de montrer leurs travaux et de venir aux démos et aux rétrospectives. Mais à la fin de chaque projet, comme la backlog produit se remplit petit à petit de corrections d’anomalies et de petites améliorations: l’excitation et la motivation avaient naturellement diminué et les cérémonies étaient vécues davantage comme des contraintes par tout le monde. Scrum peut parfois paraître trop rigoureux à vouloir appliquer systématiquement toutes les cérémonies.
Conclusion
Le bien être et le bonheur des membres d’une équipe est vraiment le plus important. Dans ce but, si vous ne voulez pas que vos équipes finissent épuissés et souffrent durant les Sprints, gardez à l’esprit que les cérémonies Scrum ne doivent pas être obligatoires et applicables en toutes circonstances. J’ai appris par l’expérience que certains développements étaient compatibles avec Scrum et que d’autres ne l’étaient pas.
Pour finir sur une note positive cet article, laissez moi simplement mentionner les deux bénéfices principaux que j’apprécie le plus dans un projet Scrum :
- Que tous les membres de l’équipe aient une compréhension claire et soient au courant de l’avancement du projet constamment.
- Avoir la sensation d’avancer et que le produit approche à la fin de chaque Sprint(toutes les deux ou trois semaines).
To be continued…