Note de l'auteur
Le bon sens prime toujours, encore faut-il avoir le sens bon ! Jean-Pierre Lambert et Constantin Guay exposent avec clairvoyance et humilité certains fondamentaux trop souvent négligés dans notre quotidien. Je suis convaincu que leur analyse sur le fonctionnement d’une équipe produit vous apportera un nouveau regard sur leur pilotage. Jean-Pierre Lambert et Constantin Guay nous invitent à mieux gérer l’alliance nécessaire entre le focus business et les composantes profondément humaines d’une équipe produit multidisciplinaire.
L’équipe Panda 🐼 est littéralement bloquée par l’absence de son designer qui n’est vraisemblablement pas assez disponible pour répondre à ses besoins. Elle vient de découvrir un élément fondamental : dans une bonne organisation, les moyens doivent être alignés aux enjeux. Elle va donc s’arranger pour devenir réellement autonome en vue d’atteindre les objectifs de sa mission. Dans ce nouvel épisode de la série la gestion de produit en pratique, nous allons parler de la métaphore de la Start-Up pour structurer une équipe produit.
Je suis Constantin Guay, j’accompagne les équipes et les managers à trouver des meilleures façons de travailler. Parfois, cela passe par les aider à construire des équipes produit vraiment indépendantes. J’ai pu l’expérimenter à plusieurs reprises même dans des grands groupes très règlementés. Cela est possible ! Nous allons voir comment dans la suite de cet épisode.
Vous verrez qu’il devient essentiel de décentraliser les décisions et que la start-up d’entreprise est une bonne métaphore pour illustrer le concept d’équipe autonome. Nous rentrerons ensuite dans le concret en définissant la raison d’être de l’équipe et en la rendant réellement autonome malgré son évolution dans une écosystème complexe. Mais, avant tout cela, voyons ensemble pourquoi la fluidité du process est un des meilleurs indicateurs de l’autonomie d’une équipe.
La fluidité du process est un bon moyen de faire ressortir le problème que rencontre notre équipe Panda 🐼. Ce que nous appelons dans notre jargon, le Flow, désigne une organisation dans laquelle les sujets avancent vite et sans blocage. Pour mesurer la fluidité du process, nous allons utiliser la notion de temps de cycle. Il s’agit du délai entre l’émergence de l’idée et sa mise à disposition dans les mains de l’utilisateur. Dans notre cas l’équipe Panda est bloquée par son designer mais nous rencontrons souvent des lourdeurs à d’autres niveaux comme le test et la validation qui arrive en bout de chaine ou encore la gestion des opérations qui consiste à mettre le produit en production. Finalement le blocage peut toucher toutes les compétences et l’analyse du temps de cycle nous permet de le mettre en lumière. Lorsque vous utilisez un logiciel pour le suivi de vos tâches, il peut souvent vous permettre de calculer le Cumulative Flow Diagram (CFD) dont je vous propose un exemple extrait du logiciel iceScrum.
Le CFD permet de visualiser non seulement analyser le temps de cycle mais aussi le nombre d’éléments en cours de processus à un instant donné, et leurs évolutions. Si vous souhaitez en savoir plus sur l’utilisation du CFD consultez la bibliographie de cet article.
Maintenant que l’équipe Panda 🐼 a mis en place ses indicateurs, elle peut exprimer clairement et factuellement l’impact d’une carence de compétences clés dans son équipe. Cette situation limite sa capacité à produire de la valeur car elle ne peut que recevoir et implémenter le design mais perd son potentiel de réaction et d’adaptabilité. Armé de cette analyse, le Product Owner pourra ainsi convaincre le patron d’intégrer le designer au sein même de l’équipe en vue de raccourcir les délais de livraison et par la même occasion, de réduire les coûts.
Cependant, une équipe efficace, sans blocage, ne suffit pas. Pour être efficient dans la construction du produit il faut aussi pouvoir décentraliser les décisions.
Précisons d’abord cette notion de décentralisation : il s’agit ici de ne plus remonter les strates hiérarchiques pour prendre les décisions mais de laisser le plus possible les équipes prendre les décisions stratégiques sur le produit. Alors pourquoi décentraliser ?
Prendre plus de décision : en premier lieu pour permettre à l’équipe d’augmenter le nombre de décisions prises. Nous comprenons facilement l’impact que cela peut avoir lorsque nous évoluons au cœur d’un système qui prône l’empirisme : tester un maximum d’options pour ne retenir que les meilleures. En effet en moyenne, sur dix idées qui émergent, seulement trois améliorent le produit, trois vont le dégrader et quatre seront sans impact significatif.
Une organisation qui centralise la prise de décisions va inévitablement limiter le nombre de validations et donc le nombre d’options testées. Dans ces conditions, nous aurons bien moins de chance de construire un bon produit. Maintenant que vous avez compris le principe de raisonnement voyons trois bonnes raisons de décentraliser les décisions.
Vous comprenez également que pour tester un maximum d’idée il est indispensable de pouvoir itérer rapidement. Comme nous l’avons déjà expliqué dans l’épisode l’EXCELLENCE TECHNIQUE prérequis pour ITÉRER VITE et créer le BON PRODUIT, sans excellence technique il est impossible d’augmenter la fréquence d’itération et en conséquence, impossible de construire un excellent produit.
Prendre des décisions plus rapidement : cette décentralisation permet de prendre les décisions plus rapidement. La plupart des opportunités ont une valeur qui se dégrade rapidement dans le temps. Un processus de prise de décision trop lent ne permettra pas de les saisir. Prendre rapidement les décisions est un réel accélérateur de la performance d’un produit !
Prendre de meilleures décisions : oui les personnes de terrains prennent généralement de meilleures décisions mais à la condition que la hiérarchie, ou les experts, communiquent les éléments qui permettent à l’équipe de bien tout prendre en compte. Lui donner le pouvoir de décisions sans lui accorder les moyens et les connaissances ne mènerait qu’à l’échec.
Nous verrons plus loin comment organiser une prise de décisions efficace au sein de l’équipe. Bref il faut décentraliser les prises de décisions pour générer plus de valeur, saisir des opportunités et créer un meilleur produit.
Pourquoi comparer une équipe produit à une start-Up d’entreprise ? Comme la plupart des start-up, l’équipe produit se concentre sur un besoin précis et se spécialise en évoluant avec ses utilisateurs. La dernière version du Scrum Guide 2020 nous conforte dans cette approche métaphorique. En effet, il met de côté la notion d’équipe auto organisée (« self organised ») au profit d’une équipe autogérée (« self managed »). Il s’agit d’un message fort car la gestion demande bien plus d’implication à l’équipe que la simple organisation. La prise de décisions s’intègre parfaitement dans ce processus et comme nous l’avons vue dans l’épisode Product Owner : qu’est-ce-que c’est ? Comment être un bon ?, d’un côté le Product Owner prend des décisions stratégiques sur le produit, de l’autre les experts (developers) prennent les décisions techniques, et en synergie, ils gèrent l’ensemble de la mission.
Vous vous dites sûrement qu’il n’est pas envisageable de laisser l’équipe gérer le budget, et pourtant cela constitue un élément incontournable pour lui permettre de saisir des opportunités. Une bonne solution peut consister à définir avec elle un palier de budget en dessous duquel l’équipe a toute latitude pour décider. Finalement c’est souvent la question du retour sur investissement qui va déclencher la décision d’engager une dépense. Non seulement les équipes sont tout à fait capable de réaliser ce calcul mais en plus elles sont les mieux placées. Et oui, elles possèdent toutes les informations nécessaires à conditions que la hiérarchie ait bien transmis tous les éléments de contexte…
Nous proposons donc de donner encore plus d’autonomie à l’équipe. La gouvernance en est simplifiée et devient plus fluide. Nous pilotons avec un focus sur le business qu’il faudra insuffler à équipe. Les OKR peuvent vous aider dans votre mise en place d’un tel pilotage et nous en parlerons prochainement sur la chaine avec Anne Gabrillague.
Anne Gabrillague, agiliste depuis 2008 n’est pas seulement coache agile, organisatrice de conférence et oratrice, elle est aussi une des références francophones incontournable sur le sujet des OKR
Nous parlons bien de l’autonomie de l’équipe, à ne pas confondre avec l’autarcie. L’équipe s’intègre dans l’écosystème qu’est l’entreprise, avec ses contraintes et ses responsabilités.
Avant de voir comment être autonome dans un écosystème il est important de rappeler pourquoi l’équipe existe. Connaitre la raison d’être de l’équipe implique qu’elle sache pour qui elle construit le produit et comment vérifier ses hypothèses. Alors voici quelques éléments de réflexion qui déterminent la raison d’être d’une équipe :
Il est souvent difficile d’accepter de décentraliser les décisions. Nous pouvons craindre que l’équipe ait des difficultés à assumer pleinement cette responsabilité et pour cause, il n’est pas si simple de prendre des décisions en équipe. Pour les aidez-vous pouvez leur suggérer une multitude de système de prise de décisions inspirants comme le consentement, le systémique, le processus consultatif ou encore le jugement majoritaire. Ce dernier est celui que je préfère car il permet de décider rapidement en évitant de tomber dans le piège des jeux politiques. Pour approfondir le sujet consulter cette vidéo de David Louapre. C’est un outil à connaitre pour accompagner votre équipe.
En bref nous ne cherchons pas à gérer les dépendances, nous les supprimons !
