Arrêtez de critiquer l’Agilité ou Scrum

Trop souvent, j’ai entendu des développeurs dire du mal des méthodes Agile, et en particulier Scrum, alors qu’en fait ils n’en critiquaient que ce qu’ils avaient vécu — et ce qu’ils avaient vécu n’avait pour le coup rien à voir avec l’Agilité et Scrum.

Pour une société, dire qu’elle pratique Scrum, c’est donner une image rassurante auprès de ses clients et lors des entretiens de recrutement

Dans trop d’entreprises, l’Agilité et Scrum sont dévoyés et les développeurs embarqués dans ces contextes ne peuvent qu’en dire du mal. On parle là de sociétés qui n’ont aucunement fait le passage à l’Agilité, mais pour qui “faire du Scrum” est un macaron qui apporte de la valeur face aux clients, ainsi que pour trouver des salariés. Mais c’est justement bien ça : un macaron, rien d’autre qu’un insigne qu’on brandit.

Un exemple d’imposture de Scrum

La réalité de ces entreprises est très différente de Scrum.
Voici un exemple “d’implémentation” de cette imposture de Scrum :

Le stand-up : Une réunion de reporting au Scrum Master. L’heure de la réunion a été décidée par Le Grand Chef pour s’assurer que les salariés n’arrivent pas trop tard au bureau, vu que cette réunion est quotidienne et obligatoire.

Le Scrum Master : Il est là pour faire du flicage. Il rédige les mails qui résument sur quoi travaille chaque développeur. Il remplit par ailleurs la feuille de présence en fonction de qui est à l’heure ou en retard au stand-up. Il sert aussi de tampon aux Chefs, c’est à dire qu’ils peuvent l’accuser de tous les problèmes.

Le Product Owner : Il assigne les tâches aux développeurs. Il est également en contact permanent avec les clients, ou plutôt, il s’assure que les développeurs ne soient jamais en contact direct avec les clients. Toute communication doit passer par lui.

La Planification d’Itération : Tout le monde se retrouve en même temps dans la même salle pour s’engager individuellement sur ses propres tâches. On peut dire que les backlogs sont individuels.

La Revue d’Itération : Il y a bien un moment où chacun est convoqué pour s’assurer que les feuilles de temps sont bien remplies, que l’outil de gestion de “backlog” est à jour — à l’heure près, bien entendu. Une démo de ce qui a été construit ? Absolument pas. Pour quoi faire ?

Le processus de release : Très chaotique, c’est la punition obligatoire à tour de rôle. On a beau s’y prendre à chaque fois plus tôt, il y a toujours des problèmes qui empêchent de terminer à une heure normale. Bien entendu, c’est le vendredi soir. Et surtout, n’espérez pas trop avoir de soutien : quand vous cherchez votre N+1 pour un arbitrage de dernière minute, vous vous rendez alors compte qu’il n’est plus dans les locaux. Vous comprenez qu’il a bien fait attention à ne pas partir par le chemin qui passe devant votre bureau, on ne sait jamais, vous auriez pu lui demander d’assumer son rôle.

La Rétrospective :La réunion a été arrêtée il y a plus d’un an, ça ne servait à rien, tout le monde se plaignait mais rien ne s’améliorait. À noter, seul le Scrum Master a le droit d’organiser une Rétrospective. Il ne faudrait pas que les développeurs discutent entre eux, sans aucune oreille indiscrète dans la salle.

Hormis les termes utilisés, est-ce que cela vous fait penser à Scrum ? Honnêtement ? Si vous avez déjà réellement pratiqué Scrum, vous savez qu’il n’y a là rien en commun.

Ces organisations qui pourrissent l’image de Scrum en pratiquant un faux Scrum

Sans tomber dans un tel extrême, beaucoup d’équipes ont une pratique de Scrum que je qualifierais de très approximative. Ce qui n’est pas nécessairement un problème en soi : une équipe mature va adapter ses process et éventuellemnet s’écarter du Scrum pur. Non, ce qui me dérange, c’est que ces équipes n’ont jamais réellement appliqué Scrum. Dès le premier jour, elles ont immédiatement bricolé le framework. Il y a toujours une bonne raison pour dire :

 

