Dans un article récent intitulé Why Do Many Developers Consider Scrum to Be an Evil Scam, le consultant Scrum Willem-Jan Ageling a déploré la nette impression que les personnes extérieures à son cercle professionnel ne partageaient pas la même dévotion envers le framework, « Je suis un passionné de Scrum. Quand je suis dans ma bulle Agile, j’ai le plaisir d’avoir de belles conversations. Nous pouvons avoir des opinions différentes sur les approches, mais au final, nous sommes majoritairement d’accord sur les mérites d’Agile et de Scrum. Mais quand je sors de ma bulle, je reçois souvent des réactions négatives. La pire chose que l’on m’ait appelé est un vendeur d’huile de serpent, vendant une arnaque maléfique ».
Je ne détaillerai pas ses arguments. Je ne pense pas que Scrum soit une arnaque diabolique et je ne pense pas que M. Ageling soit un vendeur d’huile de serpent. Pourtant, j’ai vu Scrum être trop souvent mal appliqué pour redevenir un passionné. Voici mes raisons très personnelles, basées sur des preuves de première main. C’est biaisé, mais je ne prétends pas parler au nom de « beaucoup » de développeurs, encore moins de tous.
- Le monde de la technologie s’est entiché de Scrum au point de devenir aveugle aux alternatives. Elle est adoptée sans conteste et considérée comme appropriée, voire indispensable, pour tout projet logiciel.
- Pourtant, la plupart des outils et techniques ne conviennent pas à tous les processus créatifs. Chacun doit être évalué pour son utilité en fonction des circonstances.
- Scrum est généralement imposé par l’organisation à l’échelle de l’entreprise. Lorsqu’ils ne sont pas libres de l’ignorer, les gens suivent les mouvements. Les cérémonies donnent l’impression de s’habiller pour le dîner. Personne n’aime ça ou n’en voit l’intérêt, mais nous le faisons par étiquette.
Engouement pour le cadre
C’est bien d’être enthousiaste à propos d’une technique de cadre, mais quand vous faites référence à un cercle d’individus partageant les mêmes idées comme une bulle – deux fois dans le même paragraphe pas moins, cela parle de préférence professionnelle plus que rationnelle. Cela parle de fandom. Les risques en sont évidents. Cela vous empêche de jeter l’ancien quand quelque chose de mieux se présente. Nous ne faisons pas cela avec des gens que nous aimons, et nous répugnons à le faire avec des idées chères. Quand quelque chose vous tient à cœur, la foi l’emporte trop souvent sur la vérité. En matière rationnelle, cela pousse la science en territoire religieux.
Gardez votre amour pour les autres ou pour une cause plus digne. Vous êtes un être humain avant d’être un professionnel de Java. Il n’y a rien de mal à être pragmatique, voire mercuriel quant au choix d’outils et de techniques pour faire avancer votre carrière. Vous ne jurez pas un acte d’allégeance à Java ou à Microsoft. Si vous tombez amoureux de C#, cela ne dérangera pas James Gosling. J’ai beaucoup investi dans l’écosystème Java et JVM au cours des quinze dernières années, mais je suivrai le mouvement si le monde évolue dans une direction différente. Une fois, j’ai fait beaucoup de Google Web Toolkit. C’est une technologie obsolète maintenant, et à juste titre. Je me suis amusé, j’ai gagné beaucoup d’argent et je suis passé à autre chose. Pas de mal.
Outre une incapacité à reconnaître de meilleures alternatives, l’engouement pour les outils conduit à l’anti-modèle du marteau d’or. Vous pensez que c’est essentiel et indispensable parce que vous l’aimez trop et que vous ne vous souciez pas de savoir ce qu’il y a d’autre autour de vous.
Bien sûr, nous ne pouvons pas tout savoir. Nous devons séparer l’essentiel de l’optionnel, compte tenu de nos ressources cérébrales limitées. Nous devons cueillir nos fruits de l’arbre de la connaissance avec soin car ils prennent du temps à cueillir et se gâtent rapidement. Lors de la conférence Devoxx 2022, un tableau franchement intimidant a été distribué qui couvrait de nombreuses compétences techniques de l’écosystème Java, classées en essentielles, bonnes à savoir et bonnes à savoir. Un effort louable, qui n’a même pas abordé les compétences générales et n’a rien dit sur la profondeur requise de chaque domaine. De nombreuses branches de l’arbre avaient des étagères et des conférences qui leur étaient dédiées.
Élimination radicale des distractions
Heureusement, tout dans le domaine Java n’est pas indispensable pour chaque projet. Des normes de facto comme JUnit et SLF4J viennent à l’esprit (jeu de mots). Tout dépend. Parfois, vous devez approfondir une technique que vous n’avez jamais utilisée auparavant. Vous pouvez devenir le gourou numéro un de Quarkus dans votre district postal pendant un an, puis ne pas toucher au cadre pendant les cinq prochaines années.
Je crois que le développeur à succès du futur est un éliminateur radical de distraction et un optimiseur de productivité. Elle recherche l’avantage humain sur l’IA et sait qu’il ne s’agit plus de résoudre des énigmes mathématiques ou le fond des lignes de commande arcanes Unix. Le temps nous dira comment nous pouvons battre la machine et valoir notre salaire, mais le temps et les efforts consacrés à quelque chose qui ne fournit pas d’avantage commercial ou ne vous rendent pas plus intelligent sont toujours gaspillés.
Cela me ramène à Scrum. Les cadres de gestion ne doivent pas être traités différemment des compétences techniques et des bibliothèques de logiciels. S’ils n’aident pas l’équipe ici et maintenant, dans ce projet, ils gênent. Le kilométrage varie toujours, qu’il s’agisse d’un ensemble de meilleures pratiques génériques ou du «secret personnel de ma réussite» de quelqu’un. Je suis sûr que tout écrivain d’horreur en herbe aimerait connaître la routine qui a maintenu Stephen King si prolifique pendant cinquante ans, mais même s’il a une méthode, c’est son méthode. Scrum n’est pas le méthode.
Scrum n’est pas fait sur mesure. Il met en œuvre une fonction support générique mais néanmoins prescriptive, inflexible et le plus souvent imposée comme un mode de travail obligatoire en équipe.
Un cadre normatif concerne les règles et non les recommandations. Vous ne pouvez pas utiliser votre propre jugement pour contourner ou suspendre le livre de règles à volonté, comme dans le contrôle du trafic aérien. C’est bien quand des vies sont en jeu. Mais les règles impératives doivent avoir une base scientifique solide pour justifier leur utilité générique. Cette base manque à Scrum, et nous ne la trouvons pas non plus dans les déclarations très opiniâtres du Manifeste Agile sur l’autonomie de l’équipe et la supériorité de la communication orale.
Tout cela n’aurait pas d’importance si les équipes avaient la liberté d’ignorer Scrum et de choisir le mode qui leur convenait le mieux. Nous savons que ce n’est pas le cas, surtout pas dans le monde de l’entreprise. Scrum est généralement imposé d’en haut et facilité par des personnes dont les moyens de subsistance en dépendent. Les grands facilitateurs et coachs comprennent qu’Agile concerne des principes dépendant du contexte, et non des procédures rigides. Ces personnes possèdent un trésor d’expérience et une boîte à outils complète à partir de laquelle suggérer ce qui est nécessaire pour le moment, que ce soit à partir d’un cadre propriétaire ou non. Je n’en ai pas rencontré beaucoup.
S’habiller pour le dîner
Comme tous les autres membres de la classe supérieure britannique, la famille aristocratique Crawley de Downton Abbey s’habillait pour le dîner. Même un lundi terne, sans invités et rien à fêter. Cela prenait du temps et était inconfortable, mais personne ne remettait en question son utilité. Ils savaient qu’il n’y en avait pas. Leur étiquette culinaire élaborée est venue avec le travail. Ils sont passés par les motions. Les habitudes enracinées le feront.
Plus d’une fois, je me suis senti comme ça dans des stand-ups et des rétrospectives, même en tenue très décontractée.