Fluid Scrum : un cadre transitoire pour passer du projet au produit (+ Cas pratique)

Fluid Scrum est un concept peu documenté, rarement formalisé et pourtant extrêmement utile dans certaines situations de transformation. 

Il n’a jamais prétendu remplacer Scrum, ni devenir un framework de référence à grande échelle.

Sa valeur est d’offrir une trajectoire pragmatique lorsque l’organisation demande « du Scrum », mais que les conditions structurelles, culturelles et produit ne permettent pas encore de l’appliquer correctement.

Cet article s’adresse aux contextes intermédiaires :

• Ceux où l’on parle produit sans en avoir encore complètement les attributs. 
• Ceux où plusieurs équipes travaillent « sur la même chose », sans que cette chose soit réellement pensée comme un produit unique.
• Ceux où l’on cherche à sortir du projet sans avoir encore réussi à se défaire de ses réflexes.

Fluid Scrum est un dispositif transitoire, volontairement imparfait, mais utile pour préparer les esprits, révéler les vrais problèmes et créer les conditions d’un passage ultérieur vers un modèle produit plus mature.

Dans cet article, je présente les origines et sources du concept. Ensuite, j'analyse le problème structurel rencontré lorsque Scrum est appliqué à des équipes trop larges ou à des produits encore fragmentés. Puis, je détaille le fonctionnement de Fluid Scrum. 

Un cas pratique illustre comment ce dispositif a permis à une équipe de 35 personnes de travailler plus efficacement sur plusieurs projets proches tout en préparant le passage vers un vrai modèle produit. 

Pour ceux qui souhaitent prolonger la réflexion, Fluid Scrum peut aussi être vu comme un outil transitoire pour mettre en œuvre certains principes du Target Operating Model illustré dans mon article précédent.

Origines et sources de Fluid Scrum

Fluid Scrum n’est pas un framework officiel porté par Scrum.org ou la Scrum Alliance.

Le concept apparaît au début des années 2010 dans plusieurs communautés agiles, notamment autour de praticiens confrontés aux limites de Scrum dans des équipes très larges ou instables.

On retrouve des traces du concept dans :

• des articles de praticiens publiés sur des blogs agiles anglo-saxons (notamment autour des notions de Fluid Teams et Fluid Sprints) ;
• des conférences communautaires où Fluid Scrum est présenté comme un pattern plutôt qu’un cadre prescriptif ;
• des travaux connexes sur les self-selecting teams, popularisés notamment par Sandy Mamoli et David Mole, qui ont largement influencé la logique de recomposition dynamique des équipes.

Fluid Scrum s’inscrit donc davantage dans une culture de patterns organisationnels que dans celle des frameworks normés.

Il emprunte à Scrum ses événements et ses rôles mais en assouplit volontairement certaines règles afin de répondre à des contraintes structurelles bien réelles.

Pourquoi Scrum échoue dans certaines organisations larges (et comment Fluid Scrum y répond)

Scrum repose en grande partie sur le prérequis de l’existence d’une équipe stable, focalisée sur un produit clairement identifié, avec un objectif unique par sprint.

Lorsque ces conditions sont réunies, Scrum fonctionne remarquablement bien.

Mais dans de nombreuses organisations, notamment issues du monde du projet ou du service, ces conditions ne sont pas encore présentes.

On observe alors des situations récurrentes :

• une « équipe » de 25 à 40 personnes officiellement rattachées à un même produit ;
• plusieurs demandes clients très proches fonctionnellement, mais traitées comme des initiatives distinctes ;
• une forte pression commerciale poussant à livrer vite, au détriment de la rationalisation ;
• une direction qui demande explicitement du Scrum, « parce que actuellement ça ne marche pas et que tout le monde dit que Scrum c’est formidable ! »  comme réponse organisationnelle.

Dans ces contextes, appliquer Scrum « by the book » crée rapidement des effets pervers : 

• les cérémonies deviennent lourdes, le Sprint Goal perd son sens, 
• les Daily se transforment en réunions d’écoute passive 
• et les équipes se plaignent légitimement de passer du temps sur des sujets qui ne les concernent pas.

Le problème n’est pas Scrum. Le problème est l’écart entre le cadre choisi et la réalité organisationnelle.

Qu’est-ce que Fluid Scrum ?

Fluid Scrum part d’un constat simple. Il vaut parfois mieux assouplir temporairement certaines règles de Scrum plutôt que de les appliquer dogmatiquement dans un contexte qui ne s’y prête pas.

Le principe central est le suivant : une grande équipe partage une vision produit et un backlog commun.

Mais le travail opérationnel est réalisé par des sous-équipes temporaires, appelées Fluid Scrum Teams (FST), qui se forment et se reforment au fil des sprints en fonction des objectifs.

Contrairement à Scrum :

• il va y avoir plusieurs objectifs par sprint à la planification globale et autant de FST ;
• les sous-équipes planifient et exécutent leur sprint de manière autonome ;
• les événements sont partiellement ventilés pour rester digestes.

