Cadres de mise à l'échelle Agile

Résumé
Dès que les entreprises réalisent que les méthodes de travail agiles peuvent avoir un impact énorme sur le time-to-market, la satisfaction client et l'engagement des collaborateurs, elles commencent à réfléchir à la mise à l'échelle de l'agilité.

Il existe une idée reçue selon laquelle une grande organisation aurait besoin d'une approche à l'échelle. Ce n'est pas nécessairement vrai, car la mise à l'échelle est avant tout pertinente dans les cas où le produit est trop important pour être développé par une petite équipe.

La façon de découper les produits et la question de savoir s'il faut passer à l'échelle ou non sont probablement des questions plus importantes que le choix du framework de mise à l'échelle. Malheureusement, trop peu d'entreprises se posent ces questions - peut-être en raison de la forte pression des consultants qui poussent les frameworks de mise à l'échelle.

Lorsqu'une organisation doit passer à l'échelle, il existe de nombreux frameworks parmi lesquels choisir, notamment SAFe, LeSS, Scrum@Scale et quelques autres. Mais aucun de ces frameworks ne devrait être appliqué « clé en main ».

Nous sommes fermement convaincus que les entreprises devraient s'inspirer de ces frameworks, mais plutôt que de les copier, elles devraient s'orienter selon un ensemble de principes tels que la décentralisation de la prise de décision, le Lean Thinking et l'empirisme incluant l'amélioration continue.

Pour que tout type de changement réussisse, y compris la mise à l'échelle des méthodes de travail agiles, il est essentiel que les leaders adaptent leur façon de travailler. Pour la plupart d'entre eux, cela signifie passer du travail dans l'organisation au travail sur l'organisation.

L'accent principal est mis sur l'empowerment (permettre la prise de décision) et l'enabling (développer les capacités de prise de décision) des équipes et des individus. Pour y parvenir, les managers/leaders doivent, en plus du développement systématique de leurs équipes et de leurs membres, commencer à modifier les structures, les politiques et les métriques de leur organisation.

Introduction à la mise à l'échelle des méthodes de travail agiles

Dans presque chaque atelier que j'anime, les participants me demandent comment faire évoluer Scrum ou les équipes agiles à plus grande échelle. La raison de cette question est que dans leurs organisations, il est rare que seulement 10 personnes ou moins travaillent ensemble - la plupart du temps, ils sont bien plus nombreux.

Beaucoup d'entre eux viennent de grandes entreprises, que ce soit dans le secteur des services financiers, l'industrie automobile, la pharmacie ou la technologie médicale. Dans de nombreux grands groupes, ils ont des produits importants, par exemple une voiture, sur lesquels travaillent de nombreuses personnes, c'est-à-dire des centaines de collaborateurs.

Dans de nombreuses grandes entreprises, ils ont de grands produits, par exemple une voiture, sur laquelle travaillent beaucoup de personnes, c'est-à-dire des centaines.

L'erreur courante est de penser que le nombre de personnes mène automatiquement à une approche à l'échelle. Mais ce n'est pas forcément vrai. Une organisation peut avoir beaucoup de personnes et beaucoup d'équipes, mais tant que chacune de ces équipes travaille sur un produit individuel, elles n'ont pas nécessairement besoin de passer à l'échelle - du moins pas au sens agile traditionnel du terme.

Que signifie la mise à l'échelle agile ?

La mise à l'échelle agile ne devient pertinente que lorsque plusieurs équipes travaillent sur le même produit. Il est important de le souligner : plusieurs équipes travaillent sur le même produit ! Pour déterminer si tu as besoin d'une approche à l'échelle, il est donc essentiel d'examiner d'abord ta définition du produit.

Comment définir un produit ?

Il existe de nombreuses façons d'aborder cette question. L'une d'elles est la perspective client. Qu'est-ce que mes clients considèrent comme un produit, c'est-à-dire pour quoi sont-ils prêts à payer, par exemple Microsoft Office ?

