par

« Scrum, c’est pour les petites équipes. Pour notre grande organisation, il nous faut SAFe® ».

La réflexion ci dessus, nous l’avons entendue plusieurs fois. Mais il ne faut pas croire que l’agilité à l’échelle ce n’est que SAFe®. Et d’ailleurs, ce n’est peut-être pas d’agilité à l’échelle dont vous avez besoin, mais de davantage d’agilité. Stop. Faisons une pause ici et prenons du recul sur ce sujet d’actualité dans les grandes entreprises: un beau défi qui peut s’avérer devenir un chemin de croix.

Sur la base de nombreuses conversations avec des dirigeants de grandes organisations ainsi que des coachs agiles, Laurent CHARLES, CEO de Tuleap, partage dans cet article son retour d’expérience (également partagé lors d’un meet up Agile in Geneva récemment).
Vous allez voir, vous allez faire plus simple!

Le constat du terrain

Régulièrement, lorsqu’on entend parler d’agilité à l’échelle, c’est le framework agile SAFe® qui est sous-entendu. On peut éventuellement entendre parler de LESS ou de Scrum@Scale mais c’est plutôt rare. La majorité du temps, les entreprises parlent de SAFe® parce que pour elles, l’agilité à l’échelle = suivre des projets très gros.
Cela peut se comprendre. Il est vrai que les entreprises industrielles ont souvent de très gros projets logiciels à suivre: composants logiciels pour des avions, logiciels embarqués dans les automobiles…Elles cherchent donc à gérer ces projets d’envergure de façon agile. Mais cela n’est pas simple, car il y a des contraintes de toute sorte qui rendent le processus lent et complexifie les choses. SAFe® délivre des conseils intéressants sur la réorganisation de l’entreprise mais il ne fournit pas vraiment une méthode efficace pour le faire. SAFe® semble manquer de réponses pragmatiques, surtout quand l’agilité n’est pas un concept fortement ancré dans une organisation.

Les entreprises finissent trop souvent par s’enfermer dans un cadre, en tentant de l’appliquer strictement, sans l’adapter ou le remettre en cause, sans s’apercevoir que SAFe® n’a pas la réponse à tout ou qu’il n’est pas adapté à leur contexte. D’ailleurs, découvrez ici les 5 méthodes agiles à l’échelle les plus utilisées.

Si l’on regarde les choses autrement, nous arrivons à la conclusion que SAFe® n’est pas la seule voie pour faire de l’agilité à l’échelle, pour être une entreprise agile. En voici d’autres.

L’agilité à l’échelle sous 3 formes

1. L’agilité à l’échelle, c’est…des projets de plus en plus gros

Ca c’est la vision de SAFe®.

2. c’est aussi, « de plus en plus » d’agilité…

En réalité, l’agilité à l’échelle c’est aussi augmenter le nombre de projets gérés en mode agile, même si ils sont indépendants les uns des autres. Avoir des centaines de projets agiles en parallèle, certains en Scrum, d’autres en XP, d’autres en Kanban, avec des équipes aux valeurs agiles qui cherchent à s’améliorer continuellement, c’est aussi de l’agilité à l’échelle! Cela initie un changement de paradigmes dans la gestion de projet et de culture au sein de toute l’entreprise. Voici déja un très beau défi pour 2020.

3. …et de plus grand backlog

Un backlog c’est un panier. Il peut contenir pleins d’éléments différents. Il peut grossir vite. On essaye de le maintenir à jour et priorisé mais il peut évoluer très (trop) rapidement. Il faut donc gérer une multiplicité d’items, qui proviennent des clients, des départements internes, des fournisseurs, et qui bougent vite.

Mettre en place des techniques et des outils pour mieux suivre les grands backlogs, par exemple pour les projets d’envergure, c’est aussi ca, faire de l’agilité à l’échelle.
Les grands backlogs peuvent devenir complexe pour plusieurs raisons.

Différence de maturité des users stories

