Depuis quelques années, j’ai vu passer tout un tas de modèles d’organisation. Certains classiques, d’autres plus exotiques. Et puis, parfois, surgit une proposition qui semble pleine de bon sens, presque pragmatique. C’est le cas du modèle “build/run alterné”. Deux équipes qui se passent le relais : l’une construit pendant que l’autre gère le run, puis inversion des rôles. Simple ? Pas tant que ça.

Le contexte de mise en place

J’ai vu ce modèle émerger lors d’une mission chez un grand groupe français. L’application concernée était critique : elle servait à coordonner des interventions humaines sur le réseau ferroviaire. Autant dire que la qualité des infos affichées était vitale.

À l’époque, deux équipes étaient en place… et se renvoyaient la balle sur les tests, les bugs, les responsabilités PROD. Impossible de sortir une release sans stress, sans frictions.

C’est là qu’on a fait un retour aux sources agiles : “You build it, you run it.”
Mais en version partagée.

Le fonctionnement : un relais organisé

Concrètement, voilà ce qui a été mis en place :

• Une équipe travaille sur une release pendant 2 à 3 sprints.
• Elle en assure aussi les tests.
• Une fois en production, cette équipe passe en mode run.
• Pendant ce temps, l’autre équipe prend le relais côté build.
  

Pas de découpage par feature, pas de spécialisation fonctionnelle. Juste une prise en charge intégrale du produit, alternée entre deux équipes. À l’époque, on ne s’était pas vraiment posé la question de la durabilité du modèle. On cherchait à réparer une situation critique, et c’était déjà pas mal.

Les bénéfices observés

Ce modèle, sur le papier, a des vertus intéressantes :

• L’équipe est responsabilisée de bout en bout, du code à la production. Etait-ce un des ancêtres du DEVOPS?.
• La connaissance fine de la release permet une résolution rapide des incidents.
• Le run n’est plus vécu comme une corvée “imposée de l’extérieur”, mais comme une partie intégrante du cycle de vie.
• Si la release est stable, l’équipe en run peut se concentrer sur la dette technique, chose trop souvent sacrifiée.
  

Les effets secondaires et limites

Mais voilà… l’idylle ne dure jamais bien longtemps. Voici les écueils constatés au fil du temps :

• La dette technique peut ne jamais être traitée, si la qualité des releases reste faible.
• Une forme d’asynchronie s’installe : chaque équipe connaît mal les releases de l’autre.
• Des silos fonctionnels invisibles apparaissent… et les compétences se cristallisent par équipe.
• La capacité globale à livrer semble baisser : deux équipes pour une même appli, mais une seule “productrice” à la fois.
  

Des tentatives d’amélioration… pas toujours fructueuses

Comme souvent, des ajustements sont tentés :

• Une non-régression transversale, confiée à des testeurs externes aux équipes..
• Une rotation partielle des membres entre les deux équipes, toutes les 2 ou 3 itérations (avec des effets mitigés sur l’engagement).
• Un backlog bonus dans l’équipe en run, pour avancer sur la suite (ou compléter la release actuelle, de l’autre équipe).
• Une comparaison malheureuse des vélocités, qui a introduit une compétition stérile.
  

Les signaux faibles d’un essoufflement

Peu à peu, des signes apparaissent… discrets mais évocateurs :

• Une remise en question permanente du modèle, sans décision claire.
• Des phrases glissées à la machine à café : “On récupère toujours les bugs des autres…”
• Une perte de sens, avec des zones d’application qui redeviennent les “territoires” d’une équipe.
  

À garder à l’esprit également :

• Des équipes moins impliquées en rétrospectives.
• Un temps de cycle allongé.
• Un modèle perçu comme “brouillon” par les parties prenantes.
  

Un modèle transitoire, pas une destination

Soyons clairs : ce modèle n’est pas fait pour durer. Trop fragile, trop de risques humains et organisationnels. Mais dans certains cas, il peut faire sens pendant un temps :

• Quand la qualité chute et que la taille de l’équipe ne permet plus une organisation stable.
• Quand chaque release génère une charge de run importante, qui empêche l’équipe de délivrer de la nouveauté.
  

C’est alors une étape intermédiaire, un révélateur, un catalyseur d’apprentissages…
Pas une solution miracle, ni un modèle cible.

Prochain article : Le modèle Spotify…

Article créé en utilisant ChatGPT comme sparring partner.