Agile is dead, so what

Depuis quelques temps, je vois apparaitre des articles nous expliquant que les développeurs doivent abandonner l’Agile, qu’Agile est mort, que c’est une fin de cycle. Et ce ne sont pas des anciens chefs de projet nostalgique de leur Gantt chart. Je parle entre autres de Ron Jeffries signataire du manifeste ou Dave Snowden créateur du modèle de prise de décisions Cynefin. Le pire, c’est qu’en les lisant je suis d’accord avec eux et je vais vous expliquer pourquoi pour ensuite partir sur de la prospective.

Les mots ont un sens …. dans un contexte.

Il y a quelques années quand j’entendais parler d’Agile, je voyais assez vite arriver le manifeste Agile. C’était LA référence commune qui donnait la définition du mot que l’on pouvait décliner ensuite à l’envie. Je lisais par exemple la semaine dernière un article du Beyond Budgeting Round Table qui parlait d’un process de projection Agile. J’ai du mal à me dire que cela fasse référence à un “working software”. Je me souviens d’ailleurs avoir eu ce débat il y a deux ans lors d’un meetup UX avec Quentin Bouissou dont le titre était “Lien Lean, Agile & Ux, ils ont tué les mots”. Nous sommes en pleine séance de Domain Driven Design à savoir que les mots ont un sens dans un domaine donné, mais qu’il n’existe pas de sens global. Pour donner un exemple du temps où je travaillais en banque d’investissement, nous devions toujours préciser ce que nous entendions derrière le mot deal. A l’arrivée le mot Agile est mort dans le sens où on ne sait plus ce qu’il veut dire, ou plutôt qu’il faut préciser le sens que l’on y met. In fine, je trouve cela mieux car cela évite les séries de pipeau bingo.

Agile Scrum is dead

En prenant le temps de lire les messages annonçant la fin de l’Agile, je me suis quasi systématiquement rendu compte qu’ils parlaient en fait de Scrum et maintenant par ricochet de SAFe. Et si je continue à décortiquer, ils critiquent le fait que ces frameworks soient utilisés quelque soit le contexte avec une approche prescriptive du style “Il te faut un Scrum Master”,… A l’arrivée, les murs ont été repeints mais rien n’a changé. Ou plutôt les personnes qui travaillent dans ces environnements se prennent une double peine à savoir les anciens et les nouveaux process tout à la fois. Il s’agit d’implémentations agile avec un mindset de cycle en V. Si tu fais tout ça, c’est sûr que ça va marcher. Le grand intérêt des méthodes prescriptives comme Scrum et SAFe, c’est qu’elles sont faciles à vendre. Quand un client te demande ce que tu vas faire, tu déroules le framework.

Maintenant on fait quoi ? #1

Pourquoi en sommes nous là ? Et bien parce que les vendeurs de pelle ont vendu des pelles à tout le monde. J’aurais aussi pu dire que quand on a un marteau, tout ressemble à un clou. Néanmoins, je pense que les conditions d’application de l’agile sont toujours là à savoir un environnement incertain, des liens de cause à effet difficiles à comprendre,… et donc la nécessité d’expérimenter pour apprendre. Je vais reprendre une définition de mes amis PMP qui présente les méthodes agile comme des méthodes adaptives et le cycle en V comme faisant partie des méthodes prédictives. Dans le cas de l’agile, j’apprends en marchant car je ne peux prédire le futur par l’analyse (exemple : je lance un nouveau produit digital type spotify). Dans le cas du cycle en V, je peux par l’analyse prédire la suite (exemple : je construis un pont).

Maintenant on fait quoi ? #2

Et bien on met en place des méthodes adaptives avec une approche adaptive. Je pars donc du pourquoi du comment. Je ne dis pas aux personnes qu’elles doivent faire une rétrospective, qu’il doit y avoir un RTE dans leur train,… Je pars de principes comme “Je ne peux apprendre plus vite que ma boucle de feedback”. Je regarde les impacts et non les pratiques. J’attache plus d’importance à l’apprentissage qu’à la rétrospective, je cherche l’alignement sans imposer le Scrum de Scrum. Je vais en faire hurler certains, mais tous les frameworks agile ne sont que des boites à outils et il est normal de ne prendre que ce qui correspond à vos besoins. Si vous voulez faire de l’amélioration continue à base de “Stop the line” et bien c’est parfait.

Maintenant on fait quoi ? #3

Je deviens de plus en plus hostile aux frameworks qui donnent des pratiques comme Scrum et SAFe. Je constate que nous avons tendance à être feignants et comme quelqu’un nous a maché le travail, nous prenons l’idée comme telle. Si je fais un parallèle avec le développement, c’est comme quand je vois des requêtes SQL dans les spécifications fonctionnelles. A réfléchir à la place du développeur, il arrête de réfléchir. C’est pourquoi je conseille d’aller vers des méthodes adaptives avec une implémentation adaptive. Bienvenue en terre du flux, de Kanban, de Beyond budgeting,…. Vous ne pouvez appliquer des pratiques car ce sont plus des principes. Le limiter le travail en cours de Kanban ne dit pas qu’il faut mettre des limites sur chaque colonne. Dans la majorité des cas, nous n’avons d’ailleurs pas fait comme cela. Côté pile, celui veut l’utiliser va devoir suer un peu et c’est plus dur à vendre. Côté face, nous avons une implémentation qui correspond normalement à une solution en face d’un problème.