Sans excellence technique, impossible de créer un super produit

Note de l'auteur

Voilà déjà le deuxième épisode de cette série la gestion de produit en pratique. L’excellence technique est fondamentale pour la construction d’un produit. Beaucoup d’entre vous en sont déjà convaincu mais, comme d’autres choses, c’est plus facile à dire qu’à faire… Jean-Pierre Lambert vous accompagne dans la découverte du formidable potentiel de l’excellence technique et vous donne les clés de son application pratique dans une approche holistique. Quels sont les conséquences et les intérêts ? Comment obtenir l’adhésion de l’équipe ? Quelle attitude adopter pour la mettre en pratique ? Comment mesurer ses performances ? Rien ne sera mis de côté par Jean-Pierre Lambert qui à l’habitude de traiter ses sujets en profondeur. Alors découvrez sans attendre ses nouveaux conseils et outils que vous pourrez mettre en pratique dans votre quotidien.

Introduction

L’équipe Panda avance à plein régime sur son backlog produit ! Les fonctionnalités s’enchaînent, malheureusement elles sont presque terminées, et on retarde de quelques itérations leur finalisation… Résultat : quand on apprend que l’utilisateur n’a aucun intérêt pour une des fonctionnalités, il faut pratiquement refaire tout ce qui a été fait entre temps. Ça pique…

La clé du succès pour réussir votre produit est votre capacité à itérer vite. Pour cela il faut impérativement être excellent techniquement sans quoi vous ne pourrez pas augmenter la fréquence à laquelle vous mettez le produit à disposition de vos utilisateurs et ainsi récolter rapidement leurs retours.

C’est logique ! Si le produit livré n’est pas complètement propre et utilisable vous le payerez d’une manière ou d’une autre :

• Soit, vous n’oserez pas mettre le produit entre les mains de l’utilisateur par crainte qu’il ne réponde pas encore au besoin ;
• Soit, vous diffuserez le produit mais les utilisateurs seront pollués par les problèmes techniques et ne pourront pas aller au bout du processus.

Dans ce cas vous n’obtiendrez pas le feedback que vous attendez.

Qu’est-ce que le « Done » [vraiment terminé] ? quel lien avec l'excellence technique ?

Le « Done » désigne l’état d’un travail réellement terminé, qui a atteint le niveau d’exigence requis. Cette notion est fondamentale pour le fonctionnement de l’équipe qui se doit de respecter le « Definition of Done » (DoD) : une liste des éléments à vérifier pour s’assurer que nous avons bien complètement terminé. Même si nous pensons qu’il faut absolument respecter le DoD et être intransigeant sur l’excellence technique, cela ne signifie pas que nous n’avons pas le droit de livrer un produit qui n’est pas optimal. Par exemple décider qu’une application ne fonctionnera pas sur les vieux smartphones ou tablettes et qu’elle nécessite un appareil récent n’est pas un problème. Mais ça le devient si nous ne sommes pas alignés, aussi bien au sein qu’en dehors de l’équipe, sur le détail des éléments contenus dans cette notion de « terminé ».

Une fois que l’équipe est au clair sur le Definition of Done, elle a la responsabilité de s’assurer qu’elle est toujours au niveau. Nous pouvons, ensuite, développer une stratégie produit sur cette base comme le discours externe que nous allons porter.

Une fonctionnalité ne remplissant pas tous les critères du Definition of Done doit être considérée comme non terminée et ne doit pas être abordée en revue de sprint (sprint review). Il est très important d’être strict sur ce point : c’est l’engagement numéro un de l’équipe de livrer des éléments complètement terminés. A défaut, vous risquez de compromettre la fiabilité du produit et la qualité de l’expérience utilisateur.

Ne pas aller plus vite que la musique : ralentir pour accélérer

Vous ne pouvez pas aller plus vite que la musique ! Il s’agit en fait de ralentir pour pouvoir accélérer. Rappelez vous que la vitesse de progression de l’équipe ne se décide pas, elle se mesure. Nous ne pouvons pas décréter, avec un rétro planning par exemple, ce que l’équipe va accomplir dans un temps donné. L’équipe avance à sa vitesse et il ne sert à rien d’aller vite si nous ne prenons pas la bonne direction. Comme l’a dit Peter Drucker :

« Il n’y a rien de plus inutile que de faire avec efficacité quelque chose qui ne doit pas du tout être fait. »
Peter Drucker

Tous les efforts de construction d’un produit n’ont aucune valeur tant que le produit n’a pas été mis entre les mains de l’utilisateur. En conséquence, il est préférable de livrer peu mais tout de suite que de vouloir livrer beaucoup dans longtemps.

