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.
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 :
Dans ce cas vous n’obtiendrez pas le feedback que vous attendez.
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.
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.
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 ?
Voyons ce que nous apporte l’augmentation de la fréquence de livraison :
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 :
Cela passe forcément par quelques bonnes attitudes à adopter :