L’unité de cohérence n’est plus l’équipe Scrum classique, mais l’intention produit partagée.

Fonctionnement détaillé de Fluid Scrum

Le Fluid Scrum repose sur une planification collective, une exécution déléguée à des sous-équipes temporaires et des boucles de feedback organisées à la fois au niveau local et global.

1) La planification

Le sprint démarre par une planification globale, réunissant l’ensemble du collectif.

Cette session sert à clarifier les objectifs du sprint, non pas au sens d’un Sprint Goal unique, mais comme un ensemble d’objectifs cohérents alignés avec la vision produit.

Une fois ces objectifs clarifiés, les participants se répartissent en Fluid Scrum Teams.

Cette répartition peut être facilitée, mais elle repose largement sur un mécanisme de self-selection.

Les individus choisissent l’équipe dans laquelle ils estiment pouvoir apporter le plus de valeur sur le sprint à venir.

Chaque FST réalise ensuite sa propre planification détaillée.

2) L’exécution

Chaque sous-équipe fonctionne comme une équipe Scrum classique à son échelle :

• Daily Scrum autonome ;
• Backlog de sprint dédié ;
• coordination interne.

La différence majeure réside dans le fait que ces équipes ne sont pas conçues comme pérennes. Elles existent tant que l’objectif du sprint le justifie.

3) La revue et la rétrospective

En fin de sprint, chaque FST réalise une revue légère et une rétrospective locale. Ces moments permettent de traiter les problématiques spécifiques sans polluer l’ensemble du collectif.

Ensuite, tout le monde se retrouve pour une rétrospective globale. Ce moment est clé.

Il sert à faire émerger les problèmes transverses : dépendances, incohérences de vision, dette structurelle, friction organisationnelle.

La revue globale clôture le sprint et permet de reconnecter le travail réalisé à l'intention du produit global.

Cas pratique : une organisation coincée entre projet et produit

Dans une mission de transformation que j’ai menée, j’ai accompagné une équipe d’environ 35 personnes  officiellement dédiée à un « produit ».

En réalité, elle travaillait sur cinq projets clients très similaires fonctionnellement, mais traités comme des initiatives distinctes. 

Chaque nouvelle opportunité commerciale déclenchait quasiment un nouveau produit.

La rationalisation était identifiée comme souhaitable, mais constamment repoussée au nom de l’urgence business.

La direction demandait explicitement la mise en place de Scrum.

Malgré des alertes sur la taille de l’équipe et l’absence de vision produit unifiée, le choix fut maintenu.

Très rapidement, les difficultés sont apparues.

• Les sous-groupes passaient une grande partie des cérémonies à écouter des sujets qui ne les concernaient pas. 
• Le Sprint Goal devenait artificiel.
• La frustration montait.

Plutôt que d’entrer dans une logique d’évangélisation ou de confrontation, le choix a été fait d’introduire Fluid Scrum comme solution intermédiaire.

• Un backlog global a été maintenu, avec une vision produit volontairement large.
• À chaque sprint, plusieurs objectifs étaient définis.
• Les équipes se constituaient librement autour de ces objectifs.
• Les événements étaient ventilés, permettant à chacun de se concentrer sur ce qui faisait sens pour lui.

Progressivement, des effets intéressants sont apparus.

• Les similitudes entre les projets sont devenues visibles. 
• Certaines FST se sont reformées naturellement sprint après sprint.
• Les discussions ont évolué du « client X » vers des problématiques plus génériques.

Sans imposer la rationalisation, le dispositif a permis de la rendre désirable.

Et de fil en aiguille, nous sommes passés d’une organisation projet à une organisation en feature team avec des équipes Scrum stables de moins de 10 personnes, assemblées à l’échelle sur un modèle LeSS.

Pattern organisationnel des self-selecting teams

Fluid Scrum repose très explicitement sur le pattern des self-selecting teams.

Il en reprend l’intuition centrale : les personnes sont souvent mieux placées que l’organisation pour décider où elles créent le plus de valeur à un instant donné.

Dans Fluid Scrum, la self-selection intervient au moment clé de la planification globale.

Une fois les objectifs du sprint clarifiés, les individus se positionnent volontairement sur une Fluid Scrum Team en fonction :

• de leur compréhension du besoin,
• de leurs compétences techniques ou fonctionnelles,
• de leur appétence pour le sujet,
• mais aussi de leur capacité à apprendre ou à contribuer autrement.

Ce choix rend visibles des signaux faibles que les organisations ignorent souvent.

Comme les déséquilibres de compétences, les zones de désintérêt produit, les dépendances implicites ou au contraire les noyaux naturels de spécialisation.

Fluid Scrum utilise ce pattern comme un outil d’exploration.

Les sous-équipes sont autorisées et même encouragées à évoluer d’un sprint à l’autre.