L'excellence technique diminue la vélocité, est-ce acceptable ?

C’est vrai que d’abandonner une stratégie du « beaucoup dans longtemps » au profit du « peu mais tout de suite » fait inévitablement baisser la vélocité. Même si cela peut paraitre inquiétant en contrepartie, nous augmentons la fréquence de livraison. Quand nous parlons de livraison il s’agit ici de mettre un produit, ou une nouvelle version de celui-ci, entre les mains de l’utilisateur.

Quelles sont les conséquences pratique d’une vélocité qui baisse au profit d’une fréquence de livraison qui augmente ?

• Pour le plan de livraison : aucune si ce n’est qu’il faudra le mettre à jour. Vous pensez que c’est grave car vous ne tiendrez pas les délais annoncés ? C’est en fait le meilleur moyen de respecter les échéances : vous commencez à connaitre maintenant la véritable vitesse de l’équipe et si le plan de livraison doit être mis à jour c’est qu’il était trop ambitieux et quoi qu’il arrive non tenable.
• Pour l’équipe : elle produira moins. Par exemple pour un produit logiciel elle produira moins de code mais surtout moins de bugs qu’il aurait fallu corriger tôt ou tard. Un sentiment d’excellence va s’installer et l’équipe va pouvoir s’épanouir dans son rôle en allant au bout des choses.

L'excellence technique augmente la fréquence de livraison, Quels sont les intérêts ?

Voyons ce que nous apporte l’augmentation de la fréquence de livraison :  

• Augmentation de la fréquence du feedback : c’est le premier des avantages car il est le générateur des autre effets positifs…
• Apprentissage plus rapide : en apprenant plus vite, nous pourrons plus facilement corriger le tir. Finalement ce n’est plus si grave de prendre une mauvaise décision puisqu’elle pourra être rapidement modifiée.
• Amélioration de la valeur du produit : il répondra mieux aux besoins des utilisateurs et deviendra plus vite rentable.
• Capacité de saisir les opportunités : en livrant plus vite nous serons en mesure de saisir des opportunités et d’augmenter valeur du produit sans attendre.
• Réactivité pour ajuster les process : les problèmes de fonctionnement de l’équipe seront plus vite identifiés. Elle pourra ainsi rôder ses process et les ajuster autant que nécessaire.
• Installation d’une routine de livraison : la notion d’évènement qui entoure souvent la livraison est déconstruite par cette routine. L’équipe est moins soumise à une période de stress ou de rush.
  

Quoi mesurer ? Quels sont les indicateurs de performance ?

Rappelez-vous que la vélocité n’est pas un indicateur de performance. Elle ne sert qu’à mesurer la vitesse à laquelle nous avançons pour pouvoir faire des planifications. En revanche, nous pouvons mesurer la fréquence à laquelle nous livrons ou bien le temps moyen nécessaire pour livrer. C’est un élément très important dans la manière dont vous allez piloter une équipe, surveiller qu’elle fonctionne bien et vérifier qu’elle va dans la bonne direction. C’est pour cette raison que nous avons consacré un chapitre complet sur ce sujet dans notre formation devenez meilleur Scrum Master, coach agile, agiliste. Nous insistons notamment sur la différence entre la vélocité et le temps de cycle. Pour approfondir découvrez notre formation :

Comment appliquer concrètement dans votre équipe l’excellence technique et le respect du Definition of Done

Cela passe forcément par quelques bonnes attitudes à adopter :

• Coté experts : être exigeant et intransigeant sur la qualité. Ils doivent assumer pleinement cette posture et si nécessaire apprendre à refuser toute demande qui ne s’intégrerait pas dans cette exigence de qualité.
• Côté product owner: mettre tout en œuvre pour permettre aux experts d’atteindre la qualité exigée et ainsi améliorer la fréquence des itérations et des feedbacks utilisateurs. Nous le développons dans notre formation Accélérer le développement produit en partenariat avec Artisan Développeur. Il doit intégrer le fait qu’un travail mal fait ralenti considérablement l’équipe.
• Côté Scrum Master : être la bonne conscience du groupe. Rappeler la rigueur et les process que l’équipe s’impose elle-même. Son rôle n’est pas de contrôler les agissements mais bien de mobiliser sur les objectifs de qualité qui doivent impérativement être respectés. La réunion de planification de sprint (Sprint Planning) est une bonne occasion pour présenter le respect du Definition of Done comme un élément incontournable à prendre en compte pour déterminer les objectifs du sprint.