L'alternative aux feuilles de route

J'ai toujours trouvé cette citation du Général George Patton formidable :

« Ne dites pas aux gens comment faire quelque chose. Dites-leur ce qu'il faut faire, et ils vous surprendront par leur ingéniosité ».

Malheureusement, les roadmaps font exactement ce contre quoi le général met en garde

Les roadmaps indiquent aux équipes ce qu'elles doivent faire et comment. En général, cela se présente sous forme de listes priorisées de fonctionnalités ou de projets dont quelqu'un croit vraiment qu'ils résoudront le problème (même si le problème n'est souvent pas encore clair ou n'a pas vraiment été compris).

Si ta roadmap contient par exemple quelque chose comme « Ajouter PayPal comme option de paiement supplémentaire », est-ce parce que tu penses qu'il y a des clients qui ne peuvent pas payer avec tes autres méthodes de paiement ? Ou est-ce lié aux paiements internationaux ? Ou peut-être que quelqu'un pense que ce serait un désavantage concurrentiel de ne pas proposer cette option ?

J'ai déjà souligné dans plusieurs articles que je considère les roadmaps produit classiques comme une source majeure de gaspillage (waste) pour les équipes produit. L'article Produits qui ont échoué traite de ce sujet et dans Vérités inconfortables du développement produit, j'approfondis ce concept.

Comme le problème des roadmaps attire de plus en plus l'attention, on m'a souvent demandé dernièrement de parler davantage de l'alternative aux roadmaps.

Un sujet complet

Dans cet article, je vais tenter de le faire. C'est un vaste sujet, qui touche également à des thèmes comme la culture produit, l'autonomisation et l'autonomie. En général, il me faut au moins une heure pour expliquer tout cela à quelqu'un en personne, mais j'espère pouvoir résumer l'essentiel ici.

Avant de nous lancer sur l'alternative aux roadmaps, nous devons prendre conscience que les roadmaps ont été utilisées si longtemps parce qu'elles répondent à deux besoins bien précis – et ces besoins ne vont pas disparaître comme ça.

1) La direction veut s'assurer que les équipes travaillent d'abord sur les éléments qui ont le plus de valeur pour l'entreprise.

2) Comme ils ont une entreprise à gérer, il y a des situations où ils ont besoin de délais et d'engagements concrets – et les roadmaps leur permettent de capturer et de suivre ces engagements.

Pour qu'une alternative aux roadmaps classiques soit acceptée en entreprise, ces deux points doivent être adressés au moins aussi bien qu'auparavant.

Les roadmaps trouvent leurs racines dans l'ancien modèle centralisé de Command-and-Control. Quelques parties prenantes organisent une réunion – généralement trimestrielle – pour réfléchir aux priorités et aux projets des équipes pour le trimestre suivant.

En revanche, dans le modèle d'équipe produit, les équipes doivent pouvoir découvrir par elles-mêmes comment elles vont résoudre les problèmes business dont elles doivent s'occuper.

Mais pour cela, il ne suffit pas simplement d'avoir de bons collaborateurs. L'équipe a besoin du contexte nécessaire. Les membres de l'équipe doivent avoir intériorisé où exactement l'entreprise veut aller, et ils doivent avoir compris ce que leur propre équipe doit apporter à cet objectif global.

Pour revenir au général Patton :

Comme vous le savez peut-être déjà, l'armée travaille également avec le concept d'équipes autonomes. Ces équipes (Squads) sont délibérément maintenues petites et sont en grande partie autonomes. Elles gardent toujours en vue les intentions communes, mais peuvent décider elles-mêmes de ce qu'elles considèrent comme la meilleure façon de résoudre un problème donné.

Ces intentions communes sont le contexte que je viens de mentionner. « Les intentions formulent précisément les objectifs et les buts supérieurs… Des intentions claires conduisent à des activités ciblées au sein des forces armées. Elles expriment ce que le commandant souhaite accomplir et pourquoi, et elles créent un sentiment d'appartenance au sein des forces armées. Normalement, elles s'expriment par les impacts possibles, les objectifs et les résultats souhaités… Des intentions vraiment bien formulées sont compréhensibles pour les subordonnés sans nécessiter une grande quantité de détails supplémentaires. »

Les entreprises technologiques ont diverses possibilités pour fournir ce contexte ou ces intentions. Je plaide cependant pour deux composantes bien précises :

