Depuis de nombreuses années, les DSI des grandes entreprises adoptent massivement les démarches agiles pour leur transformation numérique. Au regard de la taille des équipes qui peut aller de plusieurs dizaines à plusieurs milliers de personnes (managers, développeurs, architectes, testeurs, MOA…), il se pose la question de la mise à l’échelle: Agile at Scale. De nombreux frameworks ou modèles d’organisation sont maintenant disponibles, souvent soutenus par des grands auteurs du mouvement Agile.

Citons par exemple :

• SAFe for Lean Enterprises “Scaling Agile Framework”
  http://www.scaledagileframework.com
• Less “Large Scale Scrum”
  https://less.works
• Nexus basé sur un exo-squelette Scrum :
  https://www.scrum.org/resources/nexus-guide

Beaucoup d’entreprises s’appuient également sur ce qui est devenu, le « modèle Spotify », même si ses inventeurs Henrik Kniberg et Anders Ivarsson récusent cette idée de modèle à prendre tel quel (voir l’article : There is no spotify model):

Chez Operae Partners, nous accompagnons nos clients dans ce type de transformation pour mieux satisfaire le client, soutenir l’amélioration continue et favoriser la collaboration. Nous sommes donc très souvent impliqués dans ce type d’organisation. A ce titre, nous avons récemment accompagné la transformation Agile / Lean / DevOps d’une DSI impliquant plus de 1 800 personnes. L’organisation cible était un mélange de SAFe et du modèle Spotify.

Pour rappel, dans le modèle Spotify, une tribe regroupe environ une dizaine d’équipes Agiles (soit environ 100 pers. / tribe) appelée squad. La tribe a sa propre équipe de management tribe leadership: tribe manager, tribe scrum master, tribe product owner, tribe architect…

Nous nous sommes alors posé les questions suivantes : comment faciliter la collaboration d’une équipe de 100 personnes autour d’un même produit ? Comment « aligner » les personnes sur une même vision et des objectifs communs ? Comment aider une tribe à « réussir» ?

Au final, voici les objectifs que nous avons construits et validés avec le management :

• Partager une vision commune sur les ambitions: alignement des équipes
• Satisfaire au mieux les besoins implicites et explicites des clients
• Construire une représentation commune du produit pour comprendre la situation actuelle et la cible
• Garantir une bonne compréhension du planning et des enjeux sur les jalons communs
• Résoudre et surmonter ensemble les obstacles révélés par le management visuel

Nous avons mis de côté une gouvernance « classique » organisée en comités de projets, comités de pilotages et slideware car nous souhaitions minimiser la bureaucratie et les gaspillages inhérents qui peuvent vite trouver leur place dans une organisation à grande échelle. Nous sommes donc repartis des fondamentaux de l’Agile :

- Les individus et leurs interactions
[...]
- L’adaptation au changement

Et du Lean:

Satisfaire le client par une qualité irréprochable 
par l'élimination des gaspillages et des obstacles
en développant les personnes

Notre choix s’est rapidement porté sur l’obeya de projets avec laquelle nous avions déjà réussi de grands projets IT complexes.

Obeya

Un court rappel pour commencer : l’obeya est un terme japonais qui signifie « grande salle ». Elle est structurée autour d’un management visuel en 7 panneaux (Vision, Client, Produit, Performance, Macro plan, Micro plan et Résolution de problème). Cette démarche Lean centrée sur la collaboration intense entre équipes pour la réussite d’un projet ambitieux trouve ses origines dans l’industrie. A titre d’exemple,  Toyota, dans les années 90, a pu concevoir et sortir la Prius en dix-huit mois au lieu des cinq années nécessaire à ses concurrents pour construire un nouveau modèle. Cette approche rencontre de plus en plus d’adeptes dans l’IT (banque, assurance, e-commerce…) pour sécuriser les projets complexes.

Mais au-delà des panneaux, l’obeya introduit une dynamique d’équipes permettant une forte collaboration. On peut la résumer ainsi : une démarche agile de collaboration intense basée sur un management visuel pour réussir les projets complexes.

Voyons maintenant les 7 panneaux (grands formats A0 accrochés aux murs) de l’obeya dans le cas de l’agilité à l’échelle fondée sur une approche SAFe / Spotify :