Une autre perspective est plutôt interne : quels sont les différents composants d'un produit que nous pouvons développer de manière largement indépendante, par exemple Microsoft Excel ou des fonctionnalités au sein d'Excel.

Une perspective adoptée par de nombreuses entreprises n'est ni l'une ni l'autre. Elles considèrent plutôt les différentes parties architecturales d'un produit et répartissent les équipes en conséquence. Cette approche conduit généralement à des silos et à de nombreuses dépendances entre les équipes.

La deuxième option peut, dans de nombreux cas, aboutir à de nombreuses petites équipes travaillant de manière largement indépendante, de sorte qu'aucune approche formelle de mise à l'échelle n'est nécessaire. Mais même si une approche de mise à l'échelle était nécessaire, il est beaucoup plus facile de coordonner les équipes individuelles et le travail transversal, car les limites du produit sont clairement définies.

Comment mettons-nous à l'échelle ?

Plus loin dans cet article, nous résumerons les approches de mise à l'échelle les plus courantes. Mais avant d'y arriver, nous souhaitons clarifier la question de comment nous mettons à l'échelle et quels principes peuvent nous aider à mieux le faire.

Chaque équipe agile, par exemple une équipe Scrum, a trois responsabilités différentes : que construisons-nous ? Comment le construisons-nous (techniquement) ? Comment travaillons-nous ensemble (méthodologie) ? La plus grande différence entre les diverses approches de mise à l'échelle réside dans le fait qu'elles mettent à l'échelle l'unité entière, c'est-à-dire l'équipe Scrum avec toutes ses responsabilités, ou qu'elles ne mettent à l'échelle que les responsabilités du « comment ».

Cette distinction est importante car elle se rapporte directement à l'un des principes agiles les plus importants, à savoir la décentralisation de la prise de décision vers l'endroit où le travail et l'interaction client ont lieu. Elle est également importante car elle détermine combien de nouveaux rôles sont créés et quel rôle le leadership joue en dehors de ces équipes.

Quels types de frameworks de mise à l'échelle agile existe-t-il ?
Il existe de nombreuses façons de mettre à l'échelle le développement agile au sein d'une organisation. Aucune de ces approches ne couvre entièrement la façon dont une organisation devrait être structurée. Elles ne couvrent généralement que l'unité de développement produit d'une organisation.

Tous les départements support au sein d'une entreprise, comme les finances, le juridique, les RH et les achats, ne sont couverts par aucun des frameworks de mise à l'échelle. Bien que certains - y compris des consultants qui vendent ces frameworks - prétendent le contraire, ce n'est pas le cas en réalité.

Dans la section suivante, nous souhaitons partager avec toi un aperçu général des frameworks de mise à l'échelle les plus couramment utilisés. Mais sois conscient que « le plus utilisé » ne signifie pas « le meilleur ». Nous sommes fermement convaincus que chacun de ces frameworks présente des avantages significatifs, mais aussi des inconvénients considérables.

Plutôt que de simplement copier l'un de ces frameworks, il est préférable de comprendre les principes clés de la mise à l'échelle du développement agile et de créer quelque chose au sein de ton organisation qui évolue constamment grâce à des revues et ajustements réguliers et fréquents. Chaque organisation est unique dans sa culture et ses défis... ta façon de travailler devrait le refléter.

Scaled Agile Framework (SAFe)

Le Scaled Agile Framework - également connu sous le nom de SAFe - est probablement le framework de mise à l'échelle agile le mieux documenté. Il a été créé par Dean Leffingwell et est régulièrement mis à jour. Tu peux consulter la dernière version ici.

SAFe est probablement aussi le plus prescriptif de tous les frameworks de mise à l'échelle. C'est peut-être la raison pour laquelle de nombreuses grandes entreprises commencent leur parcours de mise à l'échelle avec SAFe. Comme mentionné précédemment, cela ne signifie pas nécessairement que SAFe devrait être le framework de mise à l'échelle de choix. En fait, je n'ai encore jamais vu d'implémentation SAFe réussie.

