Récemment sur Twitter, un petit débat a eu lieu autour de l'agilité, et de Scrum en particulier.

Je vous laisse en profiter ici :

https://twitter.com/maxime_bajeux/status/1581236820419186688

(et les commentaires sont intéressants)

C'est loin d'être la première fois que Scrum se prend des volées de bois vert. Je vous laisse vous amuser à effectuer la recherche Scrum is dead sur Google.
Moi-même encore récemment j'écrivais un billet dont le premier chapitre s'intitulait "l'Agile est mort"

Mais dans le même temps j'écrivais :

Mais, autant le discours de ces dernières années sur l'agilité m'a fatigué, autant ce serait dommage de jeter le bébé avec l'eau du bain.

Remarquez, c'est déjà mieux que celles qui font du SAFe...

Pourquoi la "Scrum fatigue" ?

Déjà on va différentier deux choses, l'agilité en théorie, l'agilité en pratique. Et comme bien souvent, le plus important ca va être la pratique.

Un jour j'irais vivre en théorie parce qu'en théorie, tout va bien.

Si on prend la base de la base, l'agilité, c'est le fait de développer par incréments utilisable. Je ne prends pas trop de risque à dire qu'aujourd'hui c'est le standard accepté par presque tout le monde.
Alors oui, le "utilisable" n'est pas toujours synonyme de mis en prod. On rencontre encore des équipes qui mettent en prod tout les trimestres ou semestre, mais globalement tout le monde s'accorde vers le fait de diminuer les temps de cycle. A l'opposé du spectre, on a de plus en plus d'équipes capables de mettre en prod dans la journée, voire plusieurs fois par jour.

Ensuite il y a d'autres fondamentaux dans les principes agiles qui sont plus ou moins bien respectés, ou compris (comme le rythme soutenable). Et c'est souvent là où l'agilité en pratique échoue dans de très nombreuses équipes. D'où le thread Twitter ci-dessus.

La réunionite, les sessions d'estimations toutes cassées, les product Owner, les story point, les daily meetings qui deviennent des moments désagréables et j'en passe, tout un tas de truc qui vous amène vite à la rupture.

Bref, l'implémentation de l'agilité, souvent bancale, est à différentier de son objectif de base. On est presque tous d'accord pour livrer par incréments et amener progressivement de la valeur aux utilisateurs, récolter du feedback, itérer. En pratique on ne sait pas toujours comment faire, on se fait bien souvent mener en bateau par les innombrables consultants/coachs en agilité, transfo digitale etc... qui n'ont pas eux même d'expérience de création de produit.

Mais surtout, surtout, vouloir implémenter une méthode dans une entreprise avec une culture logicielle défaillante, des pratiques de management toxiques, ça ne change ni l'un, ni l'autre. Vous pouvez mettre toutes les réus de Scrum possible, vous ne saurez pas mieux faire du logiciel ou créer une culture produit dans une entreprise. D'autant plus quand l'agilité est cantonnée à l'équipe de dev uniquement.
Et il est très facile d'utiliser une méthode agile, Scrum par exemple, avec des objectifs radicalement différents. Les daily pour faire du micro management, les estimations pour pressurer, les Scrum Masters pour reconvertir les anciens chefs de projet etc..

Premier contact

Mon premier contact avec l'agilité, c'était en 2006/2007, donc plutôt tôt pour la France, grâce à mon boss de l'époque qui avait compris son potentiel. En 2010, étant devenu freelance et bénéficiant de ces 3/4 ans de mise en pratique, j'ai fait une mission d'un an en tant que coach agile. Je participais à l'écosystème, j'ai plusieurs billets de blog ici-même qui parle de ca, de transfo agile etc...

Mais ce fut loin d'être un long fleuve tranquille et j'ai fini par m'en désintéresser car cela n'avait pas toujours l'impact espéré. Et plus le temps passait, plus j'étais irrité par certains gourous de l'agilité. D'ailleurs on parle souvent d'évangéliste, il y a un petit peu quelque chose de négatif là-dedans vous ne trouvez pas ?
(Marrant, j'écrivais ca en 2010 : L'agilité, c'est pas un peu une secte) J'en pouvais plus de certains discours creux sur les valeurs agiles, des serious games etc...

Et c'est pour ça que c'est un sujet que je n'aborde plus souvent sur mon blog. Ce billet fait exception, mais ce n'est plus un sujet qui me passionne. Avant tout, ce qui m'intéresse, c'est de construire un produit, qui soit utilisé et qui apporte quelque chose.

MAIS, cela fait partie des outils que j'ai à disposition et que j'ai suffisament pratiqué pour savoir les utiliser correctement.

Parce qu'en fait, bien utilisé, ça marche.

Pour toute cassé que soit de nombreuses implémentations de méthodes agiles, je ne souscris pas au fait de tout jeter. Quelle est l'alternative ?

La méthode à la rache ?
C'est assez facile en regardant de l'extérieur de penser que se passer de méthode est plus efficace. Mais construire du logiciel, c'est aussi le faire vivre, c'est la possibilité de le passer à l'échelle, c'est le travail en équipe et tout ça nécessite un cadre de travail et une mécanique de construction reproductible.

Construire un prototype tout seul ne nécessite pas autant de méthodes, mais ça en nécessite quand même. Par contre, construire un produit complexe avec plus d'une dizaine de personnes, qui devra encore fonctionner dans 2 ans et avec de nombreux utilisateurs, sans cadre de travail, c'est l'assurance du désastre.

Lorsque je vois des candidats pour Malt, je dis systématiquement la même chose. Oui, on connait Scrum (et Kanban etc...), mais sans l'appliquer de façon stricte. Chaque équipe est libre de son organisation. Ce qu'on regarde à la fin, c'est le produit final et ces externalités (taux de conversion, nps etc...), pas le nombre de story point dont tout le monde se fout. J'ai bien conscience que peut-être, pour certains, ça donne l'apparence d'une absence de méthode ou de mauvaise implémentation. Ce n'est pas assez proche du dogme.

Mais c'est loin d'être le cas. Je considère que nous avons une équipe expérimentée, qui a le recul et l'expérience nécessaire pour créer, appliquer et adapter un processus de création mature et sans forcément coller à la lettre d'une méthode en particulier.

Bref, en réalité Scrum est mort ainsi que l'agilité à partir du moment où le manifeste a été écrit, des livres sont sortis, des certifications ont été créées.

Pour autant, il faut le voir comme une boite à outils qui peut vous permettre de construire un cadre de travail, cadre de toute façon nécessaire au-delà d'une certaine taille. Et ce cadre, doit évoluer avec le temps et les équipes.