Fin 2015, j’accompagne une entreprise leader du revêtement de sol dans son projet d’amélioration de l’expérience utilisateur. Une centaine de collaborateurs répartis sur 3 continents doivent œuvrer dans un même but défini par le DSI. Et tout ça en mode agile! Dans une organisation hiérarchique silotée! Rien de mieux que SAFe (d’après le client). Et pourtant. Un cadre agile de conduite de projet ne transforme pas à lui seul une organisation. Cette difficulté de mise à l’échelle de l’Agilité fissure aujourd’hui la communauté agile. Pourquoi le Manifeste Agile ne répond pas aux besoins de l’agilité organisationnelle?
Les individus et leurs interactions plus que les processus et les outils
La première valeur du Manifeste est efficace dans une équipe de 7 personnes. Qu’en est-il pour 700 ? 7000 ? Créer et synchroniser 1000 équipes agiles ? D’autant plus qu’aujourd’hui, les équipes distribuées sont monnaie courante.
Les différentes cultures, les différents fuseaux horaires, les différentes langues sont autant d’obstacles à la mise à l’échelle de l’Agile. Je travaille avec des équipes russes, serbes, irlandaises, brésiliennes, françaises et américaines. De légers compromis sont nécessaires lors des planifications de versions et des synchronisations:
- Nous nous exprimons tous en anglais. Cependant, de nombreuses incompréhensions sont relevées.
- L’agenda est personnalisé pour permettre à tout le monde de participer.
- Notre Team Agreement est partagé.
Travailler de façon collaborative demande de définir un certain nombre de règles, d’outils et de processus. Et SAFe répond en partie à ce besoin. Mais il existe une grande différence entre agilité d’équipe à grande échelle et agilité organisationnelle.
La systémique nous apprend que tout changement de l’état d’équilibre d’une organisation résulte d’une co-construction de l’ensemble de ses éléments. Il est donc préférable de co-construire les règles et les processus. Mais à 7000, pas évident !
Une solution : les Communautés. Au nombre de 3, elles développent la flexibilité de l’entreprise.
- Les Communautés de Pratiques (comparables aux « Chapters » de Spotify) regroupent des collaborateurs de même métier. Elles définissent les bonnes pratiques, les règles « Métier ».
- Les Communautés de Produit/Service définissent les règles et les processus relatifs à un produit ou à un service, à la production de valeur de l’organisation (« Tribes » ou « Feature Team »).
- Les Communautés de But se focalisent sur les process et outils davantage transverses (ex : Communauté de But : Apprenance). Chaque collaborateur fait partie d’une ou plusieurs communautés selon ses propres choix. Au final, une Communauté de But : Gouvernance discute des axes stratégiques de l’organisation.
Des logiciels opérationnels plus qu’une documentation exhaustive
Qu’en est-il quand l’organisation commercialise plusieurs produits ? Plusieurs services ? Avec potentiellement plusieurs modèles économiques par produit. Les équipes perdent de vue la « Big Picture » de l’organisation. Malgré le PI Planning (planification à grande échelle de la méthode SAFe), les Features Teams (équipes auto-organisées) mises en place chez mon client ne voient que les fonctionnalités dont elles ont la charge.
Le partage de la vue d’ensemble doit être porté par le partage de la documentation relative à chaque produit. Elle est partie intégrante du produit, élément essentiel du « Definition of Done ». Car l’Agilité à l’échelle prend en compte l’ensemble de la chaîne « Produit » en tant que “Proposition de valeur”, de la conception au service après-vente. Cette considération systémique réduit les incompréhensions des véritables besoins des utilisateurs. Ainsi la mise en place d’une Culture Produit, facilitée par l’existence des Communautés, redéfinit les rôles et responsabilités de chacun. Des profils différents communiquent enfin autour d’une vision et d’objectifs communs.
Être ou devenir une entreprise agile n’a de sens que si cet objectif est poursuivi.
La collaboration avec les clients plus que la négociation contractuelle
Cette valeur est basée sur l’idée que la confiance se développe davantage sur des interactions entre les personnes que sur des méthodes formalisées. Elle ne peut se développer qu’à condition que les personnes passent un temps significatif ensemble. Et si vous aviez 10000 clients, pourriez-vous faire confiance à autant de personnes ? Certes, non. C’est pourquoi les équipes agiles comportent moins de 10 collaborateurs. D’un côté, ce manque de confiance est un moyen de protection de votre organisation. De l’autre côté, il mène au « je m’en foutisme » et dégradent les relations entre l’organisation et ses clients. Et les mêmes schémas sont visibles dans l’organisation lorsque les collaborateurs de la maison mère considèrent leur travail comme plus valorisant que celui des collaborateurs des filiales.
Une communication claire et sincère (via les réseaux sociaux pour une plus large diffusion) augmente la relation de confiance entre chaque protagoniste. Davantage, qu’une relation One-on-One avec chacun. Dans un monde digital, l’entreprise qui ne gère pas cette communication se met en danger.
L’adaptation au changement plus que le suivi d’un plan
Il est sûr que dans un environnement volatil, incertain, complexe et ambigu, un plan sur 5 ans est utopiste. Le darwinisme démontre que plus un animal est gros, moins il s’adapte rapidement. Qu’en est-il pour les organisations ? Aujourd’hui, beaucoup de tentatives sont menées dans les entreprises : start-up internes, digital Lab, Design Sprint… Toutes ces approches sont communes : le mode “Commando”. Isoler l’agilité des équipes du système. Et toute l’erreur est là. Une organisation constituée uniquement d’équipes agiles n’est pas nécessairement agile. La communauté agile s’acharne à mettre à l’échelle en irradiant de bas vers le haut, alors que la solution est un changement par conduction transversale.
Aujourd’hui, la communauté agile s’interroge sur la mise à l’échelle de l’agilité. Autrement dit, comment rendre une organisation agile? Tout naturellement, les solutions proposées reposent sur le déploiement de l’agilité des projets.
Or, l’organisation est un système adaptatif complexe beaucoup plus important. Sans les apports de la systémique, l’agilité à grande échelle ne peut fonctionner.
“L’agilité n’est pas une destination mais un chemin, pas un objectif mais un moyen”.
Les 12 principes agiles on été créé pour une équipe Scrum, comme vous le précisez dans votre article ; c’est donc une aberration de vouloir les généraliser à l’échelle sans prendre en compte la dimension de l’Entreprise et ses spécificités. Certains agilistes entretiennent le doute en faisant croire que l’on fait fonctionner une entreprise sans documentation, sans processus , …ces personnes presentent un danger pour leur client.
Vous faites plusieurs fois reference à SAFe, qui a traité la dimension à l’échelle et l’entreprise : ce n’est pas parfait et surtout, pas à suivre à la lettre mais la guidance proposée sécurise les tentatives de passage à l’echelle ;
certaines pratiques, particulièrement le PI planning qui réunit tous les protagonistes, dont les acteurs métiers, ou encore, la gestion du portfolio de l’entreprise, ou encore et aussi , la prise en compte des enablers technologiques à ” tous les étages de la fusée” sont autant de bonnes pratiques qui peuvent aider les entreprises souhaitant se transformer…de trouver un chemin.
Le point de la transformation organisationnelle qui doit accompagner ce chemin vers l’entreprise agile n’est pas toujours pris en compte, ou au contraire, est trop violent : c’est probablement là que l’approche systémique peut aider…. et le support de vos prestations être ” accompagnant”.
[…] L’Agilité à l’échelle ne fonctionne pas… sans approche systémique par Loic Leofold […]
[…] L’Agilité à l’échelle ne fonctionne pas… sans approche systémique par Loic Leofold […]