La fin de Scrum ou le renouveau de l'agilité

Ou un survol élémentaire de l’histoire du mouvement Agile, depuis ses débuts jusqu’aux errements actuels. Le pire dans cette absurdité, c’est qu’il existait de vraies méthodes Agiles … Bien évidemment, elles nécessitaient un apprentissage raisonnablement sérieux. Comme pour tout vrai métier quoi…

Plongeon au cœur d’une méthode simplette

De par le simplisme de sa demi-douzaine de recommandations, Scrum est certainement la plus grande esbroufe de l’histoire des méthodes informatiques. Je n’ai pas dit de l’histoire du développement de systèmes d’information ou plus simplement d’applications, puisque ces sujets ne sont même pas abordés par ce gag méthodologique et son kanban « rapporté » à trois colonnes. D’ailleurs je vais vous donner un cours rapide sur ce sujet, des fois que vous ne soyez pas au courant du miracle. Commencez par tirer deux traits verticaux sur une grande feuille de papier et intitulez vos trois colonnes « À faire, En cours, Achevé ». Voilà, c’est tout, vous disposez maintenant de l’outil magique pour contrôler vos projets les plus complexes et vos développements les plus sophistiqués. Avouez qu’il fallait quand même y penser… Mais quoi que,… si on ne le savait pas avant… Certains argueront que ces trois colonnes (comme pas mal d'autres outils "empruntés" pour faire illusion de réponses utiles), ne sont pas officiellement du Scrum. Peut-être, mais toutes les personnes que je rencontre le pensent. Voilà ce qui arrive lorsque l’on s’approprie les techniques des autres, faute de ne pas en avoir de propres.

Encore plus fort : outre l’aspect commercial de sa large diffusion, il faut reconnaître à Scrum une efficacité psychologique indiscutable, puisque quiconque a suivi une ou deux journées de formation, en ressort avec cette certitude d’être devenu un expert à qui plus personne n’a à apprendre grand-chose. Même pas le fait avéré que Scrum n’est pas naturellement itératif et qu’il est vain de vouloir nommer « itération » ce qui n’est que Sprint (dans la durée) et livraison d’un incrément définitivement achevé (dans l’objectif).

Trêve de plaisanterie, derrière le simplisme se cachent des choses plus complexes et difficiles à gérer que Scrum vous sermonne de mettre en œuvre. Trois autres points, traités ensuite, méritent une réflexion approfondie, car ils impliquent des errements graves dans la mise en œuvre de l’Agilité réelle.

Un peu de réalité et d'histoire

Il suffit d’aller sur Vickoff.com ou sur Wikipédia pour comprendre que je suis depuis l’aube de l’informatique un acteur actif en matière de méthode. J’ai donc assisté à la naissance de Scrum sur la base du plagiat d’une demi-douzaine des concepts issus de la méthode RAD. Lesquels avaient d’ailleurs été officiellement repris dans les méthodes suivantes comme Adaptative Software Development, Feature Driven Development et quelques autres tout aussi inconnues de ce côté de l’Atlantique. Les principaux emprunts se situaient dans :

la présence d’un animateur facilitateur (renommé Scrum Master par Scrum) ;
la tentative de réduction de la dualité métier informatique par la « validation permanente » de l’utilisateur final ;
le rythme des lotissements (devenus des Sprints) et des « Show » de l’application ;
la cadence des rétrospectives quotidiennes (stand up meeting) et des autres.

Il y avait aussi quelques petits détails techniques comme la salle dédiée (War Room), les tentatives d’obtenir une équipe engagée en mode projet et en mode plateau, mais ayant à l’évidence perdu les compétences techniques du SWAT (Skill With Advanced Toools).

J’ai donc assisté à la montée de Scrum suite à l’Agile Manifesto et au livre de Schwaber et Beedle qui s’en est ensuivi. Je dois dire que me suis personnellement payé ma dose de problèmes en communiquant sur l’escroquerie intellectuelle en cours (cabales de tout type, suppression de pages dans Wikipédia, etc.). Mais que voulez-vous, un truc de simplet, pour des simplets, c’était tellement tentant. D’une certaine manière, je piétinais leurs rêves de certifications pyramidales.

Puis, est survenue la prise de conscience progressive de l’impuissance relative de cette méthode et son lynchage par ses premiers adorateurs confrontés à la réalité complexe des projets et aux divers types d’échecs qui en découlèrent.

Revenons maintenant à la technique. Il est amusant de constater qu’aux débuts de Scrum, de nombreux consultants souhaitaient remplacer le RAD (au nom si peu porteur en français et surtout que j’avais verrouillé en termes de possibilités de certifications). Ils menaient donc une guerre de principe à cette toute première des méthodes Agiles en prétendant qu’elle ne l’était pas. C’était étonnant, car entre autres techniques « Agiles » dont elle était l’initiatrice, la méthode RAD comme XP, acceptait le changement des besoins utilisateurs (même en cours de développement). Ce qui n’était pas, et n’est toujours pas le cas de Scrum. Scrum se révélait donc, dans la réalité de sa mise en œuvre, être une méthode éminemment prédictive. Citons, pour ceux qui ne comprendraient pas ce problème, des points précis comme : la nécessité du backlog produit en sprint 0 et surtout l’interdiction de modifier les fonctionnalités en cours de Sprint. Ce point fondamental peut désormais se corriger en appliquant une métrique permettant d’assurer en temps réel la comptabilité des demandes de modifications (base du développement "adaptatif") .

Quant aux métaphores organisationnelles sous-jacentes, le « team » du rugby pour Scrum ou la notion de SWAT (skill with advanced tools) dans une War Room pour RAD, de toute façon, elles n’avaient pas été poussées assez loin pour qu’une réelle philosophie d’action s’en dégage. Ce n’était qu’un effet de mode. D’ailleurs, je ne serais pas étonné si dans peu de temps, les aspects « commandos » du Swat ou opérationnels de la War Room, revenaient à la mode avec l’évolution actuelle de nos sociétés.

Un autre aspect malheureux concerne l’unicité indispensable de la spécification - conception – développement – validation. Beaucoup semblent avoir oublié que dans un projet de système d’information, au-delà du relationnel (qui néanmoins conserve toute son importance), au final c’est du code qui s’exécute dans un ordinateur. Cette réflexion du passage de l’idée à la solution implémentable amène à un constat encore plus grave, le même problème que je combattais dès le début de l’aventure Agile : la rupture entre la conception et le développement subsiste. Je pensais cet aspect compris et réglé depuis longtemps, mais dans la réalité des entreprises, il n’en est rien. Les penseurs de la fuite d’eau se refusent toujours d’en être les plombiers. Le résultat de cette dichotomie n’a pas évolué avec le temps : le passage du témoin (les spécifications en l’occurrence) est toujours aussi générateur de travail additionnel de rédaction, de réunionite, de manque d’exhaustivité et de compréhension des détails. Les résultats sont évidemment toujours les mêmes : déperdition d’énergie, flou de la communication, génération d’incompréhensions et au final d’erreurs coûteuses aussi bien en développement qu’ensuite en maintenance. Sans parler de la spécification-validation permanente rarement comprise et encore moins souvent mise en œuvre, bien qu’elle soit la clé du succès des projets.

L'analyse élémentaire du problème

Toute cette réflexion conduit à un constat trop long pour ce type d’article et donc je vais me limiter à trois points problématiques :

La raison d’être et l’usage mal compris des récits utilisateurs (surtout lorsque ce ne sont pas les utilisateurs qui les rédigent avec simplisme).
Le délire de l’estimation de charge exprimée en points de complexité (dans le but plus ou moins avoué de rendre incomparable et surtout incompréhensible le reporting mural)
La volonté d’éradiquer les chefs de projet sans éclaircissement préalable de la réalité de leur sort.

En prémices, une petite métaphore.

De la même façon qu’au pays des Schtroumfs se parle le schtroumf, au pays de Scrum se parle le Scrum. La grande question actuelle au pays de Scrum est « Comment écrire un récit utilisateur ». Celle du pays des Schtroumfs est « Comment composer du Mozart ».

1 – Les récits utilisateurs rédigés par les informaticiens

Au début étaient les besoins, paix à leurs exigences. Commençons donc par un peu de recueillement. En mode Agile, depuis la méthode RAD puis eXtrême Programming, il a toujours été recommandé de confier à l’utilisateur réel de l’application le soin d’exprimer ce qu’il souhaitait (de préférence sous le contrôle de la ressource d’encadrement la plus apte à disposer d’une vision prospective du métier). En mode Agile, la forme de cette expression est primaire : en tant que X, je souhaite disposer de la possibilité Y, (et éventuellement : pour la raison Z). C’est parfaitement simple et presque suffisant à un détail près : les systèmes d’informations sont généralement un peu plus complexes que ne l’imaginent les experts Agiles « qui ont appris leur métier en deux jours ». De ce fait, imaginant avec leurs clients se trouver devant une forme d’expression obligatoire, tout ce beau monde va abandonner la rigueur des contraintes de l’espace de la solution pour se précipiter dans la rédaction d’Users Story miraculeuses d’agilité alors même qu’ils ne sont pas des utilisateurs. De la suite découlera le constat que personne d’autre que Mozart ne peut composer du Mozart.

De plus, dans un projet de développement applicatif, qu’il soit classique ou Agile, une translation de forme permet, partant du besoin fonctionnel de modéliser les contraintes techniques de l’espace de la solution. Cela se formalise (au minimum textuellement) par une décomposition en « exigences » voire en tâches, qu’elles soient techniques, fonctionnelles, de granularité de réalisation, etc. Si l’on dispose déjà de la formalisation nécessaire à l’espace de la solution, ce qui est parfois le cas, il serait absolument paradoxal et non Agile de perdre à nouveau du temps pour reformuler ce qui aurait « à l’idéal » dû être précisé par l’utilisateur, et en plus le faire décrire par des « non-utilisateurs ». Pour conclure ce point, comme aurait dit monsieur de La Palisse : « Pourquoi lorsque l’on y est déjà chercher à y venir ? ».

2 – L’estimation de charges en points de complexité relative

Le second point est encore plus désopilant. Il concerne l’estimation de charges. Pour tenter d'obtenir une évaluation raisonnable, le choix habituel est d’utiliser le « planning poker game » et c'est évidemment une bonne chose. Cette technique aboutit à un affinement de la compréhension du sujet et surtout à une estimation par l’équipe de réalisation (qui du fait s’engage moralement). Au passage, on s’étonnera d’un détail : le mot « planning » n’a aucun sens à ce niveau et le terme exact aurait dû être « estimation poker game ». Mais ceci n’est pas vital. Le vrai problème se situe au niveau de l’unité d'œuvre employée. Personnellement, comme je sais que tout finit par se compter en jours, j’utilise comme unité d’œuvre la « journée idéale ». Bien évidemment, c’est trop simple, pratique, raisonnable sans embrouille et surtout insuffisamment en rupture avec ce que souhaitent les tenants de l’ésotérisme Agile. Ils ont donc trouvé leur unité d’œuvre soi-disant incomparable, dans le sens de « ne pouvant pas permettre de comparaison de productivité entre les équipes ». Cela a été baptisé « points de complexité » et mérite une petite explication. Le principe implique de prendre « 1 » comme référence de l’user story la plus petite (ce qui nécessite de les avoir étudié toutes), puis de noter les autres en rapport avec cette complexité (par exemple : 2,5 fois). Mais fois quoi en clair ? On le saura à la fin du projet je présume. En attendant, on va imaginer la tête du dirigeant venant observer l’affichage mural incompréhensible et qui demande lui aussi : « Mais fois quoi !!?? ». Après une petite estimation sérieuse du « 1 », on imagine que ce pourrait être une journée et demie. Cela devient de suite beaucoup plus clair, mais il faut faire la multiplication pour chaque post-it. C’est d’un drôle… Au fait, de tête, en trois ou quatre secondes à perdre, cela fait combien 2,5 fois 1,5 jour ?

Au final, même si l’on se limitait à ces deux points, ce serait déjà beaucoup pour une méthode si simplette. Mais le pire selon moi concerne le fait que sans une métrique permettant d’assurer la comptabilité des demandes de modifications en cours de développement (introduisant les concepts de "livré utile" et de "livré abandonné"), il serait inconséquent de passer outre l’interdiction de Scrum d’accepter la remise en cause du contenu du Sprint ou de ce qui est déjà livré. De là à penser que cette méthode ne respecte pas le deuxième plus important des principe Agiles « Les processus agiles exploitent le changement pour donner un avantage compétitif au client. » …

3 – La disparition des chefs de projets dans un contexte où ils prospéraient

La plus marrante des tentatives révolutionnaires, surtout pour les concernés, est sans nul doute celle de faire disparaître les chefs de projets. Certaines méthodes Agiles composent avec leur présence en leur préconisant le dialogue et le consensus lors de toute décision. Derrière l’apparente simplification des relations humaines liée à leur suppression, se cache un incroyable piège organisationnel. Réfléchissez à deux fois avant de vous lancer dans une vulgarisation de la méthode sans avoir communiqué préalablement aux intéressés à qui appartiendront leurs bureaux, ou même le simple fait qu’ils devront se remettre en question professionnellement. N’oubliez pas non plus de justifier l’aspect rémunération du ScrumMaster et ses tâches réelles en regards des exigences de l‘organisation et des phantasmes de la méthode. Ces derniers points amuseront beaucoup les responsables RH impliqués.

Merci pour tout

Pour finir par une sorte de remerciement hypocrite, car au final je veux bien reconnaître à Scrum et surtout au prosélytisme de son commercial Jeff Sutherland (l’auteur du sommaire d’origine en 1995 c’est Schwaber) une chose : avant de faire condamner le mouvement Agile, au moins il l’aura fait connaître. Comprenez moi bien, je n'ai jamais été aussi certain de la nécessité de maitriser une approche agile. Je n'ai jamais pensé, à quelques petites erreurs près, que Scrum n'était pas utile, je pense juste qu'il est à l'évidence insuffisant et tant mieux. Comme cela il reste une bonne marge de progression vers l'efficience. On ne va même pas l'assassiner, on va juste l'aider à devenir ce qu'il aurait pu être.