SAFe adopte une vision d'équipe d'équipes, qu'ils appellent Agile Release Train, ou ART. Un ART repose sur plusieurs équipes Scrum, Kanban ou toute autre forme d'équipes agiles. Au niveau de l'équipe, on trouve des Product Owner, des Scrum Masters et des développeurs. Au niveau de l'ART, il existe des rôles similaires appelés Product Management, Release Train Engineer (RTE) et System Architect/Engineer.

Cela signifie que SAFe fait monter en échelle l'ensemble de l'unité d'une équipe Scrum, y compris les responsabilités du "Quoi", qui relèvent alors du Product Management. Cela crée des défis importants, car un Product Owner dans SAFe n'est pas la même chose qu'un Product Owner dans Scrum. Le Product Owner SAFe est généralement une personne qui affine le backlog au niveau de l'équipe - ce qu'on ne peut plus vraiment appeler un Product Backlog.

L'un des principaux avantages de SAFe est que les entreprises ont tendance à opposer moins de résistance lors du passage à SAFe qu'avec n'importe quel autre framework - du moins c'est mon expérience. Cela peut être positif, car cela amène les entreprises à faire le premier pas vers le changement. Mais cela peut aussi être négatif si elles croient que l'implémentation de SAFe est déjà l'objectif final.

L'une des choses les plus importantes à garder à l'esprit est que plus une approche de mise à l'échelle ressemble à ta structure organisationnelle actuelle, à tes politiques et à tes métriques, moins elle produira des résultats différents. Implémenter SAFe est donc probablement plus facile que certains des autres frameworks, mais très probablement, cela ne te rapprochera pas beaucoup plus de l'atteinte de tes objectifs.

Large Scale Scrum (LeSS)

Large Scale Scrum - également connu sous le nom de LeSS - est une autre approche de mise à l'échelle fréquemment utilisée. LeSS a été inventé par Craig Larman et Bas Vodde. Tous deux sont des personnes très expérimentées et des penseurs systémiques. Tous deux sont également très singuliers dans leur approche.

Comparé à SAFe, LeSS ne met à l'échelle que les parties "comment" de l'équipe Scrum, c'est-à-dire les développeurs et partiellement le Scrum Master. LeSS dans sa forme la plus simple ne crée pas de hiérarchie de Product Owners. Cela signifie qu'un Product Owner LeSS est vraiment un Product Owner (au sens de Scrum) et travaille avec plusieurs équipes pour atteindre les objectifs du produit et pour le produit.

Sur la base de cette définition, un Product Owner dans LeSS a besoin d'équipes très matures. Matures dans leur compréhension du client, matures dans leur compréhension de la façon de décomposer les Product Backlog Items et matures en ce qui concerne la collaboration étroite avec les parties prenantes.

Comparé à une équipe Scrum non mise à l'échelle, où normalement un Product Owner prend en charge la plus grande partie du Product Backlog Refinement, de l'interaction client et de la gestion des parties prenantes, dans LeSS il n'y aurait pas assez de temps pour qu'une seule personne fasse tout cela pour toutes ses équipes.

Comme je suis un grand fan de football, j'utilise souvent des analogies du monde du football quand je parle avec des clients. Implémenter LeSS, c'est comme jouer en Ligue des Champions. Ce n'est pas quelque chose que devrait faire quelqu'un qui ne peut pas déjà démontrer une excellente implémentation Scrum.

Comparé à SAFe, LeSS supprime beaucoup de la bureaucratie des grandes organisations et avec elle de nombreux niveaux de management. Cela met beaucoup de gens mal à l'aise rien qu'en le regardant, sans parler de l'appliquer.

Une implémentation LeSS n'est pas simple et comparé à ce que d'autres frameworks prétendent, LeSS nécessite probablement le plus grand changement dans la façon dont les managers dirigent et demande aussi le plus de focus, d'énergie et de temps dans le développement des personnes. Le passage des équipes par composants aux équipes par fonctionnalités n'est qu'un exemple parmi tant d'autres.

