Sans excellence technique, impossible de créer un super produit
janvier 20, 2021 2021-05-05 16:45Sans excellence technique, impossible de créer un super produit
Sans excellence technique, impossible de créer un super produit
Scrum Life 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.
Table des matières
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.
Lien : https://youtu.be/JrZvP41cCmo
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. »
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.
Glossaire
Faites votre veille : Sources et liens complémentaires
- Contexte et présentation de la série « La gestion de produit en pratique » : https://scrumlife.tv/blog/gestion-de-produit-en-pratique/
- La formation Scrum Life en partenariat avec Artisan Développeur sur le rôle du Product Owner au sein d’une équipe technique : https://scrumlife.tv/pocraft
- En anglais, le livre “Clean Code” de Robert C. Martin “Uncle Bob” qui nous dit “The only way to go fast, is to go well” — focus sur une vidéo où il explique “le secret pour aller vite” : vidéo calée — vous pouvez aussi consulter l’ensemble de la série de 6 vidéos disponibles sur le sujet : leçon 1, leçon 2, leçon 3, leçon 4, leçon 5, leçon 6
- Le Scrum Life qui se focalise sur le Definition of Done : https://youtu.be/d6MVJojkuPE
- Article de Jean-Pierre Lambert sur le Definition of Done, les différentes formes qu’il peut prendre et la signification sur la maturité de l’équipe : https://jp-lambert.me/%C3%AAtre-agile-avoir-un-dod-qui-se-focalise-sur-les-probl%C3%A8mes-%C3%A0-r%C3%A9soudre-76ef47284359
- Comment bien utiliser la vélocité ? https://youtu.be/JcpWqm23-qA
- Qu’est-ce que la dette technique ? En quoi entrave-t-elle le développement d’un produit ? https://youtu.be/o2nwLSKhhHo
- Comment gérer la dette technique et garder ses développeurs ? https://youtu.be/Zp1hSFlFtnI
- Le respect du Definition of Done comme base de la gestion de projet agile : https://youtu.be/cEndWSoiWnI
Comments (2)
Jog
Bonjour Scrumlife !
Merci pour cet article. Je rebondis sur la notion de livraison plus souvent et plus régulière. Autant le DoD aide à éviter l’effet chasse-neige consistant à reculer les activités peu intéressantes (docs, rédaction des tests, qualité du code) au profit du pur développement, autant j’ai un peu de mal à comprendre :
– En quoi le DoD assure-t-il une meilleure qualité : cela ne dépend-il pas surtout des règles exprimées dans le DoD (par exemple imposer une règle de cross-testing), et de la qualité de ce qui est produit (que le DoD puisse imposer des tests unitaires, soit. Mais ces tests sont-il exhaustifs au final) ?
– En quoi le DoD permet-il des livraisons plus rapides ?
Merci et longue vie à ScrumLife !
Jog
Ps : et merci pour les cartes no-estimate 😉
Jean-Pierre Lambert
Salut !
En effet la qualité dépend de ce qu’on met dans le DoD, mais…
1. C’est tout bête mais si on ne respecte pas le DoD, peu importe ce qui est dans le DoD. Tout commence par le respecter.
2. Et puis, finalement, tout commence encore avant par le définir. Tout simplement.
En somme le message principal de la vidéo c’est celui-là : “vous devez absolument avoir défini une DoD et vous devez la respecter scrupuleusement” — ce à quoi on pourra aussi ajouter “et améliorez le DoD en permanence”
Enfin sur pourquoi le DoD permet d’accélérer les livraisons, cela revient au point précédent en cascade : c’est la qualité, et l’amélioration continue du niveau de qualité suivi, qui y amènent.
— JP
Comments are closed.