Ça, ça ne marche pas chez nous. On est obligé d’adapter.

Sâchant qu’ils disent cela sans avoir réellement essayé au préalable.
Et d’ailleurs, leur excuse est souvent bidon : en cherchant un peu, on arrive toujours à trouver une autre société qui est dans la même situation et qui s’en est sortie.

Le tabou de l’Agilité qui en fait une excuse imparable

Cerise sur le gâteau, ils s’empressent d’ajouter ensuite, sourire au coin des lèvres :

Savoir s’adapter, c’est ça Agile, pas vrai ?.

Paf, ça y est, la bombe est lancée : le mot “Agile” a été utilisé. On ne peut donc plus rien répondre.
En effet dans ces environnements, parler de l’Agilité c’est tabou. Bien sûr qu’on travaille en Agile. Toute remarque ou critique qui suggèrerait autrement est simplement inenvisageable. On est tellement sûr qu’on est Agile qu’il ne faudrait pas prendre le risque de le mettre en question.

Savez-vous de quoi vous parlez ?

Alors soyons clair, quand un développeur me raconte que Scrum c’est du bullshit, que ça fonctionne pareil qu’en “mode traditionnel”, je m’insurge :

Mec, ce que tu as vécu, c’était PAS du Scrum !

Et je bouillonne intérieurement envers cette société qui, parmi tant d’autres, fait la pire mauvaise pub possible pour Scrum et l’Agilité justement en disant les pratiquer.
J’ai ensuite envie de surenchérir et d’ajouter dans ma réponse à ce développeur :

Dis, tu as fait tes recherches sur Scrum avant de dire que Scrum c’était de la daube ? Tu t’es demandé si ce que tes chefs appellent “Scrum” c’était un vrai truc ou juste un délire pour donner l’impression de faire comme tout le monde ?
Sérieux, ouvre le Scrum Guide quoi ! Tu es sensé être un ingénieur il me semble ?

Et c’est encore pire comme ça

Vous savez ce qui est le plus incroyable dans tout ça ?
C’est que, ces organisations qui disent faire du Scrum mais qui n’en font pas, elles se porteraient mieux si elles arrêtaient de se mentir à elles-même et qu’elles se remettaient à travailler comme elles le faisaient avant.
Si la hiérarchie est incapable d’éviter le micro-management et la culture du blâme, que c’est le seul mode de fonctionnement connu et pratiqué dans la boite, et qu’il n’y a pas de réelle volonté de changer cela… À quoi bon faire semblant de mettre en pratique l’Agilité ? Ils s’éviteraient des clash avec leurs équipes en mettant au clair leur fonctionnement !
Mais cela n’arrivera pas… Car comme expliqué plus haut, envisager d’arrêter l’Agilité est tabou !
Cela demanderait une telle force de caractère de la part du management pour accepter ces critiques et ouvrir les yeux sur leur propre comportement… !

À propos de Jean-Pierre Lambert

Avant, j’étais un ingénieur logiciel. Mais peut-être pas le genre que vous imaginez ; les outils et les belles architectures logicielles me laissaient de marbre. Non, mon truc, c’était plutôt la qualité, la valeur produit, les process et les relations humaines.
Du coup, maintenant, j’aide les équipes en tant que Facilitateur Test et en tant que Scrum Master. Ce n’est pas plus mal !
J’espère vous revoir très bientôt sur ce blog pour la suite de mes aventures…

 

 

Note de coach agile :

En complément et sur le sujet, n’hésitez pas à jeter un oeil à la conférence de Claude Aubry sur le même thème : “Scrum Mon Scrotum” :

Téléchargez les slide Scrum mon Scrotum

 

 

….et à télécharger le scrum guide biensur !

Téléchargez le Scrum Guide