De nombreuses entreprises se lancent dans une transformation agile à l’échelle à l’aide de méthodologies réputées sur le marché pour leur département informatique ou pour l’ensemble de leurs services. Malgré un suivi scrupuleux des recommandations de la méthodologie, le succès n’est pas toujours au rendez-vous. Dans cet article nous allons parler de l’une des premières raisons de ces échecs : la différence entre Être agile et Faire agile.
Quand une entreprise souhaite mettre en place de l’agilité, elle commence le plus souvent par déployer les outils préconisés dans les différentes approches (Scrum of Scrum, SAFe, Disciplined Agile Delivery, LeSS…). Dans le meilleur des cas, les rôles sont mis en place, les rituels sont suivis à la lettre, les artéfacts sont disponibles… C’est ce que l’on appelle le « Faire Agile ». En effet, les demandeurs veulent voir des résultats rapides et comme les recommandations paraissent simples et logiques et que ces éléments sont la partie la plus visible d’une approche agile, ils pensent que cela sera suffisant.
Pourtant, pour moi, cela équivaut à donner une paire de ciseaux à ses collaborateurs en croyant que cela va les transformer en coiffeur de star… Occasionnellement, vous pourriez tomber sur quelqu’un naturellement doué dans le domaine mais vous leur confieriez votre coupe de cheveux vous ? Si vous aimez prendre des risques, peut-être. Sinon vous remettrez en cause les compétences de la personne tenant les ciseaux : a-t-elle été formée ? Sait-elle de quoi elle parle ?
Et vous auriez raison, ce n’est pas parce que l’on nous fourni des outils que l’on sait forcément comment s’en servir. Essayer de déployer l’agilité en ne se basant que sur la mise à disposition de ces outils a de fortes chances d’échouer. En réalité, les outils de toute approche agile ne sont que là que pour supporter une manière de faire. Ils doivent rester un moyen plutôt que devenir un objectif. Car le vrai objectif dans une transformation agile est de changer un état d’esprit.
L’état d’esprit, la culture, la philosophie… On peut l’appeler comme on veut mais cela correspond aux principes de base de l’agilité. Si l’on en revient aux sources, on les retrouve dans le manifeste Agile :
Dans un projet on doit accorder plus d’importance :
Tous ces éléments peuvent paraître simples, et pourtant ils font très souvent défaut dans les projets traditionnels et dans les projets « faire agile ». Quels résultats espérer d’un projet « agile » qui a un backlog fermé au changement ? ou d’une équipe soumise à des processus de validation ?
C’est pourquoi il est nécessaire d’accompagner voire de démarrer toute transformation agile par de la sensibilisation à tous ces concepts à tous les niveaux de l’entreprise. Il faut notamment accompagner les équipes de direction qui, même si ce sont elles à l’origine de la demande, sous-estiment l’impact sur leur manière de travailler (par exemple diminuer leur demande de reporting ou de réunions de suivi). Au risque de choquer les agilistes les plus puristes, je pense qu’une fois l’état d’esprit agile bien en place, les outils des différentes approches deviennent secondaires et on peut alors faire quelques compromis.
L’agilité est plus qu’une simple boite à outils permettant de gagner en réactivité. Pour réussir une transformation agile, ça passe par le changement des modes de travail ET SURTOUT des modes de pensées internes, au niveau des équipes impactées mais également pour tout l’écosystème autour.
« Faire Agile » consiste à déployer surtout des outils sans travailler sur le changement de culture nécessaire, ce qui limitera l’impact de l’approche.
« Être Agile » consiste à un changement plus en profondeur des modes de pensées de l’entreprise et permettra une évolution non seulement dans les projets mais aussi dans le quotidien de tous les collaborateurs.