Cela ne signifie pas que LeSS est mauvais. Si je devais choisir l'un de ces frameworks pour mon organisation ou pour mes clients, ce serait probablement LeSS. Mais LeSS nécessite aussi le plus d'engagement de la part de la direction et le plus de temps pour préparer les équipes. Il conduira probablement aussi aux résultats les plus significatifs.

Pour les initiatives de développement de produits nécessitant plus de 8 équipes, LeSS a une configuration spéciale appelée LeSS Huge. La seule différence est que LeSS met désormais aussi à l'échelle le rôle de Product Owner. Il y a toujours un Product Owner, mais pour différents domaines il y a ce qu'on appelle des Area Product Owners.

Scrum@Scale

Scrum@Scale a été inventé par le Dr Jeff Sutherland, l'un des cofondateurs de Scrum. Comme SAFe, Scrum@Scale fait évoluer l'ensemble de l'unité d'une équipe, c'est-à-dire le Quoi et le Comment.

Le niveau au-dessus de l'équipe Scrum comprend un Chief Product Owner et un Scrum of Scrums Master. Il existe un cycle Product Owner qui mène à l'Executive Meta Scrum (EMS) et un cycle Scrum Master qui mène à l'Executive Action Team (EAT).

Comme LeSS, Scrum@Scale accorde une grande importance à la décentralisation de la prise de décision vers les équipes. Jeff Sutherland lui-même est un fervent défenseur de l'idée que le Product Owner est responsable de la création de valeur pour le client et pas seulement quelqu'un qui travaille sur un backlog.

Le guide Scrum@Scale documente assez bien le fonctionnement général du framework. De temps en temps, cela devient un peu cryptique, mais l'essentiel est que Scrum@Scale est une approche fractale pour faire évoluer des équipes Scrum fonctionnelles. C'est pourquoi il ne devrait pas non plus être le point d'entrée pour chaque entreprise. En fait, on peut dire cela de tous les frameworks de mise à l'échelle.

Nexus

Nexus a été développé par l'autre co-inventeur de Scrum, Ken Schwaber. En tant que framework, il semble très similaire à LeSS, bien qu'il y ait une différence notable : le Nexus Integration Team. Sinon, Nexus - comme LeSS - fait évoluer principalement les responsabilités du Comment tout en conservant un seul Product Owner. Tu peux en savoir plus sur Nexus ici.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery - également connu sous le nom de DAD - a été inventé par Scott Ambler et Mark Lines. Je ne suis pas un expert de DAD et - bien que je travaille avec de nombreuses organisations - je ne l'ai jamais vu appliqué dans la vraie vie. Cela ne veut pas dire que DAD n'est pas utilisé ou ne fonctionne pas, juste que je ne l'ai pas vu. Tu peux en savoir plus ici.

Modèle Spotify

C'est un modèle intéressant. Les personnes clés derrière le modèle Spotify - l'un d'entre eux est mon ami Henrik Kniberg - disent qu'il n'existe pas de modèle Spotify en tant que tel. Pourtant, beaucoup de grands cabinets de conseil le vendent à leurs clients. Ils parlent de Tribes, Squads et Guilds, alors que la plupart d'entre eux (en fait tous) n'ont jamais mis les pieds chez Spotify pour voir si et comment ce "modèle" fonctionne.

Le modèle Spotify semble amusant et cool, après tout Spotify est une entreprise amusante et cool. Mais ce modèle d'une startup scandinave de streaming musical - même s'il existait - convient-il vraiment à une entreprise de télécommunications allemande, un groupe pharmaceutique suisse ou une assurance américaine ? Personnellement, j'en doute fortement.

Heureusement, personne chez Spotify ne prétend que ce modèle est universellement applicable... en fait, ils ne prétendent même pas que cela fonctionne au sein de Spotify. Si tu écoutes attentivement ce que Henrik raconte dans ses vidéos sur la culture de développement de Spotify, tu l'entendras dire que tout cela semble génial, mais qu'il y a encore beaucoup de problèmes chez Spotify et qu'ils travaillent continuellement à améliorer leur façon de travailler. Il n'y a donc pas de modèle unique chez Spotify... il n'y a que des instantanés.

