Arrê­tons avec les frame­works agiles

Jetez moi SCRUM, Shape-up et les autres, et encore plus leurs versions dites « at-scale » type SAFe.

Je ne comprends même pas comment on en est arrivé là alors que le mani­feste agile met en avant «  Les indi­vi­dus et leurs inter­ac­tions, de préfé­rence aux proces­sus et aux outils ».

Prétendre cadrer les indi­vi­dus et les inter­ac­tions via des proces­sus et des outils métho­do­lo­giques est un contre-sens total de ce qu’on a appris depuis le mani­feste.

Quand on me demande ma méthode de prédi­lec­tion je parle de Kanban, parce que l’im­plé­men­ta­tion dans le logi­ciel revient juste à limi­ter le flux et donner une prio­rité à ce qui est déjà en cours, avec une grande liberté d’im­plé­men­ta­tion. S’il s’agis­sait de cher­cher une implé­men­ta­tion « comme dans la litté­ra­ture », je raye­rais d’un trait et range­rai Kanban avec les autres.

---

Appliquer des outils et des proces­sus tout faits ça rassure quand on n’a pas confiance dans les indi­vi­dus et leurs inter­ac­tions.

Le fond c’est la défiance, souvent du top mana­ge­ment, même si parfois elle se diffuse jusqu’aux équipes elles-mêmes à force de leur poser des exigences contra­dic­toires.

L’idée c’est souvent que si les résul­tats ne sont pas ceux espé­rés c’est que les équipes travaillent mal, alors on va leur expliquer comment il faut travailler en impo­sant une recette sans cher­cher à appro­fon­dir les problèmes eux-mêmes.

Rien que le présup­posé me semble toxique.

---

Ne vous mépre­nez pas. Je trouve formi­dable que Base­camp forma­lise la façon dont ils fonc­tionnent. Ce n’est pas une critique de leur fonc­tion­ne­ment. Il y a plein de choses à penser dans la lecture de Shape-up.

Le trans­po­ser tel quel avec des rituels, par contre, c’est proba­ble­ment une mauvaise idée. Trans­po­ser quoi que ce soit tel quel est proba­ble­ment une mauvaise idée d’ailleurs. Le cargo-cult est bien trop présent dans l’uni­vers logi­ciel, et encore plus dans l’uni­vers star­tup.

Chaque équipe a ses besoins, des aspi­ra­tions, ses contraintes, ses indi­vi­dus. Croire que ce qui fonc­tionne à côté fonc­tion­nera chez nous en le reco­piant c’est se trom­per de prio­rité entre les indi­vi­dus et les proces­sus. C’est d’au­tant plus vrai qu’en géné­ral on en applique les arte­facts visibles mais pas la philo­so­phie sous-jacente.

Je ne suis même pas convaincu que ce soit un bon point de départ pour ensuite itérer. Les rituels ont tendance à ne pas bouger, voire à s’ac­cu­mu­ler, surtout qu’ils appar­tiennent à « la méthode ». S’il faut commen­cer c’est proba­ble­ment par SLAP.

---

Tout n’est pas à jeter. Il y a plein d’idées inté­res­santes à reprendre à droite et à gauche. Mon problème c’est la reprise d’un cadre complet comme si ça allait résoudre les problèmes.

Dans mes boites à outils, en fonc­tion des besoins, j’au­rais tendance à conseiller les points suivants :

• Des rétros­pec­tives régu­lières, à date fixe
• Des itéra­tions de durée rela­ti­ve­ment fixe
• Des points de synchro internes fréquents voire quoti­diens
• Des démos aux utili­sa­teurs et parties prenantes
• Une notion d’ap­pé­tit pour les sujets qu’on veut livrer
• Une esti­ma­tion d’ordre de gran­deur de l’ef­fort pour la prio­ri­sa­tion

Bref, un kanban avec des cycles qui permettent de régu­liè­re­ment sortir la tête du guidon, prendre du recul, voir ce qu’on veut chan­ger dans notre fonc­tion­ne­ment, déci­der quelle direc­tion on veut prendre pour la suite, et de vrais échanges amonts pour expli­ci­ter la complexité et l’ap­pé­tit pour les diffé­rents items.

Le reste s’ajoute avec grande prudence. Sauf besoin spéci­fique j’au­rais tendance à décon­seiller les items suivant :

• Les enga­ge­ments de livrai­son, hors besoin absolu (on ne déca­lera pas Noël)
• Les esti­ma­tions autres que des ordres de gran­deur
• Les back­logs (oui oui, vous avez bien lu)
• Avoir plus d’un objec­tif par itéra­tion
• Avoir déjà étudié la solu­tion avant de commen­cer
• Tenter d’ap­pliquer ce que d’autres équipes font dans d’autres contextes au sein d’autres cultures