Panneau vision

Ce panneau, construit à partir des éléments de stratégie de l’entreprise et de la vision IT, permet de rappeler en permanence à l’équipe quelle est la contribution de la tribe à l’atteinte de ces ambitions. C’est l’étoile du nord de la tribe, ce qui unit les équipes agiles autour de la réussite d’une ambition commune. Ce panneau évolue peu, mais l’équipe s’y réfère à tout moment pour arbitrer certaines décisions.

Dans le cadre du plan de transformation digitale de la DSI, nous avons également pris en compte les objectifs spécifiques liés à cette transformation et notamment ceux relatifs à la maturité des équipes, le bien-être au travail… On retrouvera ces objectifs dans le panneau des indicateurs de performance (ci-dessous).

Panneau clients

Le panneau « clients » doit refléter la Voix du Client. La première étape a donc été d’identifier qui sont les clients ! Question qui peut paraître simpliste quand on pratique le Scrum au sein d’une petite structure agile, mais qui s’avère plus complexe dans les grandes organisations où il existe de nombreux murs séparant les équipes de développement des clients finaux ou utilisateurs.

Après avoir identifié les clients (utilisateurs finaux, mais aussi les clients financeurs tels que MOA ou départements internes), nous avons pratiqué des interviews dite de Voix du Client pour comprendre quel était le niveau de satisfaction sur les 5 axes : Exactement ce que je veux, Quand je veux, Où je veux, Soyez fiables, Ne me faites pas perdre mon temps. Nous avons également demandé à chaque client de noter son niveau de satisfaction global sur une échelle de 0 à 10 dite de Net Promoter Score – NPS.

Ce panneau est essentiel, car même si les équipes agiles ont tendance à davantage travailler en collaboration directe avec leur product owner, elles restent souvent assez éloignées du « vrai » client. La découverte de cette voix du client est une surprise pour les équipes qui prennent alors conscience des vraies attentes du client et voient ainsi des opportunités d’amélioration importantes. Cette Voix du Client est un formidable moteur d’amélioration continue pour l’équipe et permet aussi de changer de point de vue : commencer à se mettre à la place de son client !

À côté de la Voix des Clients, nous avons également présenté les membres de la tribe : tribe manager, tribe architect, tribe test ainsi que les tribe coaches (DevOps, Lean, Agile…). Ce panneau « Who We Are », sorte de trombinoscope de la tribe, s’avère très utile pour identifier les bons acteurs, discuter des rôles et responsabilités de chacun, et indispensable pour les nouveaux arrivants.

Panneau produit

Panneau central de l’obeya, il représente le produit du point de vue du client. Il est intéressant de descendre au niveau des flux et de l’architecture applicative pour modéliser un référentiel auquel se référer lors de discussions sur l’architecture, l’urbanisation, les études d’impact…

Ici, les équipes travaillent sur des produits existants (code legacy) en Java, PHP, .NET ou encore Cobol. Nous nous sommes donc limités à représenter les produits au niveau de l’architecture applicative (des boxes et des flux entre applications).

L’objectif ici est de pouvoir se tourner vers un panneau grand format A0 lors de discussions pour positionner et afficher les problèmes sur le produit directement. C’est ce qui permet aux équipes de voir et comprendre ensemble dans l’obeya.

Panneau performance

Le panneau « performance » sert à visualiser si les équipes sont en train de réussir ou pas. Si la performance n’est pas encore au rendez-vous, c’est qu’il y a probablement des obstacles qui les empêchent d’y arriver, donc des opportunités d’amélioration ! Nous avons donc construit des indicateurs qui reflètent les ambitions du panneau « vision ». Ils doivent aussi permettre de voir les réussites et les obstacles rencontrés par les équipes. Nous avons volontairement limité le nombre d’indicateurs pour démarrer à 5 :

• Satisfaction client – mesure de la satisfaction sur une échelle de 1 à 10 (0 à 6 : détracteur, 7 et 8 : neutre, 9 et 10 : promoteur).
  Cible = 8/10
