Agilité à l’échelle : quels pièges à éviter ? [partie 1]
L’utilisation de méthodologies Agile, et notamment d’Agile à l’échelle comme le framework SAFe – qui est le modèle organisationnel le plus utilisé – est de plus en plus commune au sein des départements d’ingénierie des grands industriels, et non plus uniquement dans le cadre de développements logiciels. De nombreuses industries manufacturières ont fait le choix d’implémenter ces méthodes de travail afin entre autres de lutter contre le manque de communication et de synchronisation entre leurs équipes, et d’arriver plus rapidement à des concepts, prototypes ou résultats mâtures et exploitables.
Pourquoi mettre en place un modèle SAFe ? Simple effet de mode ou réelle valeur ajoutée ?
Au-delà des questions probablement clivantes, nous souhaitons ici plutôt nous attarder sur une problématique opérationnelle liée à sa mise en application dans un contexte industriel. En effet, le framework SAFe est constitué d’un ensemble cohérent de briques élémentaires permettant de décrire les attendus à chaque étape et répondant aux questions suivantes :
- Comment constituer les équipes, les trains, les solution trains ?
- Quelles routines sont nécessaires ?
- Quels sont les rôles et responsabilités associées ?
- Comment gérer les interactions entre les différentes parties prenantes ?
- Comment accompagner et faire monter en compétences ?
Autant de questions auxquelles il est primordial de répondre, en adaptant à notre contexte afin de pouvoir déployer dans de bonnes conditions, au risque de négliger une des briques ou des prérequis et d’entrainer un modèle d’organisation non pertinent et fonctionnel.
Basé sur nos différentes expériences du terrain, nous tenterons de mettre en lumière les types de pièges fréquents à éviter afin de garantir une implémentation exploitant tout le potentiel du modèle SAFe. Les pièges présentés porteront sur différents axes :
- Le déploiement imposé ou subit du framework d’agilité à l’échelle
- L’implémentation plus complexe dans un développement de produit physique (en opposition à l’implémentation logicielle / software)
- L’impact sur l’innovation, à laquelle on ne laisse pas suffisamment de place, voire qui peut être totalement délaissée
- Les liens avec les différents métiers et les business owners pour bien porter la voix du client
- La mise en place d’une méthodologie Agile dans un environnement et un mode de pensée non Agile
Écueil #1 : imposer (ou subir) le déploiement d’un framework SAFe
Rappelons que le modèle SAFe suggère de réaliser un déploiement progressif train par train.
Une attention particulière est à porter sur les aspects de conduite de changement permettant d’accompagner ce changement culturel profond. Ce qui est vrai de manière générale dans tout projet et déploiement progressif le devient d’autant plus dans un contexte où l’on déploie un framework SAFe de manière massive : une préparation très en amont est primordiale pour voir les chances de succès s’agrandir. Ainsi, l’analyse d’impact, l’identification des sponsors et des bons profils pour chaque rôle, la prise en compte des spécificités de l’entreprise, la préparation d’un plan de communication et d’un plan de formation et de montée en compétence sont autant d’éléments qu’il est nécessaire d’avoir figés avant le début du déploiement.
Bien entendu un déploiement massif implique un risque majeur : si le modèle doit être adapté, quelles qu’en soient les raisons, le travail d’ajustement est d’autant plus conséquent et douloureux.
Par ailleurs, le manque d’implication des sponsors et du management dans le cadre de projets de transformation se révèle souvent catastrophique pour leur réussite. Ce manque d’implication peut se traduire de deux manières :
- Ne pas avoir l’engagement du management avec un véritable sponsorship enlève toute la force de la démarche dans l’état d’esprit Agile (leaders inspirés et inspirants). Le message perçu est que ce déploiement n’est pas une priorité pour le management, préférant s’atteler à des tâches leur semblant plus valorisantes. De ce fait, il est important d’avoir un middle management extrêmement engagé fonctionnant en tant que courroie de distribution entre le top management et les équipes opérationnelles
- Inversement, ne pas impliquer le management, par exemple en ne les conviant pas aux rituels mis en place pour garantir le partage d’informations sur l’avancement des travaux et collecter leurs retours (ex : démo, Inspect & Adapt), peut entrainer d’une part pour les équipes un sentiment de désintérêt sur leur travail, et d’autre part une opacité et un risque d’organisation à deux vitesses
Un déploiement Agile, d’autant plus s’il est à l’échelle, se doit d’être soutenu par le bon niveau de management pour avoir une bonne chance de réussite !
Écueil #2 : ne pas prendre la mesure d’un déploiement / d’une implémentation sur un produit physique complexe (vs. logiciel)
L’agilité ayant émergée initialement dans le monde du logiciel, son implémentation dans le cadre de projet de développement software prend tout son sens avec une facilité accrue pour livrer de manière incrémentale de la valeur aux clients, au travers de MVPs (Minimum Viable Products) puis des Products Increments.
Dans un contexte de développement de produits physiques de plus en plus complexes (ex : défense, aéronautique, spatial, nucléaire, automobile…), les cycles de développement et d’intégration sont bien plus longs. Plusieurs paramètres peuvent simplement expliquer cela :
- L’intervention de différents métiers interdépendants qui ne peuvent pas toujours paralléliser les tâches : modélisation, réalisation de plans, création et revue de maquettes numériques, phases de simulation chronophages, etc.
- Les processus industriels longs et incompressibles, que ce soit dans des phases de prototypage, de fabrication, d’acheminement de pièces élémentaires / d’équipements ou de temps d’assemblage.
- La disponibilité des technologies employées chez une poignée de fournisseurs spécialisés qu’ils sont les seuls à maitriser, créant une latence afin d’approvisionner leurs différents clients.
- La complexité de l’organisation industrielle : l’impact est d’autant plus important lorsque l’organisation d’une société est éclatée entre différents centres et/ou pays, comme cela peut être le cas pour des industriels européens tels qu’Airbus, dont les sites sont répartis en Europe et rendent la colocalisation des équipes quasiment impossible (contrairement à Boeing, dont les centres d’ingénierie et de production sont centralisés à Seattle). Il faut ajouter à cette complexité géographique des problématiques d’entreprise étendue avec ses fournisseurs, et tout ce que cela implique en termes de confidentialité, d’échanges de données et de collaboration au sens large.
- Les contraintes règlementaires nationales et internationales qui sont moins prédominantes sur la plupart des développements logiciels, et qui peuvent encore ajouter des temps de cycle supplémentaires.
Tout ceci représente autant d’obstacles supplémentaires au déploiement et à la transformation agile à grande échelle. Ces obstacles ne sont pourtant pas bloquants, et peuvent être surmontés en mettant en place certaines bonnes pratiques. Il est néanmoins nécessaire de les anticiper en amont lors du cadrage de la transformation à l’échelle. Nos recommandations sont les suivantes :
- Bien identifier les domaines et métiers visés par la transformation : les obstacles précédemment cités sont plus prégnants lorsque l’on considère les métiers liés au produit physique (prototypage, industrialisation, production), ce qui est moins le cas dans les métiers plus en amont dans la chaine de valeur dans les phases d’études et de conception.
- Encourager la modélisation et la simulation dans les phases amont d’architecture et de design général de manière localisée sur des sous-systèmes dans les domaines et les métiers, permettant d’avoir des boucles de simulation plus courte et régulière pour pouvoir s’adapter au cadencement de SAFe.
- Les modèles organisationnels d’agilité à l’échelle, comme SAFe, n’étant pas très explicites quant à la mise en application au développement hardware (par exemple le DevOps développant un Continuous Delivery Pipeline pour permettre un Release on Demand), il faut réussir à s’en inspirer en se basant sur les briques élémentaires du modèle, en en tirant le meilleur parti de ses rôles et responsabilités, routines, etc. pour l’adapter à son contexte particulier et le combiner à une autre méthode de gestion de projet (ex : Cycle en V).
- Enfin, donner du sens à la transformation est primordial afin d’obtenir l’adhésion des équipes, tout en montrant que la culture et la réalité terrain de l’entreprise sont bien respectées, sans donner l’impression de déployer une méthodologie sur étagère. Avoir des individus engagées et motivés est clé ! Cela peut se décliner de différentes manières : renforcer la collaboration pour mieux maitriser les interfaces (à travers des points de synchronisation réguliers par exemple), maitriser les plannings grâce à des engagements à court terme permettant de voir et estimer la valeur produite, ou encore capter régulièrement les retours clients pour s’assurer d’avancer dans le bon sens et de livrer le bon produit.
Lors de cette première partie de notre série de 3 articles, nous nous sommes focalisés sur les risques liés à la phase de déploiement d’un framework d’agilité à l’échelle.
Dans la deuxième partie, nous nous pencherons sur l’implication des parties prenantes, que ce soient les sponsors ou les acteurs de la transformation agile, en particulier afin de mettre en place un processus d’innovation qui nous semble indispensable.
Lire la suite