La vision produit : elle décrit la vision globale de ce que l'organisation dans son ensemble cherche à accomplir.

Les objectifs d'entreprise : ils décrivent les objectifs d'entreprise spécifiques et priorisés pour chaque équipe produit.

Il existe plusieurs systèmes et méthodologies pour gérer ces objectifs d'entreprise. Mon favori actuellement est le système OKR (Objectives and Key Results).

L'idée en soi est assez simple : dites aux membres de l'équipe ce qu'ils doivent accomplir et comment les résultats seront mesurés. Ensuite, laissez l'équipe décider elle-même de ce qu'elle considère comme la meilleure façon de résoudre les problèmes concernés.

Supposons par exemple que votre produit nécessite actuellement 30 jours pour le processus d'onboarding des nouveaux clients. Cependant, pour pouvoir évoluer efficacement, cela doit être réduit à 3 heures ou moins. Ce serait donc un bon exemple d'objectif pour une ou plusieurs équipes produit : « Réduire fortement le temps nécessaire pour qu'un client soit opérationnel. » L'un des résultats clés pourrait être : « Temps d'onboarding moyen inférieur à 3 heures. »

Même si le concept d'objectifs d'équipe semble assez simple, il existe de nombreuses façons de l'institutionnaliser dans les équipes produit et les organisations, et plusieurs trimestres peuvent être nécessaires avant que l'organisation profite des avantages de ce concept.

Il y a plusieurs enseignements sur la vision produit et particulièrement sur la bonne utilisation du système OKR que je mettrai en avant dans les prochains articles. En attendant, vous pouvez déjà consulter le matériel de Christina Wodtke.

Ce contexte est donc très important – c'est-à-dire la vision produit et les objectifs d'équipe.

Au début, j'ai souligné que nous devons prendre en compte les deux raisons principales des bonnes vieilles roadmaps. La première était le souhait de travailler d'abord sur les éléments ayant la plus grande valeur pour l'entreprise. Il est espérons-le clair que le management répond à ce besoin en fournissant les objectifs spécifiques pour l'organisation et leur priorisation. La différence cependant est qu'ils priorisent maintenant l'importance des résultats business plutôt que la valeur subjective des fonctionnalités.

La deuxième raison était le besoin d'engagements, que nous abordons avec le concept d'engagements à haute intégrité. Cela concerne les situations où nous avons réellement besoin d'un engagement sur une date ou un résultat spécifique.

Cette approche présente plusieurs avantages :

Premièrement, les équipes sont beaucoup plus motivées lorsqu'elles peuvent elles-mêmes réfléchir à ce qu'elles considèrent comme la meilleure solution au problème.

Deuxièmement, l'équipe ne peut pas simplement se contenter de livrer une fonctionnalité ou un projet demandé ; la fonctionnalité doit aussi réellement fonctionner (ce qui est mesuré par les Key Results). Si ce n'est pas le cas, l'équipe doit essayer une autre approche pour résoudre le problème.

Troisièmement – quelle que soit l'origine de l'idée de solution – très souvent la première approche ne fonctionne pas et au lieu de le nier, ce modèle en est pleinement conscient.

Tout tourne davantage autour de l'Outcome plutôt que l'Output – c'est-à-dire obtenir un résultat significatif, plutôt que simplement atteindre n'importe quel objectif.

Souvent, je demande aux équipes de regarder en arrière sur l'année écoulée et de s'auto-évaluer sur le taux de réussite de leur roadmap, notamment en ce qui concerne le nombre d'éléments qui correspondaient réellement aux objectifs de l'entreprise. Si tu fais cela et que tu n'es pas fier de ce que tu découvres, alors j'espère que tu envisageras cette alternative. Assure-toi que ton organisation produit dispose d'une vision produit convaincante. Assure-toi que chaque équipe produit a des objectifs d'entreprise clairement définis et priorisés. Assure-toi que tous les engagements qui doivent être pris sont des engagements à haute intégrité.
Et maintenant, donne à tes équipes produit le pouvoir de décider elles-mêmes quelles solutions elles trouvent les plus adaptées à certains problèmes métier, et observe combien de tes équipes te surprendront par leurs résultats.

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

Séminaire Product Owner

=> Participe dès maintenant à un Séminaire Product Owner de l'Agile Academy.

Le Product Backlog

=> Lis-en plus sur le Product Backlog dans le lexique agile.

Le rôle du Product Owner

=> Apprends-en plus sur le rôle du Product Owner.