Et si l’agilité à l’échelle venait des équipes ?

Souvent les framework d’agilités à l’échelle imposent des processus lourds. Mais ne peut-on pas imaginer l’agilité à l’échelle venir des équipes ? C’est au tout cas quelque chose qui se voit de plus en plus mais qui n’est pas toujours un succès.

L’équipe choisit son fonctionnement

Dans certains grands groupes, l’agilité à l’échelle vient des équipes elles-mêmes. Il est vrai que cela peut paraitre curieux mais les résultats ne sont pas forcément mauvais.

Chaque équipe va obtenir son coach agile qui aidera l’équipe à trouver son organisation et son rythme de croisière. Sachant que chaque coach va avoir sa préférence sur l’organisation à mettre en place (xp, scrum, scrumban, kanban…), il aura sûrement une influence forte dans la décision pour les équipes ayant peu d’expériences dans le domaine. Il doit proposer des solutions selon le contexte mais ses préférences auront forcément une conséquence sur les propositions d’organisation.

Comment manager tout ce petit monde ?

Sans même parler d’agilité à l’échelle pour le moment, il peut-être intéressant d’avoir une gestion de de porte-feuilles de projets (pas forcément que agile d’ailleurs).

On parle ici de management de produits et des liens entre eux ; une équipe gérera les entrées/sorties du produit. Pour rappel, les hommes ne sont pas managés, les équipes sont 100% autonomes.

Un simple Kanban peut faire l’affaire bien qu’il est tout a fait possible de bien plus alimenter celui-ci.

Les équipes choisissent leur destiné

Dans cette façon de monter l’agilité à l’échelle, demandez à l’équipe de mettre en place l’organisation qui permettra de faire fonctionner ensemble les différentes équipes d’un même projet.

En général, l’équipe se fait accompagner d’un coach agile sur le sujet car il n’est pas si simple de bien faire fonctionner plusieurs équipes ensemble.

Exemple (fictif et simplifié par rapport à un cas réel) :

3 équipes travaillent sur un même projet : création d’un site ecommerce et 3 équipes travaillent sur un même programme (constitué lui même de 3 produits différents).

Les 3 premières équipes qui ont un seul PO ont privilégié de faire une agilité à l’échelle avec LeSS alors que les 3 équipes du Programme ont privilégiées de faire un équivalent du Scrum of Scrum.

Voici un schéma qui représente l’organisation des 6 équipes :

En effet, rien n’est perturbant si les choix des équipes ne sont pas les mêmes.

Choix dans la définition

Si vous avez connu plusieurs coachs agiles, vous ne serez pas surpris de lire que certains coachs n’ont pas la même vision voire la même définition des mots.

Voici quelques sujets sur lesquels les définitions divergent par exemple :

• le point d’effort prend-t-il le temps ou non ?
• est-ce que l’Epic est un regroupement de user-stories ou la base d’une user-story ?
• est-ce que la vélocité a vraiment un sens à être utilisée ?

Bien qu’il y ait une vraie réponse souvent pas connue de tous les coachs pour les deux premiers points, le troisième est vouée à une réelle interprétation. Mais si l’équipe 1 n’est pas alignée à l’équipe 4, est-ce vraiment grave ? Je ne pense pas pour ma part car le principal c’est que l’équipe se sente à l’aise dans sa façon de faire.

Dans un monde idéal, l’alignement des définitions seraient mieux mais les impacts des divergences de définitions sont pas énormes en réalité. Est-ce que cela vaut vraiment le coup d’y dépenser beaucoup d’énergie ? Je vous laisse seuls juges.

Pas assez organisé pour le management ?

Il est vrai qu’avec cette façon de faire, les équipes remonteront leurs propres KPI et auront leur façon de travailler. C’est parfois ce qui dérange le core management et qui le pousse à aller vers des framework d’agilité à l’échelle plus structurés à la limite de respecter certaines valeurs agiles.

Qu’est-ce qui est dérangeant d’avoir d’un côté des KPI de type « vélocité » et de l’autres de type « cycle time/lead time » ? Pourquoi chaque équipe doit avoir les mêmes KPI si ce n’est pour comparer ou faire des reporting qui tentent de pousser à la « sur » performance future ?

Avec cette façon de mettre de l’agilité à l’échelle, il faut accepter que les équipes travaillent différemment et qu’elles remontent des données différentes.

Bien cadré, l’autonomie des équipes permet vraiment de performer. Chaque méthode s’adapte mieux selon les projets et contexte donc permettre aux équipes de choisir offre de nombreux atouts :

• équipe plus motivée
• des méthodes adaptées pour chaque équipe

Un minimum d’alignement ?

Afin de ne pas se retrouver avec des équipes (voire squad) en silos, je vous conseille de mettre des communautés de culture et de pratiques en place. Ca sera fort utile d’ailleurs pour chacune des équipes.

Si dans ce type de disposition, les équipes ne s’aligneront jamais à 100% (ce qui n’est pas le but au passage), cela permettra d’amener des pratiques à converger peu à peu.

Quand une pratique plait à un grand nombre, il n’est pas rare après partage de celle-ci de la voir apparaitre dans plusieurs équipes.

Articles :

Création d’une communauté Agile en entreprise
Les communautés de pratiques pour partager et aligner

Cette méthode VS SAFe ?

J’ai volontairement mis ce titre un peu provocateur mais je pense qu’on ne peut pas comparer les deux. Le SAFe propose une solution complète aux entreprises qui veulent se lancer tout en étant rassurée d’avoir quelque chose de très structuré.

Avec l’approche de cet article, comme tout se construit à partir des équipes, il y a le ressenti d’une période de flottement et l’entreprise doit 100% faire confiance aux coachs agiles qu’elle a prise ; clairement, pour ce type de transformation, les coachs agiles sont totalement libres et il sera indispensable de leur faire confiance ; des seniors sont indispensables pour lancer le démarrage.

Conclusion

Je ne sais pas si cela peut vous donner des idées mais comme vous le voyez, il existe énormément de possibilités pour faire de l’agilité à l’échelle. Il suffit de choisir celle qui est la plus adaptée avec l’entreprise.