Avatar

Denis St-Michel

Agiliste / PSPO II · PSM II · PAL · CSSCWB / Je rends les équipes hautement performantes et j’accrois la valeur des produits.

Sur le web, une recherche rapide me dévoile un bon nombre d’articles ou de vidéos qui parlent d’output, d’outcomes, de vélocité et d’autres métriques comme le lead time, le throughput ou le cycle time. Au fil de mes lectures, je vois une dichotomie certaine entre le désir de mesurer notre capacité à produire des fonctionnalités utiles et notre volonté de créer de la valeur qui favorisera un changement positif dans la vie des utilisateurs de notre produit. Comment réconcilier les deux? Je vous propose dans cet article quelques pistes pour y arriver.

Comment savoir que nos équipes fonctionnent en mode push

Notre point de départ, c’est le backlog de produit. Il est généralement si bien garni qu’on peine à tout livrer. On a un certain sentiment d’impuissance face à la vitesse à laquelle il se remplit. On ne comprend pas trop ce qui nous échappe : l’équipe travaille fort, vite et bien. À chaque sprint, nous parvenons à créer des fonctionnalités complexes demandées par le client. On maintient un rythme de déploiement relativement soutenu, nos processus automatisés sont assez bien rodés. Malgré cela, on ressent chez les membres de l’équipe une certaine fatigue liée au projet. Des membres de longue date trouvent que le produit se dénature. On repousse toujours à plus tard ce fameux atelier de dette technique qu’on aimerait faire. Un nouveau membre qui se joint à l’équipe sonde ses collègues sur les décisions passées, tant fonctionnelles qu’architecturales. Il est un peu confus, car il reçoit des explications différentes, voire contradictoires, des personnes interrogées.

On est en mode push, et on est en train d’épuiser l’équipe.
La belle idée innovatrice qui fut à l’origine du produit semble effacée de la mémoire collective.

Le mode push, c’est cette façon de travailler où l’on tâche de créer constamment des fonctionnalités et des livrables. C’est cette façon de travailler qui exige toujours plus de lignes de code. De corriger toujours plus de bogues. D’améliorer l’expérience utilisateur par une nouvelle technique très tendance. Tout ça commence très naturellement, sans qu’on y prête vraiment attention. Il est pernicieux, ce mode push.


Mode push : notre équipe a une capacité de production X. On a un backlog assez gros pour occuper l’équipe à temps plein pour la prochaine année. S’ensuit un sentiment d’urgence. Un petit calcul mathématique nous dit que nous devons maximiser l’utilisation de toutes nos ressources si on veut y arriver.


Le mode push, c’est cette façon de travailler où toute l’équipe se préoccupe de réduire la taille du backlog, en complétant le plus de tâches possibles. C’est un mode dans lequel les outputs sont maîtres et rois.

Comment se définit le mode pull

Si le mode push est entièrement orienté vers les outputs, le mode pull se distingue par son approche épurée, demandant « juste ce qui est nécessaire ». Au lieu d’avoir un carnet de produit rempli à ras bord, celui-ci ne contient que des récits utilisateurs dont chaque membre de l’équipe connaît la provenance. On peut expliquer facilement la présence d’une tâche, parce qu’on connaît le contexte et les circonstances qui ont mené à son ajout au backlog. Le mode pull consiste à ne pas surcharger un sprint d’un maximum de tâches et de récits utilisateurs pour ne pas exploiter la capacité de production de l’équipe. Le mode pull consiste à réaliser un petit lot de fonctionnalités triées sur le volet, sans plus, parce que la création de ces fonctionnalités est opportune à ce moment précis.


Dans le mode pull, l’équipe extirpe littéralement du carnet de produit les items qui nécessitent d’être réalisés. Dans le mode push, les items à réaliser sont « poussés » ou imposés à l’équipe, avec peu d’ouverture pour le compromis.


La beauté du mode pull est que ce qui est développé dans le produit a un impact réel, immédiat. On crée une fonctionnalité parce qu’elle est cohérente avec le jalon de la feuille de route dont on poursuite l’atteinte. Et ce jalon est essentiel pour parvenir à combler un objectif d’affaires, qui lui-même s’inscrit dans une thématique stratégique. Cette stratégie appuie une intention qui nous aide à atteindre la vision de produit.

En étant bien consciente de la vision de produit, l’équipe peut construire avec le client une feuille de route savamment réfléchie. Cette feuille de route ne contient pas des items à créer ou des epics à compléter. Un epic ou un récit utilisateur ne sert à rien s’il n’est pas contextualisé ou pertinent. Au mieux il ne nuit pas, au pire il ajoute une dette au produit.

Une feuille de route bien construite explicite la stratégie de développement (du produit et du marché visé). Elle rend visibles les objectifs d’affaires de même que les jalons intermédiaires pour les atteindre. Une fois ces conditions réunies, quelque chose de magique se produit dans l’équipe : au lieu de réaliser des fonctionnalités à n’en plus finir, on crée une expérience utilisateur inégalée. Étant donné que chaque membre de l’équipe Scrum (équipe de réalisation, client, Product Owner, Scrum Master) est conscient des objectifs à atteindre et détient une compréhension commune du cheminement qui a mené à leur élaboration, les décisions deviennent simples et moins nombreuses à prendre. C’est tout le travail qui est simplifié!

D’autres avantages du mode pull

  • Des équipes de produits énergisées et engagées dans le processus de valorisation de produit
  • Des décisions toujours plus simples à prendre
  • Une réduction massive du code à entretenir
  • Une faible dette technique
  • Du temps et de l’espace pour une réelle pratique d’amélioration en continu
  • Une démarche de réflexion avec le client visant à cibler ce qui importe le plus
  • Des livraisons de produits plus simples, plus fréquentes et comportant moins de risques