Comment peux-tu faire évoluer ton entreprise de manière agile ?

Quand nous travaillons avec des organisations, notre objectif est de les aider à comprendre que même si elles peuvent tirer de nombreuses idées et inspirations de différents frameworks de mise à l'échelle, l'essentiel est de comprendre quelques principes fondamentaux de la mise à l'échelle du développement produit agile, puis de faire évoluer continuellement l'entreprise vers ces principes.

Voici quelques-uns des principes clés que nous examinons :
Ne pas mettre à l'échelle si ce n'est pas nécessaire – avant de penser à la mise à l'échelle, regarde si tu peux découper ton produit de manière à ce que de petites équipes puissent y travailler de façon indépendante, rendant ainsi la mise à l'échelle non pertinente
Chaque équipe et l'équipe d'équipes sont organisées de manière à délivrer idéalement de la valeur client et à être centrées sur le client
Appliquer le Lean Thinking, c'est-à-dire réduire le gaspillage en limitant le travail en cours, en prototypant rigoureusement (Discovery) et en recueillant fréquemment les retours clients
Améliorer continuellement les méthodes de travail grâce à des rétrospectives régulières et fréquentes au sein des équipes et entre les équipes
Décentraliser la prise de décision autant que possible en créant de la clarté et en développant les compétences au sein des équipes
Accepter l'incertitude et créer un état d'esprit empirique aussi bien pour ce qui est construit que pour la manière dont c'est construit

Cette liste est loin d'être exhaustive. Mais quand une organisation et son équipe dirigeante adoptent vraiment ces principes, nous avons constaté des améliorations considérables de l'agilité organisationnelle, de la satisfaction client et de l'engagement des collaborateurs.

Que doivent savoir les dirigeants sur la mise à l'échelle agile ?

Dans trop de cas, j'ai vu des dirigeants croire qu'ils ne seraient plus nécessaires dès que l'entreprise s'orienterait vers l'agilité. C'est l'une des raisons pour lesquelles de nombreux dirigeants résistent aux initiatives de changement organisationnel – la peur de perdre leur statut, voire leur emploi.

Je suis convaincu qu'aucun changement organisationnel ne se produira sans le management, tant au niveau de la direction qu'au niveau intermédiaire. Ces groupes sont ceux qui travaillent sur l'organisation, contrairement à tous les autres qui travaillent principalement dans l'organisation.

L'organisation elle-même est comme un produit. Elle doit être développée. Et compte tenu de l'environnement en rapide évolution pour la plupart des entreprises, je suis fermement convaincu que chaque entreprise – tout comme la plupart des produits – est un work in progress, c'est-à-dire qu'elle doit être continuellement améliorée. C'est le rôle des managers et des dirigeants dans les organisations.

Pour la plupart des dirigeants, cela signifie que leur travail change considérablement. Pour ceux qui ont jusqu'ici fait du micromanagement de leurs équipes, cela signifie responsabiliser et habiliter les équipes à prendre de plus en plus de décisions. Pour ceux qui étaient directement impliqués dans les décisions produit, cela signifie qu'ils doivent choisir s'ils veulent rester dans un rôle centré sur le produit ou s'ils veulent évoluer vers un rôle de développement organisationnel. Dans tous les cas, la plupart des managers et dirigeants doivent adapter ce qu'ils font et comment ils le font – autrement dit, la plupart doivent traverser un parcours personnel d'Agile Leader.

D'après notre expérience, il est vraiment utile d'avoir un modèle qui t'aide à structurer systématiquement ton parcours personnel et à le parcourir étape par étape avec l'aide d'un excellent coach. Si tu veux en savoir plus sur comment y parvenir, consulte nos formations Agile Leadership certifiées.