Voici la dernière des quatre valeurs principales du Manifeste Agile : l’adaptation au changement plus que le suivi d’un plan.
Dans le chapitre précédent, vous avez vu qu'il est nécessaire d'accueillir le changement, même s'il survient tard dans un processus de développement produit. Voilà comment voir les choses : apprendre quelque chose de nouveau est toujours positif, même si vous devez changer, parce que cela vous donne plus d’information sur comment résoudre les problèmes des clients.
Dans ce chapitre, nous vous expliquerons comment vous assurer que votre équipe reste agile et accepte le changement durant toutes les étapes du processus de développement produit.
Le concept de produit minimum viable
Avez-vous entendu parler du produit minimum viable ou MVP (Minimum Viable Product en anglais) ? Dans une approche agile, il peut être utile de commencer par des petits pas, des tests simples et des prototypes, en particulier lorsque l'équipe développe de nouveaux produits et hypothèses ou qu'elle explore de nouveaux domaines, marchés et technologies.
Dans son livre Lean Startup - Adoptez l’innovation continue (vous pouvez également consulter le site officiel d’Eric Ries en anglais ici), Eric Ries écrit qu'un MVP est une version du produit qui permet d'en apprendre le plus possible sur les clients avec le moins d'efforts possibles.
Un MVP ne doit pas être plus complexe que nécessaire, et sert uniquement à ce que l'équipe apprenne quel est le meilleur moyen de résoudre un problème client. Malheureusement, certains tentent de tester trop de choses à la fois et conçoivent un prototype onéreux, compliqué ou inutilement avancé.
Lorsque Dropbox, le service de stockage de fichiers en ligne, a démarré, l'entreprise a produit une vidéo de démo qui montrait les avantages de cette idée. La popularité de la vidéo a indiqué à l'entreprise qu'elle répondait à un vrai besoin utilisateur. Grâce aux feedbacks, l'entreprise a conçu un meilleur produit.
Regardez la vidéo (en anglais, avec sous-titres), puis essayez de répondre à la question : en quoi ce MVP montre-t-il l'idée principale qui se cache derrière Dropbox ?
Prenez un produit ou service numérique de votre entreprise comme exemple. À quoi aurait pu ressembler le MVP de ce produit ou service ? Rédigez votre réponse dans la section correspondante du livret d'analyse.
Utilisez les hypothèses pour apprendre des échecs comme des réussites
L'apprentissage est une activité ludique ! L'objectif de commencer petit avec un MVP est que l'équipe peut développer une nouvelle proposition, de manière itérative, afin d'en tirer des enseignements et de s'adapter pour atteindre le résultat. L'équipe utilise des prototypes et des tests pour trouver la meilleure solution aux besoins des clients. Elle élabore une proposition à l'aide de ce qu'Eric Ries appelle dans son livre Lean Startup un cycle “produire-mesurer-apprendre” (build-measure-learn en anglais).
Dans le cycle produire-mesurer-apprendre, l'équipe commence par une hypothèse.
Tout comme dans une expérience scientifique, infirmer une hypothèse est potentiellement tout aussi intéressant que la confirmer. Cela signifie que les équipes peuvent apprendre autant des réussites que des échecs.
Une bonne hypothèse est une proposition d'explication d'une observation, situation ou idée. En plus des études, des données et des analyses, les observations des clients ou leurs retours d'expérience peuvent aussi alimenter une hypothèse.
Barry O'Reilly, auteur et expert en technologies, a décrit cette technique comme le développement piloté par les hypothèses et a mis au point un canevas utile pour définir l'hypothèse à tester :
Nous pensons que <cette capacité>
Entraînera <ce résultat>.
Pour nous en assurer, nous <effectuerons les choses suivantes>.
Nous saurons que notre objectif est atteint lorsque <nous verrons un signal mesurable>.
Cette approche structurée des tests évite à l'équipe d'intégrer des biais dans sa prise de décisions et lui permet d'apprendre de façon itérative sur le meilleur moyen de répondre aux besoins du client. Voici un exemple :
“Nous pensons qu'ajouter une fonctionnalité de recherche à notre application permettra à davantage de clients de trouver ce qu'ils recherchent. Pour nous en assurer, nous testerons cette fonctionnalité sur un groupe de personnes. Nous saurons que notre objectif est atteint lorsque nous verrons une augmentation des conversions, provenant des résultats de recherche dans notre groupe test.”
Les tests et les prototypes doivent pouvoir “échouer sans risque”, c'est-à-dire que le risque est limité si le test échoue, tout en permettant d’en apprendre un maximum sur de vrais clients.
Une fois le test terminé, l'équipe fait le point sur ce qu'elle a appris et définit la prochaine hypothèse. Cette méthode crée une boucle d'apprentissage itérative qui permet à l'équipe de s'adapter.
C’est à vous !
L'histoire est désormais connue. Airbnb a démarré par un simple prototype créé par ses fondateurs à San Francisco. En 2007, la ville accueillait une conférence sur le design. Les hôtels affichaient complet. Les deux fondateurs ont alors créé un site web simple, avec une offre indiquant "AirBed&Breakfast", soit l'hébergement sur des matelas gonflables dans leur appartement, au prix de 80 $. Le test a fonctionné, la suite, tout le monde la connaît.
Comment décomposeriez-vous ce MVP pour décrire l'hypothèse des fondateurs, le test permettant de la vérifier et les critères utilisés comme signe d'échec et de réussite ?
Complétez la phrase suivante :
Nous pensons que <cette capacité>
Entraînera <ce résultat>.
Pour nous en assurer, nous <effectuerons les choses suivantes>.
Nous saurons que notre objectif est atteint lorsque <nous verrons un signal mesurable>.
✅ Solution : retrouvez ma version du MVP ici.
Apprenez de la Sprint Review et de la Rétrospective
En pratique, comment une équipe agile peut-elle vérifier qu'elle est toujours dans un cycle d'apprentissage, de hiérarchisation des priorités et d'amélioration ?
Dans le chapitre précédent, vous avez vu l'importance de montrer des résultats opérationnels aux parties prenantes pour profiter de leurs feedbacks et recueillir leur avis tout au long du processus agile. Prenez en compte ces retours lorsque vous revoyez la priorité des prochains problèmes du backlog.
Il est aussi essentiel de trouver un équilibre entre les retours des clients et ceux des parties prenantes. Lorsque l'équipe définit les priorités des problèmes du backlog, elle devrait se poser la question “à présent, qu'est-ce qui a le plus de valeur pour le client et l'entreprise ?” La réponse à cette question indique ce que devrait entreprendre l'équipe par la suite. Si des doutes subsistent sur ce qu'il faut faire en priorité, concentrez-vous sur les besoins des clients. En effet, quand les clients sont satisfaits et se sentent compris, cela se traduit généralement par la création de valeur pour l'entreprise.
Un troisième élément d'apprentissage continu dans l'agilité concerne le fonctionnement de l'équipe. Dans les approches agiles, il peut être utile d'organiser régulièrement des réunions de rétrospective (à la fin d'un sprint) pour évaluer la performance de l'équipe, comment vous avez travaillé avec les autres équipes et ce qui peut être amélioré.
Ainsi, peut-être utiliserez-vous un tableau virtuel basé sur une trame servant à faciliter les échanges. De nombreuses trames existent et sont partagées par la communauté. Un exemple de trame classique est le “4L” du nom des 4 éléments de la trame en anglais : “Liked (ce qu’on a aimé), Learned (ce que l’on a appris), Lacked (ce qui a manqué), Longed for (ce qu’on aurait souhaité)”. Lors de la rétrospective, le facilitateur ou la facilitatrice peut demander à chaque personne de coller des post-it virtuels dans chaque case du canevas, pour indiquer ce qu'elle a aimé lors du dernier sprint, ce qui lui a manqué et ce qu'elle a appris. Ensuite, vous pouvez vous servir de ces feedbacks et des thèmes les plus abordés comme base pour discuter de ce que l'équipe aimerait faire différemment.
Pourquoi ne pas prendre l'une des trames citées ci-dessus pour vous entraîner à faire une rétrospective avec votre équipe ?
Maintenez un environnement agile au sein de l'équipe
Il peut être difficile de continuer sur votre lancée avec les approches agiles, si les autres équipes de l'entreprise ne le font pas et qu'elles vous poussent à revenir aux anciennes manières de faire. De plus, les équipes qui n’utilisent pas des approches agiles travaillent souvent selon des rythmes ou cadences différentes, ce qui peut créer des interdépendances entre les équipes, qui ralentissent les équipes agiles.
Pour éviter cela, trouvez des solutions sur mesure ou établissez des relations de travail plus souples avec les autres équipes, pour que les équipes agiles puissent obtenir rapidement les informations dont elles ont besoin. Du coaching agile peut également aider l’équipe à garder les principes agiles en tête et à les appliquer quotidiennement afin de créer un changement durable.
Voici nos conseils :
Invitez des membres importants d'autres équipes à assister aux événements ou réunions de votre équipe pour voir comment vous fonctionnez.
Choisissez des personnes contact au sein des équipes avec lesquelles vous travaillez, qui feront le lien avec votre équipe. Elles feront office d'ambassadeurs en votre nom.
Soyez transparent sur les projets en cours de votre équipe, ses objectifs et sur l'aide que les autres peuvent lui apporter.
Recherchez les priorités partagées et les points communs qui peuvent créer un sentiment de collaboration et générer des avantages mutuels.
En résumé
L'approche du produit minimum viable ou MVP peut permettre à une équipe de minimiser ses investissements et ses efforts tout en maximisant les opportunités d'apprentissage. N'oubliez pas de commencer par de petits pas, évitez de tester trop de paramètres trop tôt et mettez au point le test qui pourra vous renseigner.
Utilisez des hypothèses tout au long du processus pour veiller à concevoir des tests qui pourront vous aider à prendre des décisions. Concentrez-vous sur vos convictions, sur le résultat que vous pensez obtenir de ce test et sur l'indicateur d'échec ou de réussite.
Utilisez le cycle produire-mesurer-apprendre pour procéder par itérations et vous baser à chaque fois sur ce que vous avez appris. N'oubliez pas qu'il est important d'accueillir positivement le changement, même lorsqu'il survient tard dans le processus de développement.
Servez-vous des sessions de Review et de Rétrospective pour recueillir les feedbacks et vous améliorer en continu. Tenez compte des retours des clients, de ceux des parties prenantes et du fonctionnement de l'équipe.
Allez plus loin
Maintenant que j'en sais un peu plus sur la culture agile et les approches agiles, quelle est la suite ? Et comment encourager d'autres équipes à adopter des méthodes de travail agiles ?
Voici nos conseils :
Commencez par un projet que vous aimeriez mener de manière agile.
Mettez toutes les chances de votre côté en vous assurant que vous avez obtenu l'adhésion de la direction concernant les approches agiles. Veillez aussi à ce que l'équipe ait une bonne compréhension des principes et des comportements clés.
Définissez une bonne mission ou un bon résultat pour l'équipe et veillez à ce que chacun comprenne son rôle et ses responsabilités.
Faites appel à un coach agile pour aider l'équipe dans sa transition vers de nouveaux modes de travail. Si ce n'est pas possible, nommez un champion de l'agilité qui jouera ce rôle au sein de l'équipe.
Suivez les grands principes décrits dans ce cours, mais trouvez la meilleure façon de les appliquer à votre équipe et à votre entreprise. En d'autres termes, soyez agile dans votre façon d’appliquer l’agilité!
Enfin, rappelez-vous que l'agilité, c'est aussi célébrer les petites victoires (et les échecs). Aborder l'idée avec une équipe peut donc être très motivant et exaltant !
Avant de vous laisser, je vous invite à répondre à un dernier quiz pour vérifier vos connaissances. Bonne chance !
