Board Miro avec un modèle Agile à deux voies
De Wiki Agile
Auteur : Aleksei Sotskov
Source : MIRO BOARD WITH A DUAL-TRACK AGILE MODEL
Date : 11/05/2024
Traducteur : Fabrice Aimetti
Date : 12/05/2024
Traduction :
Il y a plusieurs mois, j'ai partagé sur LinkedIn une ébauche de diagramme pour un modèle Agile à deux voies. Grâce à la réaction de Marty Cagan et d'autres personnes, ce post (https://lnkd.in/dXdSiDdC) a reçu beaucoup de réactions, commentaires et questions. J'ai utilisé ce feedback pour corriger le diagramme et j'ai posté une version mise à jour dans les commentaires de ce post, mais le diagramme mis à jour s'est perdu là et les gens ne l'ont certainement pas vu.
Je n'aimais pas non plus la conception initiale de ce diagramme, mais j'espérais trouver un concepteur qui connaissait / apprenait le modèle Agile à deux voies et qui pourrait s'exprimer et éventuellement m'aider à mieux dessiner ce diagramme.
Le temps a passé et je n'ai pas rencontré un tel concepteur, mais j'ai remarqué que les Product Managers sur LinkedIn partagent des liens vers de jolis boards Miro - j'ai donc décidé de dessiner ce diagramme de modèle Agile à deux voies dans Miro pour (1) m'entraîner à travailler avec Miro, (2) republier une version mise à jour d'un modèle et (3) diffuser encore plus les connaissances sur ce modèle.
👉 Board Miro partagé : https://lnkd.in/dj7wxNXi
P.S. : si vous avez aimé le diagramme, merci d'aimer / commenter / reposter -- pour que plus de gens puissent le voir (si vous ne l'aimez pas, merci de me dire pourquoi aussi) ! Merci !
#dualtrackagile #agile #productmanagement #miro
Cela semble trop compliqué. Je vais réfléchir à la simplification dans une prochaine version. Merci pour vos commentaires 👍
Feedback de Christina Nadler :
OKR : ne faudrait-il pas faire la différence entre la définition d'objectifs et le fait de laisser l'équipe dériver / déterminer les résultats clés ?
Concept initial où il manque une boucle de feedback, donc ça ressemble à du Waterfall donc un processus top-down :
Version simplifiée du modèle où il manque une boucle de feedback, donc ça ressemble à du Waterfall donc un processus top-down :
Feedback de Murray Robinson :
On devrait sans doute avoir une représentation plus proche du Double-diamant ou du Modèle en W :
Feedback de Wolfram Müller :
Ce que nous voyons également dans les entreprises hyper-agiles, c'est une Oscillation - les phases de discovery et le delivery du produit ne sont pas en parallèle, mais se suivent l'une l'autre ... cela se passe comme ceci : * une phase axée sur la livraison d'un MVP/MVR - qui a le statut de projet et se concentre sur une livraison entre 4 à 6 mois... puis après la livraison * une phase d'hyper vigilance suit - axée sur les données, en observant le client et la façon dont il utilise le produit, en corrigeant / en améliorant le produit au quotidien ... à partir de là, l'étape de discovery commence ... il s'agit de trouver la contrainte de la chaîne de valeur du client ... et ensuite le MVR suivant (minimum valuable release) émerge. Il s'agit donc, comme vous l'avez proposé, d'un découplage, car les deux phases ont des caractéristiques différentes. Ce n'est pas parallèle avec tous les effets négatifs, mais une oscillation rapide est très puissante.
Feedback de Alexey Krivitsky :
La voie double et non la duel des voies : un article de Jeff Patton à lire absolument pour tous ceux qui réfléchissent à la manière d'intégrer le discovery dans le diagramme💡 : Dual Track Development is not Duel Track (en)
Feedback de Jürgen De Smet :
Agile révélé : maîtriser la découverte et la livraison de produits
Feedback de Aleksei Sotskov :
Je reconnais que le diagramme peut ressembler à du Waterfall. Mais le modèle lui-même n'est pas du tout en Waterfall ! Par exemple, dans ce modèle, nous avons plusieurs déploiements en production par semaine, voire par jour, et le code que nous avons écrit aujourd'hui, s'il arrive en production, y arrive dans la semaine ou les deux semaines qui suivent. Nous ne construisons pas quelque chose pendant des mois pour obtenir un feedback de la production. Et lorsque nous recevons un retour d'information, il ne s'agit pas d'un retour d'information du type « est-ce qu'ils l'utiliseraient ? » (parce que nous l'avons déjà validé bien plus tôt avec des prototypes), mais nous recevons déjà un retour d'information du type « est-ce que ça s'installe bien dans l'environnement du client ? ». Percevez-vous la différence ? Une vitesse d'innovation beaucoup plus élevée, qui permet de valider 90 % des idées qui ne fonctionnent pas. C'est à l'exemple de ce qu'Intercom a fait ici : https://www.intercom.com/blog/why-continuous-deployment-just-keeps-on-giving/ (10 minutes de bout en bout et 80 déploiements par jour, c'est trooop lent).
Ma compréhension actuelle d'un modèle Agile à deux voies est que le "trio produit" (Product Manager, Product Designer et Tech Lead) aborde les risques liés au produit en réalisant des prototypes, en menant des entretiens avec les utilisateurs, en parlant aux parties prenantes et en leur montrant les prototypes, en expliquant les détails à l'équipe d'ingénierie, etc. Lorsque tout est clair et que nous venons de faire une livraison finale (NdT : OKR atteint), le trio commence déjà à travailler sur l'OKR suivant, en faisant de la découverte de problèmes.
La partie Maintenance du produit en cours d'exécution (le Run) n'apparaît pas dans ce modèle. Il s'agit d'une partie de la boucle de feedback qui va de la voie de Delivery à la voie de Discovery, puis à la livraison de la version suivante du produit. En d'autres termes, une version d'un produit en cours de production présente un problème qui, par le biais de la boucle de feedback, est transmis à la voie de Discovery du produit, où il est étudié, un prototype de solution est créé et testé dans un bac à sable, puis l'équipe met en œuvre un correctif et l'expédie sur la voie de Delivery du produit.
La voie du Discovery produit consiste à construire le bon produit. Et "bon produit" signifie que nous avons la preuve que : 1. Ils l'achèteront / choisiront de l'utiliser (risque de Valeur, responsabilité du PM) 2. Ils comprendront comment l'utiliser (risque lié à l'Utilisabilité / la Facilité d'utilisation, responsabilité du Product Designer), 3. Nous disposons de suffisamment de membres de l'équipe, de connaissances et de technologies pour construire ce produit ? (risque de Faisabilité, responsabilité du Teach Lead) 4. Nous pouvons le vendre et le marketer efficacement sans enfreindre aucune loi ou réglementation ? (risque de Viabilité, responsabilité du Product Manager), et 5. Nous devons le construire, est-ce éthique de le faire ? (risque Éthique, responsabilité du trio produit). Le PM doit être responsable de la Valeur et de la Viabilité, car personne d'autre ne connaît aussi bien les clients et l'entreprise : le Tech Lead est responsable de la mise en œuvre technique en premier lieu, le Product Designer de l'UI/UX en premier lieu. Et oui, le Product Designer, le Tech Lead et l'ensemble de l'équipe de développement doivent comprendre, connaître et entendre de la bouche d'un Product Manager les problèmes et les limites de l'entreprise et des clients, et pourquoi nous construisons le produit de cette manière, mais ils ne sont pas responsables de cela.
L'adéquation entre le problème et la solution (Problem/Solution fit) est validée au cours de la phase de Discovery du produit : nous construisons des prototypes et les montrons aux clients et aux parties prenantes pour nous assurer que nous abordons le problème d'une manière qui plaira aux clients, mais qui fonctionnera aussi pour l'entreprise. Et nous le faisons avant la livraison du produit, ce qui nous permet de livrer un MVP.
La Recherche est effectuée au cours du Discovery du produit. Par exemple, si une équipe se voit attribuer un OKR "augmenter le taux de conversion des inscriptions de 3% à 5%", elle effectue une recherche sur ce qui se passe, en commençant par la manière dont le "taux de conversion des inscriptions" est calculé actuellement, ce qu'il signifie et si elle peut faire confiance aux données. Ensuite, ils utilisent les données pour formuler une hypothèse sur les problèmes que les clients peuvent rencontrer lors de l'inscription et qui entraînent une baisse du taux d'inscription : quelque chose n'est pas clair, quelque chose ne fonctionne pas (un bug) sur le site web, etc. Ensuite, ils construisent des prototypes et testent ces hypothèses avec un petit nombre d'utilisateurs réels afin de vérifier si cela résout le problème, d'obtenir de nouveaux feedbacks et d'itérer jusqu'à ce qu'ils atteignent l'OKR ou jusqu'à ce que le délai soit écoulé (en général, plusieurs mois). Par exemple, dans un modèle Agile à deux voies, nous avons une recherche constante pendant la voie de Discovery du produit qui vise à trouver une solution que les clients aiment tout en fonctionnant pour l'entreprise. La Stratégie Produit est un ensemble d'actions dont nous pensons qu'elles nous mèneront à une Vision Produit de la manière la plus optimale possible. Nous avons donc une Vision Produit - l'image d'un produit dans 3 à 5 ans. Mais comment y parvenir ? La Stratégie Produit doit répondre à cette question, en expliquant ce que nous sommes sur le point de faire et pourquoi. Quant aux OKR, il s'agit d'une technique utilisée par les Product Leaders pour guider les Équipes Produit, pour que chaque Équipe Produit sache sur quoi elle travaille ce mois-ci ou ce trimestre. En effet, chaque équipe a ses propres OKR sur lesquels elle travaille. Par exemple, une Équipe Produit peut avoir un OKR "réduire le taux de désabonnement d'un produit de 10 % à 5 %". L'objectif est de réduire le taux de désabonnement, le résultat clé est x2, de 10 % à 5 %. Ainsi, l'équipe connaît désormais le problème de l'entreprise ou de l'utilisateur, ainsi que la mesure sur laquelle elle travaille.
Feedback de Huy Nguyen :
D'autres acteurs doivent être beaucoup plus impliqués dans la phase de Discovery, pas seulement le trio (Product Manager, Product Design, Tech Lead). Par exemple : * La Sécurité ne peut pas être une réflexion après coup. Elle doit être conçue dès le départ dans certains cas. * Il ne s'agit pas seulement du Tech Lead. Cela peut signifier que la roadmap technologique est impactée, auquel cas les Architectes d'Entreprise doivent être impliqués. * Le Product Design ne se limite pas au risque d'utilisabilité. Les concepteurs de services peuvent être amenés à se pencher sur l'ensemble de l'expérience. CX = utilisabilité. Il faut également s'occuper de la Stratégie de contenu. * Les risques d'Éthique ne concernent pas seulement le trio. Le Juridique et la Conformité peuvent également être impliqués pour fournir des informations et des orientations sur la manière dont les choses doivent être articulées. * Et puis, il y a les Sales et le Marketing, et ces gars-là ne sont pas forcément faciles à gérer.
