Scrum, je t’ai aimé, mais je te quitte

Il y a peu de temps je mettais en doute l’efficacité de scrum, sur linkedIn, ici.

Crime de lèse majesté pour beaucoup !

J’ai donc repensé a tout ça, et j’ai essayé de rassembler les dérives souvent constatées dans les équipes scrum.

Ca fait très longtemps que je participe à des équipes scrum, en tant que lead dev, équipier, scrum master, ou PO selon les besoins des clients.

Et les constats de dysfonctionnement que j’ai pu faire sont souvent les mêmes:

1. Les estimations.
   Scrum utilise largement les estimations.
   Or celle ci ne servent strictement à rien. Quelle que soit la méthode, tailles de tee-shirt, story point et consort, au bout d’un moment les Tickets ( car souvent ce sont des ticket et non des User Story ) finissent par avoir tous peu ou prou la même granularité, à une vache près. Dès lors passer du temps à savoir si une story vaut 3 ou 5 points est une pure perte de temps. Ah et souvent par magie, les estimations sont transformées en deadline par simple application d’une règle de trois, très sympa quand il faut expliquer en permanence pourquoi tout ne s’est pas déroulé comme dans le plan.
2. Les sprints sont trop chargés.
   Même si on estime avec application. Même si on fait en sorte de moins charger le sprint ( coucou la loi de Hofstadter ). En conséquence les fonctions livrées sont très souvent incomplètes. Normal, on commence tout pour faire plaisir aux parties prenantes, car on est humain, on veut bien faire, mais on finit jamais rien.
   
3. Les objectifs sont absents.
   Les objectifs métier du sprint sont au mieux flous, ou définis a rebours mais souvent inexistants.
   Normal, sauf coup de bol, le timing du sprint est la plupart du temps incompatible avec la réalisation d’une fonction de bout en bout. C’est soit trop court soit trop long, car fixe.
   
4. Le cadre est trop fixe.
   On fixe à l’avance et à intervalle régulier les réunions de refinement / grooming / chiffrage de user story.
   Et comme les PO vont plus vite à comprendre, que les devs à coder, on fait du stock de User story.  Quoi de plus normal. Les backlogs deviennent ainsi un gros bordel. Il est souvent impossible de s’y retrouver et le taux de story non réalisées ne fait qu’augmenter. Saviez-vous que dans le lean « toyotesque » original, un stock était valorisé au passif d’une entreprise et non à l’actif ? Dit autrement un stock coûte du pognon, et ne rapporte rien. Et votre stock de User Story va vous coûter cher, même si on ne s’en rend pas bien compte.
   
5. La pression monte.
   Comme le pain s’accumule sur la planche, Les devs sont de plus en plus sous pressions « viiiiite il faut avancer, les story s’accumulent !! » et le sprint a tendance à porter de mieux en mieux son nom, car il faut écouler le stock d’US. Bye bye les tâches d’amélioration de fond. Ah et n’essayez pas de « réserver de la bande passante » car, les sprints sont trop chargés, on vous le répète, et une urgence quelconque aura tôt fait de préempter la précieuse bande passante, fût-elle imaginaire.
   
6. Le stock de User Story.
   Les story sont écrites et parfois chiffrées parfois longtemps avant d’être réalisées. Ainsi, au moment de s’y mettre le dev a perdu la moitié du schéma mental du besoin. Si tant est qu’il ai réussi à s’en faire un au moment du grooming. Cette compréhension métier, est pourtant essentielle à la réalisation de sa tâche, afin de prendre les décisions pertinentes, quand lors de la réalisation, il découvrira les cas non-spécifiés. Il y en a toujours. Le stock d’US a un peu moisi, tout le monde a un peu perdu son temps.
   
7. Les devs deviennent des machines.
   Conséquence plus ou moins directe des points 4 et 5, les devs manquent cruellement d’ownership. Transformés en robot stakhanovistes par une méthode qu’on leur ressasse comme miraculeuse mais qui ne peut que les mettre sous pression. J’en ai même vu refuser des tickets si TOUT n’était pas écris, jusqu’aux structures de données à tester. Après quand vous êtes infantilisés au point de devoir demander l’autorisation d’améliorer la qualité logicielle, et que le PO refuse, car il y a plus urgent, ben vous pouvez commencer à vous demander quelle est votre plus value.
   
8. "C'est pas toi le PO ?"
   Le rôle de PO, parlons en tiens. Je n’ai JAMAIS vu de PO. Je dis bien jamais. C’est à dire quelqu’un qui collecte du feedback utilisateur, et qui oriente le produit en fonction. Je n’ai certainement pas eu de chance. J’ai en revanche souvent vu des gens décliner les roadmap managériales, dont moi hein, en rajoutant des petit plus « ce qu’il serait bien de faire ». On fait donc au mieux, avec plus ou moins de réussite. Bah, c’est notre job à plein temps, alors on occupe l’espace, en empilant de la feature, dont l’impact est variable. Mais bon on est payé pour ça 40h semaine, alors on fait et… zou Go To point 3.
   
9. Les epics n'en sont pas vraiment, et rien n'avance.
   Conséquence de tout ça les epics ne sont plus des epics, mais un genre de thème qui sert plus ou moins à essayer de classer les story, pour voir si avec une bonne requête multi critère, on pourrait avoir une idée de quand est-ce que le produit sera fini. Aucune epic ne sera jamais terminée, on ne se choquera plus vraiment 200 epics en cours dans le backlog. Et le produit sera terminé, bah, un jour.
   
10. On perd notre temps au final.
    Et enfin, la méthode est assez lourde et consommatrice de temps. Ce qui fait d’ailleurs souvent lever un sourcil désapprobateur au management. Pour des refinement qui servent à faire du stock, des démos de fonction à moitié faites où tout le monde dort, des rétro qui servent à remonter qu’il n’y a plus de papier toilettes, parce que les 14 rétro précédentes n’ont pas été suivies d’actions concrètes. Et puis on a pas que ça a faire, on 43 tickets à livrer pour après demain.

C’est un peu tout ça que je reproche à scrum, car tout ça arrive même en étant complètement conforme à la méthode.

Alors on pourra me répondre «  non mais tu appliques pas bien la méthode »
Et c’est très possible, j’assume tout à fait ne pas être scrum-certified. Mais encore une fois, dans ces 10 points, j’en ai vu la plupart revenir très souvent. Le hasard à bon dos, mais quand même.

Je commence sérieusement à penser que ces défauts sont inhérents, sinon à la méthode, au moins a la possibilité de l’appliquer au sein d’une organisation plus vaste.

Quand la méthode ne fonctionne pas bien, premier réflexe: plus de méthode !
Plus de réunions, plus de rigueur, contraindre les chiffrages, refuser ci ou ça…. bref, s’arc-bouter en défense. Ça ne marche pas et isole encore plus les devs du reste du monde, pour booster la scro-sainte productivité. Isoler les devs est à mon sens ce qui peut arriver de pire à votre produit.

Bref, Scrum, je t’ai aimé, mais je te quitte.
J’ai trouvé mon nouvel amour.

Kanban.

Mais ceci est une autre histoire.