Mode pull : L’équipe connaît très bien les besoins du client. Ce sont des besoins de la vie courante, pas des besoins techniques ou des fonctionnalités spécifiquement détaillées. Les équipiers connaissent aussi très bien le fil narratif du produit. Il est facile pour chacun d’eux d’expliquer les raisons qui ont mené à une décision plutôt qu’à une autre. Le backlog est petit et se gère très facilement.


Comment passer du mode push au mode pull

S’il est facile d’entrer malgré soi dans le mode push, ça demande un engagement fort pour s’en sortir et passer au mode pull. Heureusement, même si ça demande passablement de travail, la marche à suivre est simple, et je dévoile ici les grandes étapes.

Rédiger un énoncé de vision de produit

Tout part de la vision de produit. Les bénéfices d’un énoncé de vision engageant sont immenses et se font sentir tout au long du cycle de vie du produit. Un énoncé clair est connu de toute l’équipe, élaboré conjointement avec le client et utilisé lors des événements scrum comme le sprint planning et la rétro d’équipe. La vision de produit est le phare au loin qui guide tout le reste. C’est ce qui va nous permettre de rester alignés et de protéger la nature du produit. Chaque membre de l’équipe doit connaître par cœur cet énoncé et pouvoir expliquer à quiconque ce qu’il signifie. Un énoncé de vision de produit ne se fait pas sur le coin d’une table. Cela requiert des ateliers de travail et de la réflexion.

Créer une feuille de route stratégique

Si l’énoncé de vision nous rappelle où l’on tente d’aller, la feuille de route est notre carnet de voyage. Dans le cadre Scrum, le Product Owner est responsable d’établir et de maintenir la feuille de route. Mais on a tout à gagner à faire des sessions de travail avec toute l’équipe. Les développeurs, analystes et concepteurs ne sont pas des ouvriers. Ils sont des artisans. Connaître la destination, comprendre les chemins à parcourir, les intentions, la stratégie de développement et les objectifs d’affaires leur permettront de prendre les meilleures décisions, de mettre leur cœur et leurs trippes dans leur travail, de défendre le produit, d’en parler, de le faire vivre, de s’en sentir responsables et de le dorloter. Surtout, une feuille de route bien construite permettra à cette équipe de prendre en charge le développement du produit de manière cohérente, volontaire et réfléchie.

La feuille de route ne devrait pas contenir :

  • De récits utilisateurs
  • Le nom des fonctionnalités
  • Des livrables détaillés

La feuille de route devrait plutôt mettre de l’avant :

  • Des intentions
  • Des thématiques (fonctionnelles, financières, commerciales, opérationnelles, juridiques, etc.)
  • Des objectifs d’affaires
  • Des jalons

Réduire (drastiquement) la taille du carnet de produit

Le backlog de produit ne devrait pas être une to-do list. Il devrait être une vue magnifiée d’une petite portion de la feuille de route. Lorsqu’on est en mode push, on a peur « d’oublier » qu’un jour, il faudra faire telle ou telle fonctionnalité. Et le carnet de produit s’embourbe et devient rapidement un beau gâchis. Pour passer au mode pull, il faut repartir de la vision du produit et de la feuille de route pour créer juste le nécessaire, de manière à  atteindre les deux premiers jalons des objectifs priorisés. Attention à ne pas retomber dans un mode push, ce faisant. Soyons attentifs aux objectifs ciblés dans le roadmap. On a une super idée qu’on ne veut pas oublier? On se retient et on ne la crée pas dans le backlog. On se questionne plutôt à savoir si cette idée est cohérente avec la feuille de route. Si c’est le cas, et que cette idée est nécessaire pour atteindre les jalons sur lesquels on travaille, alors on en discute en équipe et si tout est encore valable, on l’ajoute au backlog. C’est parfait ainsi! On vient d’ajouter un item de valeur à notre carnet de produit. Et cet item a de la valeur parce qu’il nous aidera à répondre aux objectifs d’affaires prioritaires.

Si, en revanche, cette idée qui semblait bonne au départ n’a pas de lien avec la feuille de route, alors de deux choses l’une : soit quelque chose de majeur nous a échappé lors de la conception du roadmap, soit cette idée n’apporte rien au produit compte tenu de la vision que l’on a de celui-ci.

 

En conclusion

Le mode push est éreintant et apporte moins de valeur à tous les acteurs gravitant autour du produit. L’équipe s’épuise. Les gestionnaires galèrent. Le client n’obtient pas le meilleur retour sur investissement possible. Dans cet article, j’ai mis en lumière les inconvénients du mode push et les avantages du mode pull. En mettant en place des pratiques simples de valorisation du produit, il est possible de tirer une bien plus grande valeur pour tous les acteurs, et de rendre nos équipes de produit hautement performantes. Ces pratiques de valorisation de produit s’appuient sur un énoncé de vision très engageant (c’est le Product Goal du nouveau guide Scrum), une feuille de route brillamment construite et un carnet de produit savamment restreint.

Assurément, l’accompagnement proposé par un coach, un Scrum Master ou un Product Owner expérimenté facilite grandement la transition. Procéder à ce changement requiert du travail et un certain temps. Rappelons-nous aussi que, comme pour chaque changement opérationnel, les premiers moments sont caractérisés par une perte apparente de productivité. Cette perte de productivité est l’effet d’une mesure basée uniquement sur les outputs. Mais lorsque l’on commence à s’intéresser aux outcomes, alors la vraie valeur générée par l’équipe et par le produit représente mieux la performance réelle de l’équipe.

Bonne transition!

 

 

 

 

Partage cette page

Qu'en pensez-vous?