Lorsque je commence à travailler avec une équipe de produits Agile, l’une des situations les plus courantes que je trouve est celle où les équipes ont des réunions de planification de Sprint longues et frustrantes car les éléments de l’arriéré sont mal définis et mal compris; ils ont une vitesse lente ainsi qu’une mauvaise conception car les détails sont encore en cours d’élaboration pendant le Sprint; et la quantité de déchets et de reprises est très élevée car les éléments de l’arriéré n’ont pas été validés.

Rappelez-vous que notre objectif d’ordre supérieur est de valider nos idées de la manière la plus rapide et la moins chère possible. En fait, la création et le lancement d’une idée de produit sont généralement le moyen le plus lent et le plus coûteux de valider l’idée.

C’est pourquoi je suis un grand défenseur de ce qui est parfois appelé Agile à Double Piste (aka Scrum à Double Piste, Faux Avant De Le Faire, Construisez Des Choses Qui Ne S’Adaptent Pas / Construisez Des Choses Qui Évoluent, Bougez Vite / Ne Cassez Pas Les Choses, Découverte Continue / Livraison Continue, etc.).

J’appelais cela simplement des Sprints de découverte, mais cela implique une découverte en boîte dans le temps, ainsi qu’une sérialisation des phases. Jeff Patton a d’abord partagé avec moi le terme “Mêlée à double piste” et je préfère ce terme car il capture mieux la nature parallèle de la Découverte et de la livraison.

La piste de découverte consiste à générer rapidement des éléments de backlog de produits validés, et la piste de livraison consiste à générer des logiciels libérables.

Une autre raison pour laquelle j’aime la métaphore Agile à double piste est que je trouve que beaucoup de gens font essentiellement de petites mini-cascades dans leur cadre Scrum. Le chef de produit effectue une sorte de travail “exigences”, qui est transmis à un concepteur qui réalise ses conceptions et génère ses artefacts (généralement des wireframes annotés), puis qui est transmis à l’équipe de livraison pour construire et tester.

En revanche, dans l’Agile à double voie, le flux de travail n’est pas caractérisé par chaque rôle livrant des artefacts à l’étape suivante; il s’agit plutôt d’une collaboration – le chef de produit, le concepteur et l’ingénieur principal travaillent ensemble, côte à côte, pour créer et valider des éléments de backlog.

Les lecteurs de ces articles savent à quel point je considère la conception de l’expérience utilisateur comme importante, mais l’une des difficultés pour de nombreuses équipes Agiles est que le rythme et le rythme de l’Agile peuvent être très difficiles sur les équipes UX traditionnelles. C’est pourquoi je suis fan de Lean UX. Lean UX et Dual-Track Agile sont faits l’un pour l’autre. Plutôt que de nous concentrer sur les artefacts, nous nous concentrons sur les prototypes et la validation de ces prototypes dans Discovery, avec l’avantage supplémentaire que le prototype sert de spécification pour la livraison.

Plus important encore, contrairement à un processus en cascade où la validation se produit après la sortie, en Agile à double voie, nous validons lors de la découverte. Dans le principe de la validation aussi rapide et bon marché que possible, la plupart du temps, nous pouvons en fait faire notre validation avant d’écrire un code de production, dans l’esprit du “fake it before we make it”.”

Donc, si votre équipe produit est frustrée par la quantité de déchets et la lenteur à obtenir des résultats commerciaux réels, envisagez d’essayer l’Agile à double voie. Voyez si cela peut inspirer un niveau de collaboration, une itération et une validation rapides qui se traduisent par un travail bien meilleur.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.