« 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.


Agilité à l’échelle, le constat du terrain

Note : nous avons rédigé cet article suite à de nombreuses conversations avec des CEO de grandes organisations ainsi que des coachs agiles lors de nos conversations sur l’agilité à l’échelle. La vision de ces dirigeants à changer suite à nos échanges. Ca devrait vous parler aussi. Vous allez voir, vous allez faire plus simple!

Régulièrement, lorsqu’on entend parler d’agilité à l’échelle, c’est le framework 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

Chez Tuleap, nos différentes expériences et celles de nos clients, nous ont montrées qu’il existe en réalité « plusieurs sortes » d’agilité à l’échelle. En effet, sous ce même chapeau, nous avons constaté 3 aspects d’agilité à l’échelle.

L’agilité à l’échelle, c’est…

1. …des projets de plus en plus gros…

Ca c’est la vision de SAFe®. Nous vous invitons à lire notre article sur le framework agile SAFe pour mieux le comprendre.

2. …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 cette année!

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.

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. Un outil de Planification Agile d’Entreprise connecté à la chaine d’ingénierie logicielle apporte

5 clés pour déployer l’agilité à l’échelle

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

  1. L’agilité, c’est d’abord une culture.
  2. Pour faire grand, apprenons à faire petit.
  3. (Re)apprenons à essayer, à nous tromper.
  4. Montez à l’échelle, non pas en complexifiant les processus, mais en rendant le travail plus cohérent, les équipes mieux synchronisées.
  5. Ne partez pas seul. Faites vous accompagner.

Pourquoi les Product Backlog sont de plus en plus complexes

Revenons sur notre constat n°3, sur l’agilité à l’échelle qui arrive avec des Product Backlog de plus en plus grands, de plus en complexes. Ceci arrive 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, qui développent des produits digitaux très complexes dits cyber-physiques, nous notons de grands backlog hétérogènes, c’est-à-dire de natures très différentes. Dans un backlog industriel, vous retrouvez des users stories hardware, des US software, d’autres électroniques ou systèmes. L’enjeu consiste dans ce cas, à rendre cohérent les développements de chaque partie du produit, à prévoir des itérations calées les unes par autre aux autres, ou encore à penser les campagnes de validation 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 marketeur, n’ont pas les mêmes préoccupations. C’est la qualité de leurs multiples échanges qui donnera des user stories plus riches, au plus proche de la réalité marché donc qui satisferont un plus grand nombre de personnes. Tous ces profils doivent donc être en capacité de collaborer dans un environnement agile commun.


Rejouer notre conférence sur ce sujet