La peur de livrer

Livrer c’est une des plus grandes satisfactions dans le quotidien d’un product owner.

Pourtant, dans beaucoup d’équipe scrum, la livraison est une angoisse.
Plus qu’une angoisse, ça se transforme parfois en peur panique.

  • On est vendredi, il est trop tard pour livrer
  • Les testeurs viennent de détecter 3 bugs, on ne peut pas livrer
  • Il n’y a pas de valeur dans ce sprint, ça sert à rien de livrer

C’est quoi le blocage ?

On en parle dans ce post.

Les peurs de livrer 

Peur d’etre juger 

don't judge me

Effectivement, si vous craignez le jugement, vous avez de bonnes raisons d’avoir peur car vous serez certainement jugé par ce que vous livrez.

Si vous en êtes à ce stade, c’est soit que vous avez un blocage psychologique soit qu’il y a un problème de management dans votre boite (j’en parle en bas du post).

Pour être ou devenir PO, il ne faut surtout pas avoir peur d’être jugé.

Au contraire, il faut attendre le jugement avec impatience.

Une fonctionnalité ou une nouvelle mise à jour sur le marché, ça a comme objectif de satisfaire le client ou répondre à un besoin.

Vous avez absolument besoin de ce jugement pour avancer et évaluer le travail réalisé et l’améliorer.

Peur d’échouer

En réalité, derrière tout jugement, la vraie peur que l’on a, c’est celle d’échouer.

  • Décevoir le client
  • Viser à côté
  • Peur du plantage technique
  • Incompréhension de l’interface.

Encore une fois, c’est une certitude. Quand ça va planter fort, vous allez en prendre plein la g…

  • Avis négatifs sur l’appstore ou Google play Store
  • Appels ou emails de haters reçus sur l’adresse email du service clientèle
  • Déchaînement sur les réseaux sociaux
  • N+1 qui vous convoque d’urgence en salle de réunion pour vous demander des explications

Bref, la liste est longue.

Seulement voilà, dites vous bien un truc. Ça fait partie de votre job.

C’est ça être PO !
Vous devez assumer et prioriser les choix techniques, UX, marketing… récoltés par tout le monde en interne et quand ça plante c’est vous qui êtes en front line.

Rationalisez, vous avez la chance de pouvoir faire des choix qui influencent l’utilisation d’un produit parfois consommé par des millions de personnes.

C’est un super pouvoir !

Vous vous doutez bien qu’il y a forcément une contrepartie.

Cette contrepartie, c’est de prendre la responsabilité quand il y a un échec.

assumer

Même, si ce n’est pas de votre faute.

  • Le Marketing vous a imposé un truc à la con que les utilisateurs détestent
  • Le testeur n’a pas détecté un bug grave en recette

Vous devez avoir la peau dure et être le bouclier qui protège votre équipe.

Assumez l’échec !

L’échec fait partie de tout processus de création. Il est essentiel.

Il faut apprendre à vivre avec et l’affronter.

Peur de la première fois, de l’inconnu

première fois

Enfin, une des peurs les plus courantes c’est quand vous intervenez dans la phase délicate d’un lancement de produit.

Le lancement n’est pas une livraison comme les autres, c’est un événement.

Si vous avez bossé comme des malades pendant des semaines voire des mois, il est normal d’avoir une appréhension et ressentir la pression.

Seulement encore une fois, ce n’est qu’une étape. Même si ça plante (ce qui est quasi sûr la première fois), il faudra se relever et s’améliorer.

Plutôt que de faire des longues phrases, je préfère tout résumer avec la citation très célèbre de Reid Hoffman, le fondateur de LinkedIn.

Si vous n’avez pas honte de la première version de votre produit c’est que vous l’avez lancé trop tard.

Le mythe de la livraison 

Si certains ont peur de livrer, c’est parce que l’on sacralise trop cette étape.

Pour une raison quasi mystique, on interprète la livraison comme quelque chose d’extraordinaire. 

Livrer : Un objectif 

mission réussie

Dans la tête de beaucoup d’entre nous, livrer est vu comme un aboutissement.

A l’échelle micro, au sein d’une équipe scrum, il est vrai que ça conclut un cycle.

Pourtant, la vérité c’est que ce n’est qu’une étape, le réel aboutissement ce n’est pas la livraison mais la valeur perçue après usage.

Soyons réaliste. 

Une fois que vous avez livré, avez-vous atteint votre objectif ?

Non, au contraire, c’est parfois même tout le contraire

  • Bugs en prod
  • Réactions négatives des utilisateurs
  • etc…

Le vrai aboutissement c’est quand vous avez la preuve que l’utilisateur ou le client vous témoigne positivement de la valeur reçue.

Livrer : La célébration

accomplissement

Etant donné que la livraison n’est pas un objectif mais une étape, il n’y a aucune raison de pousser un ouf de soulagement ou de célébrer.

