Comment mettre l'agilité à l'échelle : un guide pratique pour les équipes d'entreprise

Idéalement :

Dès le début de la transformation agile.

Théoriquement :

Dès que la complexité et la portée du projet deviennent suffisamment importantes pour nécessiter le travail de plusieurs ressources.

Concrètement :

À tout stade où une organisation rencontre régulièrement :

• Un manque de collaboration
• Des goulots d'étranglement métier
• Des revenus stagnants ou en déclin
• Des cycles de livraison plus lents
• Des processus complexes
• Des frictions organisationnelles
• Un travail en silos
• Des obstacles bureaucratiques
• Des défaillances de système d'une équipe à l'autre

Ce sont là tous les symptômes révélateurs d'une mise en œuvre de l'agilité qui a besoin d'être mise à l'échelle.

À ce stade, vous avez besoin d'une évaluation pour déterminer dans quelle mesure votre organisation est apte à mettre l'agilité à l'échelle. Sollicitez le soutien de la direction pour évaluer le manque d'unités spécialisées telles que les spécialistes de la conception, les spécialistes IT, les spécialistes de la sécurité, le soutien des parties prenantes, etc., afin de déterminer quels facteurs d'entreprise vous empêchent de mettre l'agilité à l'échelle.

• De bas en haut
• De haut en bas

Pour une approche de bas en haut, vous devez commencer la mise à l'échelle au niveau de l'équipe et remonter vers les autres équipes et la direction de l'organisation.
Cela fonctionne parfaitement pour des équipes indépendantes les unes des autres dans leur travail. Mais si les équipes dépendent les unes des autres, vous devez alors réévaluer votre stratégie.

L'approche de haut en bas, c'est lorsque la transition agile est d'abord adoptée par la direction supérieure, puis se répercute jusqu'au niveau de l'équipe.
Cela peut être mieux réalisé en faisant appel à un consultant ou à un coach agile qui peut vous guider dans la transition vers la mise à l'échelle de l'agilité.

Dans l'une ou l'autre approche, la transition globale ressemble structurellement à ceci : il existe un certain nombre de petites équipes multidisciplinaires qui travaillent sur un problème complexe, en le décomposant en fragments. Les équipes fournissent des solutions pour chaque élément des fragments en utilisant des produits minimum viables rapides et des boucles de rétroaction serrées. Elles collaborent ensuite pour intégrer toutes ces solutions en un ensemble cohérent. Le secret de cette collaboration est de veiller à ce que ce ne soit pas le plan, mais la réaction au changement, qui soit l'élément central. Une métrique précise pour mesurer le succès du processus est le déplacement de l'attention de la production (comme les lignes de code ou le nombre de nouveaux produits) vers les résultats (comme la croissance, les revenus et l'expérience client).

• Quelle est votre stratégie métier ?
• Combien de projets sont prévus ?
• Combien d'équipes travailleront sur ces projets ?
• Quelle est la complexité d'un seul projet ?
• Vos équipes actuelles sont-elles suffisamment équipées et compétentes pour travailler sur ces projets ?
• Qu'est-ce qui fonctionne bien ? Qu'est-ce qui doit être amélioré ?
• La culture de travail actuelle soutient-elle le changement ?
• Quels seraient vos KPI pour la mise à l'échelle de l'agilité ?
• Dans quelle mesure vos équipes connaissent-elles l'agilité ?
• Vos équipes seront-elles capables de bien performer dans un environnement agile ?
• À quoi ressemblerait une transition réussie ?
• Avez-vous identifié des risques ou des dépendances susceptibles d'affecter votre transition ?

Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe) permet aux entreprises d'atteindre leurs objectifs organisationnels afin de produire le produit de la plus haute qualité dans le délai durable le plus court. C'est une approche qui met Scrum à l'échelle d'une entreprise et vous donne la liberté de mettre à l'échelle selon vos besoins métier, quelle que soit la taille de l'entreprise, qui pourrait compter des milliers de personnes.

Outre les rôles Scrum traditionnels, SAFe comporte de nouveaux rôles définis tels que le Release Train Engineer et le Solution Engineer. On y trouve également l'ajout de cérémonies et de processus tels que le PI Planning, l'exécution du Program Increment, l'Agile Release Train, le Solution Train, etc.

Il introduit une philosophie de leadership au service des autres et lean-agile, et va au-delà de la simple mise en place d'une structure organisationnelle : il instaure plutôt un nouvel état d'esprit. Apprenez-en davantage sur l'éventail des rôles dans SAFe sur le blog Kendis.

Disciplined Agile (DA)

Disciplined Agile Delivery (DAD) est un cadre simple et flexible qui fournit des conseils adaptés au contexte, répondant aux besoins de votre entreprise pour produire plus rapidement des produits de haute qualité. C'est un modèle hybride formé par un ensemble de méthodes Lean-Agile éprouvées dans le monde entier, telles que Scrum, Kanban, XP, l'Agile Modelling, l'Unified Process et bien d'autres encore.

DA aborde la livraison de projet depuis sa conception jusqu'à sa mise à disposition des utilisateurs finaux, en faisant tomber les barrières entre le développement et les autres parties de l'organisation afin de réunir tout le monde dans un seul effort commun. Il coordonne et aligne les équipes Scrum avec le reste de l'organisation et leur travail, de sorte que tout reste transparent.

Large Scale Scrum (LeSS)

Large Scaled Scrum, abrégé en LeSS, est l'un des principaux cadres de développement logiciel agile. C'est un cadre Scrum multi-équipes qui peut être appliqué à une équipe agile composée de douze, cent, voire des milliers d'individus, travaillant tous ensemble sur un produit partagé spécifique.

En utilisant LeSS, vous pouvez créer des produits de grande ou de petite taille. C'est un cadre simple et minimaliste où l'application de règles, de processus, de rôles ou d'artefacts est moindre. Il n'existe que les rôles Scrum conventionnels tels que le product owner, le scrum master et l'équipe.

LeSS est très centré sur le client, car les équipes peuvent interagir directement avec le client tandis que le product owner se concentre sur l'établissement de la feuille de route, des priorités et de la vision à long terme du produit. Apprenez-en davantage sur l'éventail des rôles dans LeSS sur le blog Kendis.

Tribe

Le modèle Tribe popularisé par Spotify a bouleversé les cadres de mise à l'échelle de l'agilité. Spotify, un lecteur de musique populaire, a été lancé en 2008 et a maintenant grandi pour devenir des équipes réparties sur plusieurs fuseaux horaires. Ils doivent leur succès à leurs méthodologies agiles profondément enracinées et à l'utilisation de la mise à l'échelle de l'agilité, avec leur propre touche personnelle.

Les équipes appelées “Squads” dans ce cadre utilisent KANBAN, les sprints scrum, XP ou un mélange de ces méthodologies agiles pour accomplir leurs tâches. Découvrez l'éventail des rôles dans le modèle Tribe sur le blog Kendis.

• Suivre des processus et des pratiques cohérents
• Obtenir le soutien des dirigeants et des parties prenantes
• Utiliser des outils communs à toutes les équipes
• Bénéficier de la consultation ou de l'aide de coachs agiles
• Disposer d'une base solide de connaissances agiles contextuelles
• Réduire le délai de mise sur le marché
• Un environnement de travail plus flexible et réactif
• Un respect mutuel entre collègues
• Une productivité globale accrue
• Une prise de décision décentralisée

Compréhension incomplète du cadre

De nombreuses transformations agiles à l'échelle sont vouées à l'échec avant même d'être mises en pratique. La raison est triple :

• Souvent, les personnes qui dirigent la transformation supposent à tort que le simple fait d'imposer une boîte à outils va, par magie, transformer leur organisation. Dans ce cas, la limite du cadre devient la limite de leur agilité à l'échelle.
• Peu de dirigeants d'organisation font l'effort de comprendre le profil de besoins de leur entreprise avant d'adopter un cadre de mise à l'échelle particulier. Cela se traduit par un manque de préparation lorsqu'il s'agit des détails les plus fins de l'exécution, et donc par une perte de confiance de l'équipe.
• Un leadership mal préparé peut également signifier que quelqu'un décide de diriger après avoir terminé un livre ou suivi une formation rapide, sans aucune connaissance pratique de la manière dont la mise à l'échelle de l'agilité se déploie à travers les rangs d'une organisation. Cela aboutit à des processus mal mis en œuvre et à une interprétation erronée des principes.

Manque de motivation à changer

Sortir de sa zone de confort est toujours difficile, d'autant plus dans le contexte des grandes organisations. L'inertie est bien réelle. Cela signifie qu'une fois qu'une organisation s'engage dans le changement, le premier élément de son équipement doit être la motivation à ne pas se laisser intimider par l'inconfort des nouveaux processus et des terrains inconnus.

Adopter un nouvel état d'esprit

Un prérequis majeur lors de l'adaptation à tout modèle de mise à l'échelle de l'agilité est de posséder un état d'esprit lean agile. Ce n'est pas une seule personne qui doit l'avoir : il doit être ancré dans l'ADN de l'organisation. Les dirigeants doivent intérioriser le concept de leadership au service des autres, où les priorités des équipes sont placées en premier. Il faut apprendre aux équipes à s'approprier leur travail et leur donner les moyens de prendre leurs propres décisions.

Changement culturel

Dans un style de management traditionnel, les équipes sont confinées à travailler au sein de leurs silos en suivant un système hiérarchique. Elles sont fermement attachées à suivre le plan établi par la direction supérieure. Avec l'agilité à l'échelle, une nouvelle culture de travail doit être adoptée.

Elle élimine l'idée d'une hiérarchie de haut en bas, supprime les silos et renforce la transparence et la collaboration entre les équipes et la direction. L'autorité n'est plus centralisée.

Adopter cette culture prend du temps et constitue une tâche ardue, mais gratifiante. Le basculement mental vers l'adoption d'une culture où la responsabilité est partagée par tous demande beaucoup de travail et un engagement fort envers la cause de la mise à l'échelle de l'agilité.

Outils inadaptés

Construire en silos est rédhibitoire pour l'agilité. Les organisations ont tendance à utiliser des outils qui diffèrent d'un service à l'autre. Cela provoque une déconnexion.

Harmoniser la pile technologique de l'organisation est l'un des plus grands défis de la mise à l'échelle de l'agilité. Il faut un outil de suivi qui soit accessible à tous. Il doit permettre un flux d'informations transparent, favorisant la visibilité et la collaboration. Cet outil de suivi vous permettra de créer des plans stratégiques, des dépendances et des risques. Kendis est l'une de ces solutions de mise à l'échelle de l'agilité qui prend en charge tous les besoins de planification et de suivi de ses partenaires — du PI Planning et de la gestion des dépendances à la coordination au niveau Solution, en veillant à ce que tous leurs processus métier soient visibles.

Équipes distantes

Dans le monde post-pandémie, la mise à l'échelle de l'agilité à distance n'est plus un concept inédit. Elle a son propre lot de défis :

Sites multiples
Équipes distribuées
Communication interculturelle
Dépendance croissante à l'égard de facilitateurs technologiques tiers

Ce ne sont là que quelques exemples des défis rencontrés lors de la mise à l'échelle de l'agilité. Tout comme les défis, il existe également une poignée de mythes autour de la mise à l'échelle de l'agilité. Aucun de ces défis ni de ces mythes n'est impossible à gérer ; cependant, ils peuvent s'avérer difficiles à surmonter si votre organisation n'est pas pleinement préparée à y faire face.

(Besoin de partager ces défis avec votre équipe ? Utilisez notre article de blog dédié à ce sujet.)