• Satisfaction collaborateurs – mesure anonyme du nombre de collaborateurs « dans le rouge » (collaborateur dans le rouge = collaborateur en difficulté dans son poste)
  Cible = 0 collaborateur dans le rouge
• % stories livrées / sprint
  Cible = 100 % des stories prévues livrées à la fin du sprint
• % stories livrées sur le Product increment (~Product burndown)
  Cible = 100 % des stories prévues livrées à la fin du product increment
• Nb incidents en stock (en production)
  Cible = diminuer le stock de 50 % chaque mois

Ces indicateurs ont rapidement mis en évidence les écarts entre la situation de départ et la cible. Cela a donc permis d’alimenter la résolution de problèmes via des des boucles d’amélioration continue PDCA « Plan-Do-Check-Act » (roue de Deming).

Ainsi, chaque nouvelle interview où le client donnait une note inférieure à la cible était une opportunité d’amélioration.

De même, pour l’indicateur de satisfaction des collaborateurs, chaque personne dans le rouge donne une opportunité au manager de comprendre les causes réelles et de mettre en place des actions d’amélioration.

Enfin, l’indicateur essentiel du % de stories livrées permettait de suivre la réussite des équipes sur chaque sprint (2 semaines) et leur capacité à délivrer dans les délais impartis. Par exemple, si la squad avait réussi à délivrer 9 user stories sur 10 prévues, on affichait 90 %. Comme toujours, en Lean, tout écart par rapport à la cible est considéré comme un « problème », donc une opportunité d’amélioration continue à travers un PDCA. L’équipe apprend et progresse sur deux aspects : mieux estimer le délai et la complexité des tâches et mieux délivrer.

Nous avions également un indicateur représentant le pourcentage d’avancement sur le Product Increment (équivalent d’un product burndown) afin de mesurer la réussite d’un Product Increment.

Panneau macro-plan

Le panneau « macro plan » est un calendrier A0 à la journée donnant une vue macroscopique sur les 6 prochains mois.

Loin d’un planning Gantt, ce panneau permet aussi de s’assurer que tout le monde partage bien les mêmes jalons tels que :

• Product Increment
• Release planning
• Mises en service / Livraisons en productions
• Frozen-zone…

Panneau micro-plan

Dans ce cas précis, nous avons construit un simple management visuel To do / Work in progress / Done avec les actions à suivre au niveau de la tribe pour l’ensemble du management et des coaches. Cela permettait de s’assurer que les coaches et managers étaient bien informés des activités de chacun (éviter les loupés, les actions en doubles…).

Panneau amélioration continue

Ce panneau permet de comprendre comment l’équipe s’améliore au fil des sprints en résolvant ses problèmes via les PDCA. L’ambition, ici, est d’aller plus loin que la rétrospective Scrum  »classique » où l’équipe va directement du problème à la solution pour chaque irritant remonté. Au contraire, la démarche de PDCA est une véritable démarche scientifique où l’on pose le problème, on mesure l’impact, on identifie des hypothèses de causes (racines) avant de proposer des actions correctives et, in fine, on mesure l’effet des actions d’amélioration pour prendre la décision selon les 3A (abandonne, adapte, adopte). Chaque PDCA correspond à un problème rencontré par une squad et est représenté sous la forme d’une feuille de papier A3.

Pour piloter l’ensemble de l’amélioration continue des squads d’une tribe donnée, chaque obstacle ou problème rencontré est représenté sous forme d’un Post-it® jaune (un titre, un porteur et l’impact mesuré) et est positionné sur un tableau à quatre colonnes en fonction de l’avancement de la résolution du problème: 1. Plan > 2. Do > 3. Check > 4. Act.

Cela permet rapidement de voir comment l’équipe met en œuvre l’amélioration continue : a-t-elle détecté beaucoup d’obstacles ? Ces obstacles sont-ils en cours de résolution ou résolus ?

En dessous du panneau, on stocke les feuilles de papier correspondant à chaque PDCA dans des pochettes plastiques afin qu’ils soient visibles et accessibles à tous (chaque Post-it® jaune a son pendant dans une feuille grand format).