Cette plasticité permet de tester des découpages, de valider ou invalider des hypothèses d’organisation et d’observer quelles équipes tendent à se stabiliser naturellement.

C’est précisément là que Fluid Scrum se distingue, car la self-selection constitue un levier pour faire émerger une future organisation produit plus pertinente.

Comparaison avec LeSS

Fluid Scrum présente certaines similitudes avec LeSS, notamment l’existence d’un backlog commun et la coordination de plusieurs équipes autour d’un produit.

Dans LeSS, chaque équipe dispose de ses événements locaux (Daily, planification, rétrospective) et participe à des événements globaux pour l’ensemble du produit, comme :

• la Review globale, 
• l’Overall Retrospective
• et la coordination via les Area Product Owners.

Les rôles sont rationalisés et les mécanismes explicites assurent l’alignement transverse tout en conservant des équipes stables et un cadre strict.

Fluid Scrum, en revanche, accepte de relâcher certaines contraintes pour s’adapter à une organisation encore immature sur le plan produit.

Les sous-équipes se forment et se reforment à chaque sprint en fonction des objectifs et du contenu disponible.

Et la coordination repose à la fois sur des événements locaux et sur des rendez-vous globaux (revue et rétrospective globales). 

La flexibilité et l’instabilité temporaires permettent de tester les découpages, révéler des dépendances et préparer la transition vers un modèle produit plus mature. 

Fluid Scrum ne vise pas l’optimisation à long terme mais la transition et l’apprentissage organisationnel.

Fluid Scrum : limites, risques et erreurs fréquentes

Fluid Scrum n’est pas une solution miracle et ne doit pas être considéré comme une fin en soi.

Son utilisation introduit une complexité supplémentaire pour le Scrum Master, qui doit gérer plusieurs dynamiques simultanément :

• chaque Fluid Scrum Team a son propre sprint, ses propres objectifs et ses propres problèmes locaux,
• tout en nécessitant une coordination avec les autres équipes pour la revue et la rétrospective globales.

Cette double attention demande une vigilance constante et un accompagnement actif pour éviter que certaines équipes ne se détachent de la vision produit globale.

Le cadre peut également masquer temporairement des problèmes structurels.

Par exemple, des dépendances mal identifiées, des responsabilités floues ou des dysfonctionnements organisationnels peuvent rester invisibles tant que la flexibilité de Fluid Scrum absorbe les frictions.

Si l’organisation s’y installe trop longtemps sans intention claire de progression vers un modèle produit plus stable, ce dispositif risque de devenir un confort organisationnel, retardant la rationalisation et la création d’équipes pérennes.

Enfin, la répartition dynamique des sous-équipes repose sur l’auto-organisation et le principe de self-selection.

Mais si la maturité des collaborateurs ou de l’organisation est insuffisante, certaines équipes peuvent se constituer autour de compétences limitées. Ce qui réduit l’efficacité et compromet l’apprentissage transversal.

Il est donc essentiel :

• de définir des règles de gouvernance claires, 
• d’accompagner la montée en compétence des équipes
• et de prévoir des jalons pour évoluer vers un modèle produit stable et optimisé.

Tableau de comparaison de Scrum / LeSS / Fluid Scrum

Le tableau suivant permet de synthétiser et de comprendre les différences entre ces trois concepts :

Conclusion

Fluid Scrum doit être compris avant tout comme un outil de transition, un dispositif temporaire qui facilite le passage d’une organisation orientée projet vers un modèle produit plus mature.

Il ne remplace pas Scrum, ni LeSS, ni une véritable réflexion sur la structuration produit.

Son intérêt réside dans sa capacité à créer un espace d’apprentissage concret, permettant aux équipes et aux décideurs de se confronter à la réalité du delivery à grande échelle, sans subir immédiatement les contraintes strictes d’un cadre classique.

Lorsqu’il est utilisé de manière consciente et encadrée, Fluid Scrum aide à préparer les équipes à penser produit, à rationaliser le backlog, à identifier les dépendances et à stabiliser progressivement les pratiques.

Il permet de tester des découpages d’équipes, d’aligner plusieurs sous-équipes sur une vision partagée et de révéler les incohérences structurelles ou organisationnelles.

À l’inverse, mal appliqué ou laissé comme dispositif permanent, Fluid Scrum peut devenir un compromis organisationnel qui masque les vrais problèmes, entretient des pratiques dispersées et retarde l’évolution vers un vrai modèle produit stable.

La vigilance des Scrum Masters et des Product Owners est donc essentielle. 

Il ne suffit pas de mettre en place le cadre, il faut aussi l’accompagner d’objectifs clairs, de gouvernance sur les sous-équipes et de jalons de progression.

En agilité, comme souvent, la question n’est pas de savoir si le cadre est « pur », mais si son application permet à l’organisation d’évoluer, de créer de la valeur et de construire les conditions d’une transformation durable.

Fluid Scrum devient alors un tremplin pour passer du projet au produit et ne doit pas constituer un substitut définitif à une discipline produit structurée.