En équipe, vous êtes en train de faire votre plan de livraison durant la phase de préparation d’un projet X. Celui-ci est basé sur vos cas d’utilisation ou encore de vos histoires, et lorsqu’est venu le temps de déterminer votre MVP, votre PO vous indique que son produit minimum viable (MVP) constitue la livraison de l’ensemble des fonctionnalités.

Vous lui faites alors remarquer que l’essence même de l’Agilité est de piloter par la valeur, et non par le plan. Ceci implique de rendre l’investissement et le temps de développement fixe, tout en laissant la latitude d’estimer la portée qui nous permettra possiblement de faire émerger le produit minimum viable.

Votre PO vous mentionne alors que le demandeur a émis des objectifs (sur lesquels la portée a été basée) et que, pour être viable, il doit tous les rencontrer, donc il doit tout livrer!

Certains parmi vous se disent probablement que cela n’a aucun sens (ou pas) et pourtant, je suis certain que pour plusieurs d’entre vous, vous venez de vivre une impression de ce que nos voisins du Sud appelle un « déjà vu ». Non seulement cela enlève toute la latitude que l’Agilité peut apporter à votre projet, mais à quoi bon alors de faire plusieurs livraisons, et pire encore, pourquoi vous embarrasser d’un MVP!

Mais qu’est-ce qu’un MVP alors ? Un MVP est un concept provenant du Lean Startup qui, selon la Scrum Alliance, se définit comme suit : « Version d’un nouveau produit qui permet à une équipe de collecter le maximum d’informations validées sur les clients avec le moins d’effort possible ».

Comme décrit par Eric Ries, plusieurs équipes et leur PO mettent l’accent sur la portion
« minimum » du terme MVP, ce qui accentue les risques de livrer un produit dont la qualité ne serait pas suffisante pour permettre une évaluation précise de l’utilisation du produit par les clients. Pour certaines autres, l’accent est mis sur la portion « viable », et c’est pour ces équipes que cette confusion émerge comme dans le scénario décrit ci-dessus, c’est-à-dire de vouloir intégrer toutes les fonctionnalités dans notre MVP en croyant à tort que si nous ne les livrons pas toutes, nous ne pouvons décrire cela comme étant une solution qui serait viable.

Les fondations mêmes de la définition du produit minimum viable se basent sur l’apprentissage. Il ne faut pas confondre avec le Minimum Marketable Feature (MMF) ou le Minimum Marketable Product (MMP), qui eux mettent l’accent sur les gains que notre produit peut nous apporter.

Comme presque tout dans la vie, c’est une question d’équilibre. Notre MVP nous permet de mettre la « switch à On », d’avoir la qualité minimum nécessaire afin d’être fonctionnels, de nous permettre de collecter l’information nécessaire auprès des clients pour la suite de notre projet tout en ayant le nombre de fonctionnalités nécessaires afin d’être viable.

Mais si toutes les fonctionnalités sont réellement toutes requises pour rendre ma solution viable, comme un projet de conversion par exemple, que faire alors? Suis-je condamné à ne pouvoir utiliser le MVP comme pratique? Bien entendu que non! Le produit minimum viable pourra vous être également utile. La qualité minimale requise différera toujours selon chacune des fonctionnalités à livrer et il y a toujours plus d’une manière de réaliser celle-ci. Cela vous permettra d’apporter les discussions au bon niveau afin d’apprendre et de connaître les exigences/objectifs de votre demandeur, et ainsi lui permettre de possiblement faire des économies dans son investissement et dans le temps de développement de l’équipe de réalisation selon l’axe qui en découlera.