.png)


La transition organisationnelle des grands groupes est complexe et les freins sont nombreux (choc culturel, rapport à l’échec, cycle de décision...). Certaines ont réussi à franchir la première étape et démontrer leur premier succès agile via la mise en place de petites équipes autonomes, les fameuses “squads”.
Les organisations les plus avancées cherchent aujourd’hui à augmenter l’impact de leurs équipes, et à passer l’agilité à l’échelle. Jusqu’ici protégées, ces équipes ne peuvent plus agir isolément. Elles doivent sortir de leur “bulle” et se ré-aligner avec leur organisation.
Nous vous partagions notre conviction dans un précédent article : passer l’agilité à l’échelle, c’est un peu comme creuser un tunnel. Les deux parties doivent faire leur bout de chemin : le management de haut en bas (Strategic Agility) et les équipes opérationnelles de bas en haut (Scale up).
Concentrons-nous, dans cet article, sur le second : Scale up. Comme souvent, il faut revenir aux basiques de ce qu’est le travail en équipe, et c’est dans cet esprit que nous avons créé l’Agile Index. Comment aligner les équipes sans les priver de leur autonomie ? Comment s’engager individuellement tout en impactant durablement le collectif ? Voici nos 5 petits secrets pour réussir votre passage à l’échelle de bas en haut.
Pilier n°1 : toute aventure business commence par une équipe.
Le premier défi qu’une équipe doit relever lorsqu’elle se lance dans un projet agile est de s’auto-organiser. S’il n’est pas chose aisée de se définir dans de nouveaux rôles (Product owner, Scrum Master, …), les équipes qui y parviennent voient leur niveau d’impact décuplé par un sentiment de responsabilisation accru. A l’échelle, ce sentiment de responsabilisation diminue parce que le cadre s’élargit et devient l’affaire de tous. De tous, donc de personne. Le what (ce que je fais) finit par primer sur le why (pourquoi je le fais). Au long cours, il est difficile de maintenir une équipe motivée dans de telles conditions. Remettre le sens (purpose) au centre de la démarche est alors indispensable.
En parallèle, il est clé de faire éclater la “bulle” dans laquelle chaque équipe était jusqu’alors protégée. Pour décupler la productivité et la créativité des premières équipes agiles, celles-ci ont souvent été “excubées” (en Sprint Room ou dans un espace de coworking). A l’échelle, s’isoler ne suffit plus, voire devient une menace. L’organisation doit repenser ses espaces de manière globale afin d’offrir un nid aux Corporate Startupeurs en devenir et polliniser au sein de sa propre “tribu”. Dans les organisations de plus en plus multi-localisées, ces lieux doivent être connectés et l’accès aux outils est alors lui aussi repensé comme un véritable “Service Store” à l’échelle.
Lorsqu'elle était dans sa bulle, l'équipe agile était un véritable laboratoire pour acquérir de nouvelles compétences. Souvent citée en exemple, elle était hautement sponsorisée et rayonnait à grande échelle pour remporter l’adhésion de son organisation. Elle doit désormais réintégrer la complexité de son organisation. Face à ce changement de paradigme, elle a besoin que le top management agisse comme un véritable facilitateur afin d’éliminer les obstacles les uns après les autres. C’est ce que nous appelons le Strategic Agility. Nous y reviendrons.
Enfin, l’agilité, ce sont des rôles, des outils, des méthodes… mais avant tout une véritable culture. Et lorsque les petites équipes agiles passent à l’échelle, c’est souvent un véritable choc des cultures auquel elles se heurtent. A nouveau, le top management a un rôle à jouer en devenant lui-même une équipe agile afin de diffuser cette culture par le haut.
Pour résumer, il faut maintenir une équipe auto-organisée, co-localisée, ayant les moyens de ses ambitions et partageant une culture lean et agile. Voici le premier défi du passage à l’échelle.
Pilier n°2 : cette équipe regarde dans la même direction. Elle partage une vision.
Partager une vision, c’est partager une même compréhension du problème rencontré par les utilisateurs, de la proposition de valeur à leur livrer, de l’impact à mesurer, et du ROI à générer pour l’entreprise.
Si l’on peut se réjouir de voir de plus en plus d’équipes adopter une démarche centrée-client et s’efforcer à résoudre de véritables problèmes, l’autonomie conférée à chacune les ont conduit à siloter leurs visions. Le coût d’opportunité est de plus en plus élevé. A l’échelle de l’organisation, comment réconcilier les différentes définitions du mot “client” ? Un client se définit-il par l’usage ou la transaction ? Des Customer Management Offices voient le jour, CXO en tête, afin de répondre à ces questions et ré-aligner les équipes sur une même définition du client. C’est seulement à ce prix que les expériences client, porteuses de valeur, pourront regagner en cohérence et ainsi décupler leur impact.
Car c’est de cela dont il s’agit : maximiser la valeur créée par l’organisation au global. Trop souvent, les indicateurs des petites équipes agiles se superposent, voire s’opposent. En ré-alignant les indicateurs de chaque équipe, la valeur créée par l’entreprise sera largement supérieure à la somme des valeurs créées par chacune. Et l’impact décuplé.
Un impact financier, mais pas seulement. Si les premières équipes agiles sont bien souvent sponsorisées par un management sensible à la création de valeur autrement que par la transaction (la collecte de données ou l’apprentissage des équipes sont souvent reconnues comme une véritable source de ROI), les directions financières ont une approche plus traditionnelle. Pour ne pas freiner le processus d’innovation lors du passage à l’échelle, les équipes pollinisatrices doivent aider leurs interlocuteurs historiques à repenser la notion de valeur.
Pilier n°3 : entreprendre, c’est avant tout faire. La vision n’est alors rien sans l’exécution.
Les méthodes agiles, Scrum en tête, ont offert un cadre de travail idéal aux petites équipes pour livrer de la valeur en continu, tout en maîtrisant leur niveau de risque.
Le Product Backlog, point central du Scrum, est devenu l’outil privilégié de toute équipe produit. Flexible, transparent, activable, il leur a permis de décupler leur impact. En acceptant de se ré-aligner sur une même définition du cap à atteindre, les équipes produits doivent désormais s’engager à traduire leur vision dans des feuilles de routes elles aussi ré-alignées.
Cela passe par de nouveaux rôles (Chief Product Owner par exemple), mais aussi un ajustement des rituels d’inspection et d’adaptation. Le Scrum@Scale est un cadre ouvert qui permet d’entamer sa propre route vers le passage à l’échelle de manière pragmatique.
C’est à ce prix que les équipes pourront alors continuer à livrer de la valeur en continu à leurs clients. Synchronisées, elles devront néanmoins veiller à conserver leur autonomie en améliorant significativement leurs standards DevOps et infra. Là encore, nous y reviendrons dans un billet adressés au plus techniciens d’entre nous !
Pilier n°4 : dans un monde dévoré par le logiciel, la solution est de plus en plus technique.
Ce qui rythme le quotidien d’une équipe de développement, c’est l’art de coder. On parle de craftsmanship ou encore d’artisanat. Au niveau projet, développer en respectant les modèles modernes de développement est un défi pour certains : dans un contexte business en forte accélération, nous constatons un choc des KPIs du développement (pérennité, stabilité, sécurité) et du business (time to market, évolutivité, transformation). Le nombre de standards et de savoir faire techniques s’est démultiplié (no-ops, microservice,“containerisation”, pipelines d'intégration continue, machine learning, etc.) ; ainsi que le nombre de technologies. Et le contexte de développement est de plus en plus exigeant, au point d'en écoeurer certains.
Ces enjeux se complexifient d’autant plus à l’échelle : moins les standards sont respectés, plus l’application sera difficile à maintenir dans la durée. Faire évoluer à un rythme soutenu l’application - en fonction des retours du marché - exige un code aux meilleurs standards. L’équipe de développement qui grandit doit par exemple optimiser l'intégration de nouveaux arrivants : cela passe par une documentation à jour, mais aussi et surtout par le partage de standards de code communs au sein de l’équipe. On parle notamment de code agnostique.
L’urbanisme du projet, la stack technologique et la gestion de la qualité sont les trois autres paramètres auxquels nous vous invitons à avoir une attention particulière, pour garantir la pérennité du produit livré dans un contexte de passage à l’échelle.
Pilier n°5 : un produit ne serait rien sans son marché.
Si vous êtes parvenus à ré-aligner vos équipes sur la conception et la réalisation de solutions viables… Vous n’êtes qu’au début de l’aventure. Car un produit ne serait rien sans son marché.
Apprendre et s’adapter en continu, c’est tout ce qui compte. Cela nécessite en permanence d’écouter ses clients : suivre leurs usages, recueillir leurs feedbacks et les accompagner dans la prise en main du produit pour le faire évoluer. Et si elles étaient jusqu’ici maître de leur apprentissage, les petites équipes agiles sont rapidement dépassées par le volume élevé de données collectées lorsqu’elles passent à l’échelle, et par la difficulté à maintenir un rythme de décision rapide lorsque les données sont partagées.
Dans un tel contexte, à qui appartient la donnée ? A qui appartient le client ?
Nous y reviendrons très bientôt ! Ce post s’inscrit dans un cycle de prises de parole sur l’agilité à l’échelle. Il se compose notamment d’une série de 5 articles pour approfondir les 5 piliers précédemment cités et ainsi vous donner les clés d’un passage à l’échelle réussi de bas en haut.
Stay tuned!