Mon article en bref
Le dual track agile fait tourner deux voies en parallèle dans une même équipe : une voie discovery qui valide ce qui mérite d’être construit, une voie delivery qui construit et met en production. La difficulté n’est pas dans la définition, elle est dans l’articulation des deux.
Voici les points essentiels à retenir :
- Définition : deux natures de travail menées en même temps, pas deux phases qui se succèdent.
- Deux logiques : le delivery cherche la prévisibilité, la discovery cherche la vitesse d’apprentissage.
- Le point de passage : ce qui franchit la frontière n’est pas une idée, c’est un problème formulé avec une solution déjà éprouvée.
- Qui fait quoi : product manager, designer et référent technique mènent la discovery, mais toute l’équipe y contribue.
- Le piège principal : couper l’équipe en deux, ce qui recrée un cycle en cascade sous un vocabulaire agile.
Le dual track agile, aussi appelé dual track scrum ou dual track development, désigne une organisation du travail produit en deux voies menées en parallèle : une voie discovery, qui valide ce qui vaut la peine d’être construit, et une voie delivery, qui transforme le validé en logiciel mis en production.
Cette définition tient en trois lignes, et c’est bien le problème : elle se retient facilement et se met en place très mal. Les méthodes de la discovery elle-même sont traitées à part ; cet article porte sur l’articulation des deux voies — qui fait quoi, comment la discovery alimente le sprint suivant, et pourquoi tant d’équipes finissent coupées en deux en croyant faire du dual track.
Sommaire
Dual track agile : définition et principe
Le principe repose sur un constat que beaucoup d’équipes vivent sans le nommer : construire un produit demande deux natures de travail difficilement compatibles. Livrer recherche la prévisibilité et la qualité. Découvrir recherche l’inverse : apprendre vite, à moindre coût, en acceptant de jeter. Jeff Patton, qui a formalisé le modèle dans Dual Track Development is not Duel Track, insiste : ce sont deux types de travail et deux modes de pensée.
Deux natures de travail, une seule équipe
Voilà ce que le schéma trahit le plus souvent : deux voies ne veulent pas dire deux équipes. Marty Cagan, dans l’article qui a diffusé l’expression, décrit un fonctionnement où product manager, designer et référent technique travaillent côte à côte pour valider les éléments de backlog — et non un enchaînement où chaque rôle transmet son livrable au suivant. Cette dernière situation porte un nom : un cycle en cascade miniature, glissé dans un cadre Scrum.
| Voie discovery | Voie delivery | |
|---|---|---|
| Question posée | Est-ce que ça vaut le coup d’être construit ? | Comment le construire correctement ? |
| Rythme | Boucles irrégulières, de quelques heures à quelques jours | Itérations régulières, le sprint |
| Ce qui sort | Une décision : construire, abandonner, continuer à apprendre | Un incrément potentiellement livrable |
| En première ligne | Product manager, designer, référent technique | Toute l’équipe de développement |
D’où vient le terme « dual track » ?
Le modèle vient d’un article de la designer Desirée Sy publié en 2007 dans le Journal of Usability Studies, qui décrivait des voies de conception et de développement conduites en parallèle chez un éditeur de logiciels. Jeff Patton en a fait un schéma d’enseignement, et Marty Cagan a popularisé l’expression Dual-Track Agile à partir de 2012. Détail rarement mentionné : aucun des deux ne défend plus ce terme. J’y reviens à la fin, car c’est sans doute l’information la plus utile du sujet.
Comment tourne la voie discovery
La voie delivery se déroule, la voie discovery tourne. C’est la différence de forme la plus concrète entre les deux, et celle qu’on oublie en dessinant deux flèches parallèles de même longueur. Une boucle ne produit pas un livrable : elle produit une décision, puis recommence.
- Formuler le pari — quel problème, pour qui, quelle solution envisagée, et à quoi l’on saura que ça marche.
- Isoler le risque le plus inquiétant — l’hypothèse qui, si elle est fausse, invalide tout le reste. C’est celle-là qu’on teste, pas la plus facile.
- Choisir la méthode la moins coûteuse — un entretien, une maquette, un wireframe cliquable. Rarement du code de production.
- Trancher — construire, abandonner, ou continuer à apprendre. Les trois issues doivent rester ouvertes.
Des boucles en heures ou en jours, pas en semaines
C’est le calibrage qui décide de tout : plusieurs boucles doivent tenir dans un sprint de deux semaines. Dès qu’une boucle dure trois semaines, elle devient un projet parallèle avec ses réunions propres. D’où la règle de coût que rappelle Jeff Patton : la façon la plus lente et la plus chère de tester une idée est de la construire en qualité production — ce qui distingue une boucle de discovery d’un MVP, déjà mis entre les mains des utilisateurs.
Deux compteurs, pas un seul
Sur la voie delivery, la vitesse mesure la quantité livrée par itération, et sa vertu est d’être stable. Sur la voie discovery, elle mesure le nombre de questions tranchées pour un coût donné. Confondre les deux compteurs mène à une absurdité fréquente : reprocher à la discovery de ralentir la livraison, alors que son travail consiste à retirer du backlog ce qui n’avait rien à y faire.
Une voie discovery qui n’abandonne jamais aucune idée n’est pas une voie discovery : c’est une file d’attente avec un vocabulaire plus flatteur.
Comment la discovery alimente le sprint suivant
Tout se joue à la frontière entre les deux voies. Ni un mur ni une porte grande ouverte : un sas, où l’on vérifie qu’un élément est prêt à changer de régime. Sans ce sas, la discovery déverse des intentions dans le backlog et le delivery instruit ses sujets en pleine itération — précisément le symptôme que le dual track prétend soigner.
Ce qui franchit le sas
Jamais une idée, rarement un document. Un élément prêt à passer côté delivery réunit quatre choses :
- Un problème formulé — pour un utilisateur identifié, pas pour « les clients » en général.
- Une solution déjà éprouvée — le prototype validé tient souvent lieu de spécification : il montre le comportement attendu mieux qu’un texte.
- Un critère de réussite — l’indicateur qui dira si le pari était bon. Décidé avant, jamais après.
- Une faisabilité dégrossie — le référent technique a dit si c’est jouable, et à quel ordre de grandeur.
Cette matière se met en forme au moment du backlog refinement, qui devient le vrai lieu de rencontre des deux voies : le résultat d’une boucle s’y transforme en user stories discutées par toute l’équipe. Le refinement cesse alors d’être une séance de découpage pour devenir le moment où l’équipe reçoit le contexte.
Qui fait quoi de part et d’autre
La discovery est menée par un trio : le product manager porte la valeur et la viabilité, le designer la désirabilité et l’utilisabilité, le référent technique la faisabilité. Ce trio ne travaille pas seul — assister à un entretien ou éprouver une piste technique se répartit dans l’équipe entière. Côté delivery, la responsabilité ne change pas ; ce qui change, c’est qu’on hérite d’un problème instruit au lieu d’une fonctionnalité datée, donc qu’on peut discuter la solution au lieu de l’exécuter.
💡 Le bon test — demandez à l’équipe ce qu’elle a appris pendant le dernier sprint, pas ce qu’elle a livré. Si la réponse ne contient aucune idée abandonnée, la voie discovery ne tourne pas encore : elle prépare.
Par quoi commencer pour mettre en place le dual track
Ni réorganisation ni cérémonie supplémentaire : la mise en place se fait sur un seul sujet, et une avance d’un sprint suffit. Chercher plus d’avance produit un stock de solutions validées dans un contexte qui aura changé quand viendra leur tour.
- Reformuler un seul élément de backlog parmi les plus incertains, en problème assorti d’un résultat attendu.
- Nommer l’hypothèse la plus risquée et la tester en quelques jours au maximum.
- Rendre la discovery visible sur le même tableau que le delivery : un travail invisible passe pour du temps volé au sprint.
- Traiter le refinement comme le sas — rien n’entre en sprint sans problème, critère de réussite et faisabilité.
- Assumer le premier abandon et le raconter en revue : c’est lui qui prouve que le dispositif sert à décider.
Un pilotage par OKR facilite l’exercice : quand l’équipe est attendue sur un résultat et non sur une liste de livrables, le temps passé en discovery n’a plus à être justifié. Sans cela, cette voie reste une pratique tolérée, la première à sauter au premier retard.
Les pièges du dual track agile
Les trois pièges qui suivent ont la même origine : le schéma des deux voies se lit comme un passage de relais, alors qu’il décrit deux activités simultanées. Une image qui se comprend en une seconde et qu’on interprète de travers pèse plus lourd qu’un long texte juste.
Piège n°1 : l’équipe coupée en deux
D’un côté ceux qui réfléchissent, de l’autre ceux qui exécutent. La dérive s’installe sans décision explicite, simplement parce que les rituels se dédoublent et que les développeurs cessent d’être invités aux entretiens. Le coût est double : le delivery perd le contexte qui lui permettait de proposer des solutions moins chères, et la discovery perd le regard technique qui l’empêchait de valider l’irréalisable.
- Signe qui ne trompe pas : les développeurs découvrent le sujet au sprint planning.
- Autre signe : la discovery a son propre tableau, que personne d’autre ne regarde.
- Le correctif : faire participer un développeur différent à chaque boucle, même une heure.
Piège n°2 : la discovery devient une phase amont déguisée
Plus discrète, cette dérive fait fonctionner la discovery en lots : on « fait la discovery » du trimestre, on en tire un dossier, puis on passe au delivery. Le vocabulaire est agile, le fonctionnement est séquentiel, et l’apprentissage se retrouve concentré avant l’engagement — au moment où l’on en sait le moins. Le marqueur est simple : la discovery a une date de fin. Un projet en a une, une voie n’en a pas.
⚠️ À surveiller — l’apprentissage ne s’arrête pas à la mise en production. Si personne ne revient mesurer l’effet de ce qui a été livré, la boucle reste ouverte et le pari n’est jamais soldé.
Piège n°3 : prendre le schéma pour le principe
Reste le piège dont les auteurs se méfient eux-mêmes. Jeff Patton dit ne pas aimer ce nom, parce que l’image suggère des métiers séparés là où l’équipe entière porte les deux travaux. Marty Cagan est allé plus loin : il a cessé d’employer l’expression à partir de la deuxième édition d’Inspired, au motif qu’elle faisait regarder le processus au lieu des principes, et parle désormais de discovery et de delivery continus.
Cette mise au point me paraît plus utile que n’importe quel gabarit d’organisation. Le dual track n’est pas un framework agile à installer, mais le nom d’un fait que toute équipe produit rencontre : on ne réfléchit pas et on ne construit pas dans le même état d’esprit. Une équipe qui apprend et livre en continu en fait sans le mot ; une équipe qui a adopté le mot, deux tableaux et un rituel de plus n’en fait pas nécessairement.
FAQ — Tout savoir sur le dual track agile
Dual track agile et dual track scrum, est-ce la même chose ?
Oui, à une nuance près. « Dual track scrum » désigne ce fonctionnement dans un cadre Scrum, avec ses sprints et ses rituels. « Dual track agile » est la formulation plus large, valable aussi en Kanban ou en flux continu. Le principe des deux voies parallèles est identique.
Faut-il deux équipes pour faire du dual track ?
Non, et c’est le contresens le plus répandu. Les deux voies décrivent deux natures de travail menées par une seule équipe. Créer une équipe discovery et une équipe delivery revient à instaurer un passage de relais, c’est-à-dire un cycle en cascade avec un vocabulaire agile.
Quelle avance la discovery doit-elle prendre sur le delivery ?
Environ un sprint, rarement plus. Il faut de quoi remplir la prochaine itération sans constituer un stock : une solution validée trop en avance sera reprise dans un contexte qui a changé, et un trimestre de sujets « validés » redevient un engagement pris avant d’avoir appris.
Comment mettre en place le dual track dans une équipe existante ?
Sur un seul élément de backlog, reformulé en problème avec un résultat attendu, dont l’hypothèse la plus risquée est testée en quelques jours. Rendez ce travail visible sur le tableau de l’équipe et faites du refinement le point de passage obligé. Aucune réorganisation n’est nécessaire pour commencer.
Le dual track agile est-il compatible avec Scrum ?
Oui, et il en comble un angle mort : Scrum décrit comment livrer un incrément, pas comment décider ce qui mérite d’y entrer. La voie discovery alimente le backlog, et le refinement sert de jonction entre les deux voies. Aucun rôle ni artefact supplémentaire n’est requis.
Le terme « dual track agile » est-il encore d’actualité ?
Le fonctionnement l’est, l’expression un peu moins. Jeff Patton dit ouvertement ne pas aimer ce nom, et Marty Cagan a cessé de l’employer parce qu’il concentrait l’attention sur le processus plutôt que sur les principes, au profit de « discovery continue » et « delivery continu ».
