Scrum : un framework pour experts de l'agilité ?
Les voix sont nombreuses qui incriminent Scrum sans réel argument, parce qu'il est de bon ton de ringardiser le cadre agile le plus populaire. Certains opposent même Scrum au courant no-estimate, ce qui est absurde vu que le mot "estimation" ne figure pas dans le guide Scrum. Ainsi, Scrum est devenu le bouc-émissaire de l'agilité.
Pour ma part, un certain esprit de contradiction me conduirait presque à défendre l'enfant mal-aimé. Mais, le temps passant, je dois avouer que je trouve moi aussi toujours plus de raisons de m'en distancier.
En voici 3, au risque de crier avec les loups.
1. C'est un cadre excessivement scolaire
Il vous dit quoi faire, pourquoi le faire mais surtout le comment faire : rôles, cérémonies, artéfacts, tout est décrit, jusqu'à la durée des réunions. C'est important, la durée des réunions : jusqu'à 8 heures de sprint planning pour un sprint d'1 mois (bon courage).
Ainsi, Scrum vous prend par la main, par les deux mains, ce qui est peut-être rassurant pour un premier contact avec l'agilité mais qui ne vous apprend pas spécialement à réfléchir. Combien a-t-on vu de chefs de projets, sentant le vent tourner, bachoter 2 ou 3 jours et se recycler à la va-vite en Scrum Masters, sans rien comprendre aux fondamentaux de l'agilité ?
La critique est injuste, me direz-vous : Scrum n'est pas responsable de l'usage que l'on en fait. Oui, sauf que Scrum appelle ces dérives en prenant peut-être, un peu, les gens pour des idiots.
2. Scrum ne dit rien de la conception fonctionnelle
Le guide évoque succinctement le "refinement" sans vraiment lui donner de place. Tout au plus est-il suggéré d'y procéder lors du sprint planning. Sauf que si vous attendez le lundi matin du début de sprint pour travailler sur vos user stories, vous pouvez faire une croix sur votre soirée à l'opéra.
Ainsi, la conception fonctionnelle est le trou dans la raquette, le grand oublié, l'impensé de Scrum. Pourtant, elle représente une charge de travail significative et nécessite souvent des allers-retours avec les parties prenantes (utilisateurs, experts du domaine etc.). Si vous ne l'anticipez pas, vous êtes dans les choux au 1er jour du sprint.
En passant, l'example mapping vous sera certainement utile pour produire une conception de qualité et faire monter en compétence toute l'équipe sur le métier.
3. "Scrum, c'est l'Extreme Programming sans les pratiques techniques qui font que ça marche"
Un autre reproche possiblement injuste, car Scrum ne prétend pas être exhaustif. Le guide nous met d'ailleurs en garde sur le sujet : "[Scrum] functions well as a container for other techniques, methodologies, and practices".
Seulement, ce cadre agile ne dit pas explicitement quels aspects il entend prendre en charge et quels autres il assume laisser de côté. C'est vrai de la conception fonctionnelle comme de tout ce qui permet de livrer fréquemment (DevOps) en minimisant la dette technique (Craftsmanship). Des aspects quand-même un peu essentiels, qui ne sont même pas mentionnés, même pas pour dire qu'ils sont hors périmètre.
Ainsi, pour le novice, tout porte à croire que Scrum est autosuffisant. Ce qui donnerait à penser que Scrum est en fait un outil d'experts : un cadre porteur de nombreuses idées parfaitement fondées, mais qui ne s'adresse pas aux bonnes personnes.