L’agilité à l’échelle c’est aussi de plus grands backlogs, avec des niveaux de maturité différents, qui mélangent « simple idée », « proposition de changements » et « user stories bien rédigées ». La gestion de la maturité des idées du backlog est un sacré challenge agile. Cette démarche d’innovation de produit est ce qu’on appelle « l’idéation » en Design Thinking.

Différence de nature des users stories

Chez les industriels, nous avons aussi noté des backlog hétérogènes, c’est-à-dire de natures différentes. Dans un backlog, vous retrouvez des users stories hardware, software et systèmes.

Aparté : Il existe un manifeste agile pour le Hardware en 2008, proposé par Joe Justice, un Scrum master américain. Ce manifeste est une adaptation du premier manifeste agile aux besoins spécifiques du hardware et notamment à la difficulté encore plus grande de faire des changements lorsque le processus de fabrication d’un produit est avancé.

L’enjeu ici consistera à rendre les choses cohérentes, à prévoir des itérations calées les unes par autre aux autres ou encore à penser les tests de façon globale.

De plus en plus d’intervenants

Faire parler, récolter du feedback, au plus tôt, c’est bien tout l’intérêt des approches agiles. Mais lorsque les projets deviennent plus grands, le nombre de personnes impliqués augmentent. Elles ont des rôles et des vues différents: un client, un PO, un marketeux, n’ont pas les mêmes préoccupations. Leurs échanges vont donner lieu à des user stories qui satisferont un plus grand nombre de personnes. Tous ces profils doivent donc être en capacité de collaborer dans un environnement agile commun.

Projets de plus en plus gros, plus de petits projets agiles, de plus grands backlogs, voici trois pistes d’agilité à l’échelle que vous pouvez déployez dans votre organisation. Elles sont complémentaires, donc ne vous focalisez pas sur un seul de ces axes. Essayez en un autre si l’un ne convient pas à votre entreprise. Vous avez plusieurs leviers sur lesquels agir….. mais gardez également en tête que…

Vous n’avez peut-être pas besoin d’agilité à l’échelle… mais davantage d’agilité!

Nous ne le répéterons jamais assez, l’agilité c’est d’abord une culture, des valeurs, des bonnes pratiques d’ingénierie. Vous voulez de l’agilité à l’échelle? Commencez par plus de petites équipes agiles, en Scrum ou autre.

Davantage d’agilité veut dire plus de culture, plus de bonnes pratiques, meilleurs échanges, amélioration continue, pas à pas, se concentrer sur la valeur livrée etc. Mettre en place aussi les bonnes pratiques d’ingénierie logicielle, de Devops et de software craftmanship, les pratiques d’intégration continue, de test continu, de peer coding.

5 pistes pour faire de l’agilité à l’échelle

Voici les 5 clés que vous devez garder en tête avant de partir:

  • L’agilité, c’est d’abord une culture
  • Pour faire grand, apprenons à faire petit
  • (Re)apprenons à essayer, à nous tromper
  • Monter à l’échelle, non pas les processus, mais l’automatisation par les outils
  • Ne partez pas seul. Faites vous accompagner

Rejouer le retour d’expérience sur l’agilité à l’échelle

Vous souhaitez en savoir plus sur agilité à l’échelle ?


À propos

Manon Midy

Manon travaille dans le domaine de l'ingénierie logicielle depuis 2008. Elle est attirée par le challenge de créer de la valeur économique pour une entreprise par l'innovation ouverte et l'open source. Cela l'invite à la remise en cause et l'innovation, tant dans la communication, les modèles économiques, que les approches commerciales. Manon est en charge de la communication/marketing pour Tuleap. Manon est convaincue qu'il est possible de fournir des services pros alliant les valeurs du libre (écoute, transparence, co-élaboration) avec les objectifs d'une société. Elle sait que la richesse d'une entreprise provient autant de la valeur des hommes qui fournissent les services que de sa technologie.