Dual-Track Scrum

Lorsque je rencontre des équipes produit agiles pour la première fois, les membres de l'équipe se trouvent généralement dans une situation où ils sont accablés par des réunions de Sprint Planning longues et frustrantes, car les Backlog Items sont mal définis et mal compris. La Velocity est lente et le design médiocre, parce que des détails sont encore élaborés pendant le Sprint. De plus, il y a beaucoup de gaspillage et de retouches à effectuer, car les Backlog Items n'ont pas été validés.

N'oubliez pas que notre objectif principal est de valider nos idées de la manière la plus rapide et la plus économique possible. Implémenter réellement une idée de produit et la lancer sur le marché est fondamentalement la façon la plus lente et la plus coûteuse de le faire.

Qu'est-ce que le Dual-Track Scrum ?

C'est pourquoi je suis un grand fan de ce qu'on appelle notamment le Dual-Track Scrum. Auparavant, j'utilisais le terme « Discovery Sprints », mais cela donnait l'impression d'une Discovery limitée dans le temps et d'une sérialisation des phases.

C'est Jeff Patton qui m'a parlé pour la première fois du « Dual-Track Scrum ». Je préfère ce terme car il met mieux en valeur la parallélisation de la Discovery et de la Delivery.

Le Product Discovery Track consiste à générer le plus rapidement possible des Product Backlog Items validés. Le Product Delivery Track consiste à générer du logiciel livrable.

Une autre raison pour laquelle j'aime tant la métaphore des deux « voies » du Dual-Track Scrum, c'est que je vois souvent des personnes qui intègrent essentiellement des mini-cascades dans leur framework Scrum. Le product manager effectue un travail « d'exigences » qu'il transmet ensuite à un designer. Celui-ci crée alors un design et génère ses artefacts (généralement des wireframes annotés), puis le tout est transmis à l'équipe Delivery pour le développement et les tests.

En revanche, le flux de travail en Dual-Track Scrum ne se caractérise pas par le passage d'artefacts d'un rôle à l'étape suivante. Au contraire, le Dual-Track Scrum est collaboratif – product managers, designers et lead developer travaillent côte à côte pour créer et valider les Backlog Items.

Les lecteurs de mes articles savent à quel point le User Experience Design est important à mes yeux. Cependant, le rythme et la vitesse de Scrum peuvent poser problème à de nombreuses équipes UX traditionnelles. C'est pourquoi je suis un tel fan du Lean UX. Le Lean UX et le Dual-Track Scrum sont faits l'un pour l'autre. Au lieu de nous concentrer sur les artefacts, nous nous concentrons lors de la Discovery sur les prototypes et leur validation. Un autre avantage est que ces prototypes servent de spécifications pour la Delivery.

Mais le point le plus important est que la validation ne se fait pas après la release comme dans un processus en cascade, mais qu'en Dual-Track Scrum, nous effectuons la validation déjà pendant la Discovery. Dans l'optique de valider quelque chose le plus rapidement et à moindre coût possible, nous pouvons souvent effectuer la validation avant même qu'une seule ligne de code ne soit écrite – dans l'esprit du motto « fake it before we make it », c'est-à-dire faire semblant jusqu'à ce que ça fonctionne vraiment.

Conclusion sur le Dual-Track Scrum

Si votre équipe est donc frustrée par tout ce gaspillage et par la lenteur à obtenir des résultats commerciaux concrets, vous devriez envisager le Dual-Track Scrum. Cela pourrait mener à une meilleure collaboration, des itérations et validations plus rapides, et donc à un travail de meilleure qualité.

Ce texte provient du blog de Marty Cagan et a été traduit par nos soins en français.

Stratégie d'entreprise vs. Stratégie produit

Découvre les potentiels conflits de stratégie dans notre article sur la différence entre stratégie d'entreprise et stratégie produit.