Les équipes ont ainsi résolu des « petits » obstacles ayant un impact pour l’entreprise relativement limité de quelques milliers d’euros. Ils peuvent être résolus directement à l’intérieur des squads via le PDCA. Mais il y a aussi des obstacles plus transverses (inter-squads) qui doivent être portés par les membres du tribe management (posture de leadership). L’impact financier pour l’entreprise est est alors beaucoup plus important et se chiffre rapidement en centaine de milliers d’euros. Dans un PDCA, on estime l’impact sur l’entreprise en termes financiers, notoriété, satisfaction client… ce qui a pour effet de factualiser. Ainsi, on passe de « Nous avons un gros problème, c’est très urgent ! » à « On travaille sur un problème qui coûte 680 k€/an. Pourrait on avoir 20 minutes de ton temps pour nous aider à confirmer certaines hypothèses ? ».

A titre d’exemples de gros problèmes, nous avons coaché les équipes sur :

• l’accueil des nouveaux prestataires qui recevaient leurs équipements PC/accès plusieurs semaines après leur arrivée dans les locaux. Nous avons ainsi diminué ce délai en vérifiant la check-list des documents en entrée à fournir par l’ESN, en retardant si besoin la date d’arrivée et en construisant un welcome package pour accélérer la montée en compétences du nouveau.
• des blocages sur les environnements de tests empêchant de livrer les user-stories dans les délais du sprint. Le travail conjoint avec les équipes d’architectes et la production ont permis de mettre en évidence des problèmes de puissance des serveurs et aussi des conflits dans les usages de ces serveurs. Les premières solutions apportées ont donc d’augmenter le CPU / mémoire des serveurs et de proposer davantage de serveurs virtualisés.
• des difficultés sur les évolutions des messages dans le bus centralisé (ESB). L’équipe en charge de ce bus de données croulait sur les demandes souvent mal qualifiées, nous avons coaché les équipes à rédiger un standard de spécification en entrée avec une check-list, à prioriser les demandes, à réaliser des tests ok/nok en sortie sur les environnements de livraison pour réduire le délais et la charge des équipes.

Dans ces trois exemples, les solutions apportées ont un effet de levier sur toutes les squads de la tribe. On en revient au triptyque de l’obeya « Voir <> Comprendre <> Agir » ensemble.

Un nouvel outil de reporting pour un management type Command and Control ?

Comme je le disais en introduction, l’obeya n’est surtout pas un outil de reporting à destination des managers ni un outil de contrôle !

Dans ce retour d’expérience, l’obeya permet surtout d’aligner les équipes sur les ambitions de l’organisation, de développer l’écoute du client pour mieux le satisfaire et enfin d’apprendre à résoudre et surmonter les (nombreux) obstacles ce qui conduit à l’amélioration de la performance.

L’obeya apporte indéniablement de la sérénité aux équipes en stimulant la coopération : ce n’est plus ton problème, c’est notre problème et nous allons le résoudre ensemble ! Aussi, il est essentiel que les équipes investissent et s’approprient ce lieu comme leur propre salle de travail / réunion et profitent de ce management visuel en place dans l‘obeya.

Les obeya sont donc devenues naturellement des salles occupées par les équipes qui utilisaient l’information riche et continuellement mise à jour pour enrichir leurs réflexions et débats. Plusieurs cérémonies y ont lieu : démos de fins de sprints, rétrospectives, Scrum of Scrum, tribe meeting, coaches meeting…

L’obeya s’avère donc un outil formidable dans le cadre d’une transformation agile à l’échelle pour aider les équipes à ‘Voir, Agir et Comprendre ensemble » en améliorant leur qualité de vie au travail !

Et vous, comment faites-vous collaborer vos différentes équipes agiles « à l’échelle » pour qu’elles réussissent ensemble ?

Par Thomas Deligny
Merci à Christian Ignace pour ses précieux retours et Jean-Philippe Douet pour sa relecture et l’illustration.

PS/
Vidéos et lectures  sur le sujet de l’obeya:
Obeya à la DSI : l’exemple de Nike Europe

Bien démarrer un grand programme IT grâce à l’Obeya

Par ailleurs, LeSS cite l’obeya en faisant le lien entre pratiques Lean  et Agilité à l’échelle:
Obeya: Dedicated Room with Visual Management