L’Agilité est souvent fantasmée, parfois usurpée et trop fréquemment mal comprise.

Voici 12 mythes à garder à l’esprit pour éviter de se tromper quand on envisage d’adopter une approche Agile.

1.   L’agilité est une mode

Faux car Scrum a été conçu en 1995, le manifeste agile a été écrit en 2001… Donc on ne peut pas dire que « c’est une mode ».

L’agilité est ancrée, durablement. Le 15^ème état de l’Art sur l’agilité rappelle que 94% des entreprises ayant une composante de développement logiciel pratiquent l’agilité, et 65% de ces entreprises ont plus de 3 ans de pratique (source 15th State of Agile Report, Digital.ai)

2.   L’Agilité, ce n’est que pour l’IT.

Faux : Même si les outils et méthodes utilisent souvent le vocabulaire de l’IT, j’ai personnellement eu l’occasion de voir que c’était aussi parfaitement adapté à d’autres projets de l’entreprise (Marketing, R&D, Juridique, Sécurité, Mécanique, Électronique…).

3.   L’Agilité, c’est la meilleure façon de faire pour tout le monde, tout le temps.

Faux : L’agilité n’est pas la réponse à tout. Si vous êtes certain de votre périmètre, de votre techno, que les attentes des parties prenantes ne changeront jamais… alors ne le faites pas en agile.

Par contre, si l’un de ces domaines pourrait être amené à évoluer (combien de fois vos parties prenantes ont-elles changé d’avis sur les 2 dernières années ?), alors faites-le en Agile.

4.   L’Agilité, c’est moins cher.

Faux : L’agilité, entrainant un certain nombre de réunions supplémentaires, décomptées du temps de réalisation, va coûter plus cher que le même projet en cycle en V.

Cependant, un projet en cycle en V a beaucoup plus de chance de se « planter ». 29% des projets utilisant le cycle en V se sont plantés, contre 9% des projets agiles. (Source le Chaos report de 2015).

Si on prend en compte les rallonges, avenants… qui sont traditionnellement le lot des projets en cycle en V, il devient évident qu’un portefeuille de projets, menés en Agile coûtera moins cher que ce même portefeuille de projet menés en cycle en V.

Pour creuser le sujet, regardez les Options Réelles de Claus Hirzmann.

C’est comme les trous dans le fromage : Plus il y a de trous, moins il y a de fromage et plus il y a de fromage, plus il y a de trous…

5.   L’agilité peut être appliquée de la même façon dans toute l’entreprise

« One size fits all » est un gros mensonge. Portons-nous tous la même paire de chaussures ?

Les pratiques agiles doivent s’adapter aux équipes, aux métiers, aux projets…

Si vous changez l’un de ces composants, il vous faudra revoir le dispositif.

Une partie de Disciplined Agile a été construit dans ce but : Vous fournir le meilleur outil en fonction de votre problématique, de la complexité de votre domaine, de la complexité de votre solution, de la taille de vos équipes, de leur maturité… (cf. Disciplined Agile Browser).

6.   L’Agilité, c’est facile

L’Agilité, c’est simple à comprendre… ça ressemble tellement à du « bon sens ».

Mais il faut comprendre ce qui est écrit en creux

• Si on demande aux équipes d’être autonomes, auto organisées, cela implique que l’on supprime les « petits chefs » qui regardent leur montre quand quelqu’un part avant 18h…
• Si on demande aux équipes de construire de la valeur, cela implique qu’elles aient accès aux utilisateurs (et non plus l’homme qui a vu l’homme qui a vu l’homme… qui a vu l’ours), qu’elles puissent re-prioriser le Backlog sans redemander la validation d’un comité de pilotage « Copil N+x »…
• Si on demande aux équipes d’être efficaces, cela implique que ce qui a été produit va être mis dans les mains des utilisateurs pour recueillir leur feedback, à chaque itération (et non pas tous les 3 mois…)
• Si on se permet des changements dans la méthodologie (« On fait du Scrum, mais… » ), on se retrouve trop souvent à avoir supprimé tout ce qui était compliqué, mais essentiel.

Cette liste n’est pas exhaustive. J’ai repris le schéma du ministère de la défense américain à propos de « Agile bullshit« .

L’Agilité demande de vrais changements « autour » de l’équipe. S’ils n’ont pas été entrepris, les équipes vont se décourager. Je suis convaincu que l’Agilité doit être conduite de façon sérieuse, voire disciplinée (cf. Disciplined Agile).

7.   L’agilité, c’est mettre Scrum partout

Scrum est l’un des Framework les plus utilisés (66% des cas d’après 15th State of Agile Report).

Mais Scrum n’est pas la seule réponse, beaucoup d’autres outils et méthodes sont aussi là pour répondre et aider l’organisation (cf. Disciplined Agile Browser, et The Agile Landscape, Christophe Webb).

8.   Passer à l’échelle, c’est rajouter des équipes agiles partout

Passer à l’échelle requiert une analyse de l’organisation actuelle et de comprendre ses faiblesses.

L’organisation à l’échelle devra avoir mis en place des solutions pour éviter de reproduire les problèmes de l’ancienne organisation.

Il est important de garder le lien avec les parties prenantes, ainsi qu’avec la vision du produit (et pour qui on travaille).

9.   Passer à l’échelle, c’est mettre en place SAFe.

Seulement 37% des entreprises ayant mis en place une organisation agile à l’échelle utilisent SAFe (cf. 15th State of Agile Report).

10.  L’Agilité, c’est le Chaos. On a sacrifié la prédictibilité pour la réactivité.

Trop souvent, en acceptant un changement demandé par le client, on oublie de lui rappeler les conséquences. On lui fait plaisir sur le moment, mais quand il faudra faire le bilan de 15 changements d’avis sur les 3 derniers mois, celui qui va payer la note ne sera pas content…

L’Agilité requiert une plus grande rigueur et discipline que sur un cycle en V car les conséquences sont visibles immédiatement (cf. PM2 de la commission européenne) d’où le nom de « Disciplined Agile ».

11. L’Agilité, c’est faire 2 fois plus vite pour 2 fois moins de temps

Même si Jeff Sutherland le promet dans son livre (“Scrum, The art of doing twice the work in half the time”), il est important de se rappeler que le père Noël ne vient qu’une fois par an…(et vous pouvez lui demander ce livre).

« 95% des performances d’un système viennent de la conception du système, et non des capacités des personnes qui travaillent dans le système » W.E. Deming.

J’ai un petit Serious Game pour le mettre en pratique, créé par Henrik Kniberg et mis à jour par Alfred Almendra.

Donc oui, on peut toujours améliorer les choses, tout en étant réaliste.

12. On peut faire une transformation Agile en 6 mois

Non. Celles auxquelles j’ai participé ont toutes demandé bien plus de 6 mois. Tout le monde ne travaille pas dans la Silicon Valley… Même Mc Kinsey le dit et parle de 1 à 3 ans.

---

Jean-Yves KLEIN, Certifié PMP, DASSM, PMS1, SAFe

Ancien développeur, passé directeur de projet puis responsable d’agence, Jean Yves a basculé en 2008 sur la mise en place d’équipes agiles.
Coach Agile, il a accompagné plusieurs entreprises dans la mise en place d’organisations guidées par l’efficacité.
Il est intervenu en électronique, mécanique, marketing, et bien sûr en IT.
Il est membre du PMI Rhône Alpes, et formateur Disciplined Agile.
Il est aussi président d’OpenSeriousGame car c’est l’une des meilleures méthodes pour faire passer un message, que de le faire vivre. Il a créé Lego4DevOps, Lego4SAFe, DevSecOps.