Parce que l’agilité à l’échelle est l’un des enjeux cruciaux des grandes organisations, nous avons interrogé quatre experts afin de constituer un ebook, permettant de comprendre les apports de l’agilité à l’échelle et SAFe. L’article suivant est un extrait de cet ebook et nous permet de voir comment initier une approche d’agilité à l’échelle.
On privilégie le partage d’expérience et la synchronisation hebdomadaire
Partage d’expérience en tant que Coach Agile au sein de la DSI de la Caisse des Dépôts en France, pour la mise en oeuvre de la plateforme « Banque des Territoires ».
Lors du démarrage d’une nouvelle structure ayant pour objectif de mettre en place une plateforme bancaire unique quel que soit le type de client et le produit proposé, la phase de cadrage et la définition du MVP ont été animées par une équipe de 3 coachs agiles internes, avec l’assistance de deux coachs externes :
Le Product Manager, futur directeur de la structure, a pu être formé et coaché en même temps que les équipes. Une vision produit a été définie : à l’origine, un slide tiré d’un COMEX de lancement de la nouvelle plateforme (les 7 promesses de la plateforme), partagé et décliné avec toutes les équipes (certaines constituées pour la nouvelle plateforme, d’autres préexistantes, soit 80 personnes en tout).
Le backlog a été défini à partir d’une feuille blanche, avec les Product Owners par «équipe» (au début les équipes étaient organisées en Component Team), priorisé (identification du MVP dès le départ par la question : “Dans 4 mois, que voulez-vous présenter à vos clients?).
Sur cette base de départ il a été possible de créer une dynamique de réunion hebdomadaire des PO, sous la responsabilité du Product Manager, et consolider progressivement les nouveaux backlogs et les backlogs existants.
L’auto-désignation des Scrum master dans les équipes, complétée par des recrutements, a permis d’amorcer une communauté, qui a mis en place très tôt un partage d’expérience et une synchronisation hebdomadaire ; ce sont eux qui ont été les interlocuteurs pour la mise en place des outils de gestion du backlog et de management de projet agile.
Les rôles transverses ont trouvé des personnes engagées, y compris pour la logistique des évènements.
On met un point d’honneur sur le besoin client
Partage d’expérience de SoCraAgile, en tant que Coach Entreprise dans la Haute Horlogerie en Suisse.
Comme lors de chaque accompagnement à la transformation organisationnelle, nous avons en premier lieu pris le temps de bien comprendre le besoin du client. Ce point n’est pas négligeable, nous avons souvent rencontré des dirigeants voulant mettre un framework de mise à l’échelle, plus pour des raisons d’outils, que d’un réel besoin. Nous sommes pragmatiques, et nous considérons que les frameworks peuvent toujours être ajustés au besoin de l’organisation, tant qu’elle respecte le Manifesto agile.
Dans ce cas, notre client nous avait contacté pour la mise en place de SAFe 5 dans leur organisation. Après compréhension du vrai besoin, nous avons compris qu’en réalité, l’attrait pour SAFe était uniquement dû à un phénomène de mode : si une autre société l’a mis en place avec succès, cela voulait dire que c’était le meilleur framework… Nous avons finalement proposé de mettre en place Scrum@Scale (aussi connu sous Scrum of Scrum), ce qui leur permet de faire une mise à l’échelle au besoin, sans ajouter de complexité dans un système déjà fort complexe.
La première étape a été de créer des équipes autour de produits indépendants les uns des autres. Ceci est important car nous changeons radicalement de paradigme. L’organisation n’est plus conduite par des “projets”, mais par des “produits” qui sont suivis sur du long terme. Un Product Owner sera en charge d’un produit (ensemble d’applications regroupées sous un produit commun) ; il va gérer des besoins stratégiques, des besoins d’évolution, de la maintenance technique et des incidents.
Puis on commence par mettre en place les équipes agiles, et on les fait monter en maturité. Ceci est également important pour la suite des choses. Des équipes qui ne se comportent pas en équipe Scrum seront difficilement mises à l’échelle plus tard. Si la partie “facile” du système ne peut pas être adaptée, alors à quoi bon essayer une mise à l’échelle.
Le premier outil de mise à l’échelle en place sera les “Scrum de Scrum” (sorte de Daily Scrum) et la “Rétrospective à l’échelle”. Grâce à ces deux événements, nous amenons plus de la transparence et l’amélioration continue entre équipes.
Le reste viendra par petit pas, selon la maturité des équipes et du système en son entier.
On favorise la synchronisation et la cohésion des équipes
Partage d’expérience en tant que Coach Agile au sein d’un programme complexe d’environ 250 personnes dans le domaine de l’énergie.
Je vais parler de ce contexte particulier où le déploiement de SAFe au niveau Solution (ou en tout cas une mauvaise interprétation) a été tentée, sans accompagnement et sans succès. Il est à noter que ce programme est très complexe, aussi bien en termes de nombre de composants, interfaces, technologies, organisations différentes que de répartitions géographiques.
La première étape a été de déconstruire cette implémentation qui ne fonctionnait pas, tout simplement en expliquant aux acteurs concernés que ce qu’ils faisaient (des PI Plannings de 15 personnes qui planifient des activités de spécifications puis qui suivent toutes les semaines où ils en sont sur ces spécifications – la partie Solution donc de leur point de vue) n’était ni agile, ni du SAFe.
Nous avons ensuite attaqué la partie la plus évidente pour moi à ce moment là : plusieurs équipes composants devaient travailler ensemble pour livrer une solution. Or, des interviews individuelles m’ont vite fait comprendre que non seulement les équipes ne se côtoient pas, ne se connaissent pas mais aussi que chacune poursuit un objectif individuel (livrer son composant) et non pas collectif (livrer la solution).
Nous avons donc mis en place des synchronisations hebdomadaires entre représentants de ces équipes, sont alors apparues des premiers échanges intéressants pour tenter de livrer et intégrer les composants au fil de l’eau (les équipes travaillaient pour la plupart en Scrum mais avec des durées d’itérations différentes). Des premières démos communes ont eu lieu.
Nous sommes ensuite arrivés à un consensus pour cadencer les équipes sur le même rythme (itérations de 3 semaines), après plusieurs semaines de négociation.
Nous avons alors organisé un premier “vrai” PI Planning qui a eu lieu en janvier 2019 avec 80 personnes mais peu d’équipiers, nous n’avions alors pas réussi à convaincre du bien-fondé et de l’importance de leur présence. Malgré les doutes de beaucoup de personnes, ce PI Planning s’est bien déroulé (en tout cas pour un premier), d’autant qu’il a abouti notamment à la mise en lumière de problématiques importantes concernant une équipe centrale. Les synchros autour d’un management visuel, les rétrospectives et démos communes sont entrés dans les mœurs.
Quelques décisions (ou non-décisions) managériales et un confinement plus tard, une période d’errement a commencé où peu de choses ont évolué.
Enfin, depuis 2 mois, une nouvelle énergie a permis d’accélérer et d’élargir cette transformation, créée par un push du top management, une vision commune et partagée, la constitution et l’alignement d’une équipe de transformation, un manager leader qui prend part à cette équipe, des renforts de coaching tout récents.
Nous venons de lancer ou plutôt d’officialiser l’existence de 3 Agile Release Trains (au moins 4 ou 5 autres seront lancés l’année prochaine, tous sont déjà cadencés sur le même rythme des itérations et Program Increment) qui livrent 3 solutions (et évidemment, ce n’est pas du 1 pour 1, il y a des dépendances) : cela signifie organiser 3 vrais PI Plannings (les développeurs étaient là !), un pre-Program Increment et un post-Program Increment, officialiser, former et accompagner les rôles clés des trains (les trios Release Train Engineer / Product Owner / SAFe Agilist) et des solutions (Solution Train Engineer / Scrum Master / SAFe Agilist), accompagner les équipes là où il y a des manques.
En parallèle, pour cette fin d’année, un gros travail de mise en place du portfolio va s’opérer : backlog commun et à plusieurs niveaux, priorisation, rituels, outillage… Car il y a un vrai manque à ce niveau là qui impacte les équipes.
D’autres chantiers nous attendent également l’année prochaine : travailler sur des livraisons incrémentales, impliquer beaucoup plus le client, mettre en place des communautés de pratiques, harmoniser et améliorer l’outillage, etc …