Agilité à l’échelle : quels pièges à éviter ? [partie 3]
Lors des 2 précédentes parties de notre série de 3 articles (partie 1 & partie 2), nous avions insisté sur les risques liés au déploiement du framework à l’échelle, ainsi qu’à l’implication des parties prenantes, qu’ils soient sponsors ou acteurs de la transformation Agile.
Dans cette troisième et dernière partie, nous nous pencherons sur les risques liés à l’environnement, souvent non-agile, dans lequel cette transformation a lieu.
Ecueil#5: Ne pas tenir compte de son environnement non-agile
Nombre d’industriels ont désormais été amenés à introduire une méthodologie Agile partiellement, voire sporadiquement, mais très rarement de manière globale et coordonnée au sein des différents acteurs de l’entreprise.
Ainsi, il arrive (trop) souvent qu’une équipe, un projet voire un département se lance dans le déploiement d’une méthode Agile, sans pour autant avoir sécurisé son intégration avec le reste de l’entreprise et donc des contraintes qui en découlent.
Puisqu’il n’est pas envisageable de systématiquement pousser ce genre de structures à basculer intégralement en Agile de manière brutale, des compromis sont à trouver par les différentes parties prenantes.
Malheureusement cela se résume souvent à contraindre les équipes ayant mis en œuvre de l’agilité à adapter leurs méthodes de travail, leur reporting ou leur framework aux contraintes imposées par ailleurs.
Toutefois certaines adaptations sont plus simples à mettre en place et acceptables que d’autres. A l’inverse, si rien n’est fait, cela peut largement mettre en péril la légitimité et donc la survie de l’organisation Agile mise en place.
D’après nous, les principaux risques pour une équipe Agile qui travaillerait dans un environnement non-Agile sont les suivants :
- L’entreprise peut imposer des jalons (exemple d’un pour un programme en développement), indépendamment du rythme de livraison de l’équipe, imposant donc une attente de résultats à des moments précis du projet.
-
- Notre recommandation : puisqu’il n’est a priori pas possible de s’affranchir de cette contrainte, il faut être le plus honnête possible quant au cadre auquel l’équipe est contrainte, sans faire miroiter une autonomie totale des livraisons et un scope totalement flexible. Cela passera alors par une responsabilisation des équipes : la cible est ce jalon, l’autonomie et l’empowement telles que décrites dans le framework agile sont possibles, à condition d’être au rendez-vous avec une maturité attendue.
- Notre recommandation : Bien que cela aille à l’encontre des principes Agile, adapter la longueur des PI Planning en fonction de ces contraintes peut être une adaptation assez simple pour s’éviter des risques supplémentaires tels que des changements de priorités en cours de PI. En complément, il est nécessaire de créer les points de rencontre avec les parties prenantes qui ne sont pas organisées en SAFe pour pouvoir synchroniser les différentes équipes.
2. Les sponsors, généralement de hauts managers de l’entreprise, pilotent des portefeuilles de projets suivant une fréquence et dans un format souvent prédéfini. S’insérer dans ce cadre de travail est indispensable pour s’assurer un bon support de leur part.
-
- Recommandation : être force de proposition quant à la forme et la fréquence des informations et des prises de décisions. Le top management en question peut aussi apprécier d’être challengé et d’avoir un reporting différent de ce à quoi il est habitué. Pourquoi ne pas l’inviter exceptionnellement lors d’une Demo agile ?
- Recommandation : quoiqu’il arrive, intégrer ce reporting au backlog Agile, afin qu’il soit considéré par l’équipe comme une tâche comme une autre, bien qu’elle soit à non-valeur ajoutée pour le produit.
3. Les méthodes agiles peuvent générer une incompréhension ou un manque de visibilité pour les interlocuteurs externes au projet, qu’ils soient clients, fournisseurs, ou simplement en interface, et qui n’y sont pas familiers.
-
- Recommandation : Passer par une phase d’on-boarding de ces interlocuteurs, puis les impliquer de manière proactive dans les rituels mis en place, afin d’éviter de devoir prendre des actions spécifiques, toujours en réaction à leurs demandes, pour chacun d’entre eux.
Conclusion
La prise en compte de ces risques et la capacité à s’en prémunir sont des facteurs clés de succès dans le déploiement et l’application d’un framework d’agilité à l’échelle.
La mise en place d’un framework SAFe n’est donc pas qu’un simple phénomène de mode à l’ère de travailler plus efficacement, plus rapidement, de manière plus agile. En effet, son implémentation persiste dans le temps, quitte à le faire évoluer ou à l’adapter au contexte particulier de l’entreprise.
Malgré tout, il faut garder en tête qu’il existe bel et bien des pièges lors de la mise en œuvre. Ceux-ci peuvent compromettre l’efficacité du modèle, alors que sa roadmap d’implémentation ne les aborde que de manière assez simpliste. C’est pour cette raison que nous proposons d’agir avec nos clients à l’aide de bonnes pratiques et recommandations dont voici la synthèse :
- Comment ne pas ou subir le déploiement d’un framework SAFe ? D’une part en impliquant les sponsors et le management dans la transformation afin de la promouvoir et de rester connecté aux réalisations du terrain. D’autre part en ne négligeant pas l’effort de conduite du changement et en démarrant bien en amont du projet.
- Comment prendre la mesure d’un déploiement / d’une implémentation sur un produit physique complexe (vs. Software / logiciel) ? Cela passe par l’identification des domaines et métiers concernés (notamment ceux directement liés au produit physique), par l’adaptation du modèle SAFe aux contraintes de l’entreprise, et sa combinaison avec des méthodes de gestion de projet tierces lorsque le framework n’est pas explicite. Il est indispensable de donner du sens à la transformation pour engager et motiver les équipes en lien avec la culture de l’entreprise.
- Comment prendre en compte l’innovation ? L’innovation n’est pas une option : il faut donc que les équipes se sentent libres d’innover avec un temps dédié et sans pression du management, qui doit au contraire l’encourager. Cet effort d’innovation doit devenir un facteur de reconnaissance pour les équipes. Utiliser des méthodologies spécifiques pour l’innovation doit aider à tirer le meilleur des équipes, même si cela passe souvent par une intervention extérieure.
- Comment bien porter la voix du client ? Une attention particulière doit être portée à l’identification et l’implication des clients. Nous recommandons notamment de mettre en place des forums d’échanges réguliers entre les clients et les Business Owners afin de mettre en place une communauté de BO et une cohérence globale, de pouvoir confronter les points de vue et de recueillir les retours des futurs utilisateurs.
- Comment bien s’intégrer avec des environnements non agiles ? La transformation doit souvent s’intégrer dans des processus ou des règles d’entreprise, qui ne sont pas liés à un environnement agile (ex : des jalons programme imposés avec des attendus stricts, du reporting régulier demandé par le top management). La transparence est alors de mise avec les équipes structurées en SAFe quant à leur autonomie qui est possible mais contrainte. Proposer un type de reporting différent de celui qui est attendu, à minima à travers des démos Agile, est un moyen de concilier les attentes du top management avec le mode d’organisation agile
Lire les articles précedents