C’est un temps après la livraison, après quelques jours ou parfois après quelques semaines que vous pourrez évaluer les bienfaits et la valeur de la livraison.

En général la livraison est juste un acte indolore.


Rien ne change et rien ne se passe avant un certain temps.

Livrer : Un relâchement

soulagement

Quand un dev fini son ticket et qu’il le passe en revue, il ne célèbre pas.

Il attend et surveille si le reviewer approuve. Puis ensuite, il y a encore l’étape de la recette.

Il doit rester vigilant pendant ces 2 étapes pour être prêt à faire des corrections si nécessaire.

Son objectif est de s’assurer que son ticket passe en Done le plus rapidement possible.

A ce moment là, il peut se relâcher et avoir le sentiment de travail bien fait.

C’est exactement l’état d’esprit qu’il faut avoir avec la livraison.

Après la livraison, c’est pas le moment de se relâcher. C’est tout le contraire !

Une livraison au niveau marché ce n’est pas un Done, c’est une sorte d’autre test.

Il faut surveiller les premières 48 heures pour voir si les utilisateurs ne remontent pas des anomalies.

Si ça passe, il faudra attendre encore un peu plus de temps pour observer les résultats escomptés

  • Taux d’adoption de la nouvelle fonctionnalité
  • Taux de satisfaction
  • Achat
  • etc..

Ce sont ces sentiments ou ces attitudes qui font de la livraison quelque chose de sacré pour beaucoup d’équipes Scrum.

En conséquence, cette sacralité entraîne des angoisses et des stress inutiles.

Essayez de rationaliser la livraison et donner lui sa juste valeur. Une simple étape dans le cycle d’un produit.

Les causes et les remèdes

Les causes

racines du problème

Bien souvent, quand l’équipe appréhende une livraison, il y a un problème de management.

Au dessus de vous, il existe des attentes irrationnelles sur votre travail :

  • Il faut absolument livrer cette feature pour augmenter notre chiffre d’affaire
  • C’est la fonctionnalité que tout le monde attend pour présenter à des investisseurs ou faire le buzz
  • C’est la fonctionnalité qu’il nous manque pour décoller ou lancer 

En gros, votre organisation vous a mis une pression pas possible sur votre prochaine livraison.

C’est le genre d’organisation où les départements se tirent dessus et n’assument pas leurs responsabilités.

  • Si l’équipe commerciale ne peut pas vendre, c’est parce qu’elle n’a pas cette fonctionnalité
  • Si l’équipe Marketing ne peut pas lancer sa campagne de pub, c’est parce qu’elle attend cette livraison

Dans ce contexte, impossible de ne pas avoir peur.

Sans votre travail, on vous fait croire que toute la boite est bloquée.

Forcément, par effet boule de neige, cette pression est transmise à toute l’équipe qui se sent oppressée et frustrée.

Je ne vais pas épiloguer, mais à moins que vous travaillez sur la sortie du prochain iPhone et en sprint de 6 mois, l’avenir de votre organisation ne dépend pas de votre prochaine livraison.

Le cours de la bourse ne va pas s’effondrer si ça plante.

Si vous vivez ce genre de contexte, il y a un gros problème de culture managériale.

La livraison dans le scrum, c’est un principe d’itération. Vous ne livrez jamais (ou très très rarement) une navette spatiale en un seul morceau.

Les remèdes

solutions

A part si vous subissez une pathologie au niveau managérial, la peur de livrer ça se soigne très facilement.

Voici mes 3 remèdes.

  1. Organisez quelques sprints d’une durée d’une semaine et livrez des trucs nazes.
    Des trucs que personne ne remarque. Des corrections de bugs, des updates…
  2. Mettez en place un système de livraison continue (j’en parle dans un prochain post)
  3. Ne communiquez pas sur vos livraisons (en interne comme en externe).

Ces petits exercices vont vous permettre de débloquer la machine et désacraliser la livraison.

  • Exercez vous à livrer tout et n’importe quoi jusqu’à ce que cela devienne facile et naturel pour tout le monde dans votre équipe.  
  • Intensifier le travail et les ressources de test sur la prod plutôt que sur la branche de Dev.

Une histoire de mindset

déclic

A l’inverse d’autres tâches (spécifier, coder, tester…), la livraison est une étape d’un sprint qui crispe tout le monde car elle demande un effort collectif.

Quand une tâche est en cours dans votre sprint, ne laissez personne la perdre de vue.

Diffusez le mindset où chacun doit rappeler à l’autre que ce qui est commencé doit être livré.

Ne laissez pas chacun vaquer à ses occupations et se réveiller en panique 24 heures avant la fin du sprint :

“ P… , il y a encore 5 tickets en revue et 4 en recette, on va pas pouvoir livrer “

N’attendez pas non plus forcément la fin du sprint pour livrer quelque chose.

La livraison ne doit pas devenir un événement avec une date sur le calendrier.

Livrer, c’est une tâche classique de votre quotidien.  Rien de plus. 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *