Certes mais est-ce suffisant ?
Définitivement NON !
Une fois, toutes les 3 semaines, le dernier jour du sprint, pour vous c’est peut être mieux qu’avant, mais c’est loin d’être suffisant.
Car le feedback c’est le cœur de l’Agilité, l’élément clé du dispositif Agile, celui qui évidemment va assurer l’avancement du projet mais aussi celui qui permet de toujours faire mieux notamment au travers de l’amélioration continue (« Plan-Do-Check-Act » / « Inspect & Adapt »).
Quel est le problème ?
La principale difficulté réside dans le fait que le FEEDBACK (à recevoir / à donner) n’est ni quelque chose de naturel, ni une habitude ancrée dans notre façon de travailler.
Loin de le rechercher, beaucoup d’équipes ont donc tendance à le fuir ou à le retarder, tout en rationalisant tant bien que mal une conduite de moins en moins justifiable …
- « Ça va nous ralentir »
- « S’il donne son feedback, on en finira jamais »
- « De toute façon il ne sera jamais content »
- « Il va rajouter des choses »
- « Dans le Sprint? on a pas le temps »
- « L’itératif ça marche comme ça…on se voit à la fin et les modifs c’est pour le sprint suivant »
- « Mais alors à quoi ça servirait de faire une demo? »
- …
Le feedback est déterminant et multiple
La qualité du Feedback est selon moi un indicateur majeur du caractère agile d’une équipe, signe d’une performance maîtrisée.
- Sans Feedback, ça ne marche pas…
- Plus vous intégrez tôt le feedback, mieux c’est…
- Plus le feedback est rapide, mieux c’est…
L’absence de feedback constitue donc une entrave à la performance de l’équipe qui nuit gravement à la dynamique collective ainsi qu’à la fluidité du « process » agile.
Son impact sur la qualité du produit est évident, à court ou moyen terme.
Maintenant, être prêt à recevoir (POSITIVEMENT) le feedback, et inversement, donner du feedback (DE MANIERE CONSTRUCTIVE), c’est un changement culturel majeur pour les Hommes et les organisations.
Plus qu’une question d’apprentissage, c’est d’abord une affaire de volonté et d’état d’esprit qui nécessite de s’appuyer sur trois ingrédients essentiels à cultiver sans modération :
- le courage,
- le respect
- la confiance.
Et Pour l’équipe Agile ?
- C’est solliciter des retours du Client (ou Product Owner) le plus tôt et le plus souvent possible, TOUT AU LONG DU SPRINT
- C’est multiplier les rencontres avec les utilisateurs finaux, dans une approche Guerilla Usability ou RITE
- C’est se donner en permanence du feedback dans l’équipe (Daily Scrum, workshops, Pair programming, Tests…)
- C’est recueillir en continu le feedback du produit (TDD, Intégration continue, Tests fonctionnels automatisés ou non : cela sert à ça !)
- C’est faire une demo plus formelle à chaque fin de sprint
- C’est finalement tenir compte de ces feedback et s’adapter en continu dans un esprit » kaizen »
Mon Challenge de coach Agile :
- Mettre la question du feedback au cœur des préoccupations de l’équipe et les amener à travailler ensemble sur cet axe
- Remettre les valeurs & Principes agiles sur le devant de la scène et cultiver des valeurs humaines fondamentales telles que le respect, le courage et la confiance
- Insister au niveau de l’organisation sur les vertus de la colocalisation (Product Owner / Equipe) et inciter le Product Owner à assister le plus souvent possible aux Daily Scrum
- Inciter l’équipe à « TERMINER » les choses et à les montrer en sollicitant aussitôt le Product Owner (client)
- Inciter le Product Owner (Client) à aller voir, à initier la conversation, à faire le premier pas sans attendre la demo de fin de sprint …
- Convaincre de l’intérêt de rencontrer les utilisateurs finaux
- Impliquer les acteurs et faciliter directement le feedback au travers de RDV collaboratifs
La conclusion me vient directement d’une équipe qui travaille dans un mode agile depuis quelques mois et de ses réponses plutôt éloquentes à cette question de retrospective « Qu’est ce qu’on a fait de bien sur ce sprint ? »:
1. « Les workshops techniques »
2. « Les workshops Business »
3. « Le maquettage (Balsamiq)
Chez eux, le feedback progresse ….
Mes autres Alertes:
- Alerte Agile N° 7: Notre Product Owner va craquer !
- Alerte Agile N°6 : Le dailyScrum c’est pour qui au juste ?
- Alerte Agile N°5 : où sont les testeurs ?
- Alerte Agile N°4: Mon ScrumMaster en fait trop !
- Alerte Agile N°3 : des priorités… ah bon ?
- Alerte Agile N°2: un backlog… quel backlog ?
- Alerte Agile N°1: votre équipe manque de rythme !
Une petite question qui me tarabuste… Si l’on sollicite le feedback du client *tout au long du sprint*, à quoi sert, finalement, la revue (la démo) ?
D’ailleurs, moi qui pratique la revue, je trouve que l’on n’a peu de temp pour solliciter du vrai feedback et qu’il est plus efficace de le solliciter le plus souvent possible. Donc… à quoi sert la revue ?
« C’est solliciter des retours du Client (ou Product Owner) le plus tôt et le plus souvent possible, TOUT AU LONG DU SPRINT »
Je suis très étonné par cette phrase… On fait généralement un point avec le client à la fin d’un sprint. C’est à dire quand on a quelque chose à montrer. Laissons à l’équipe le temps de construire avant de demander un feedback.
Je ne vous recommande pas non plus « C’est se donner en permanence du feedback dans l’équipe ». Au final cela donne une image de perpétuel changement et que l’on ne sait pas que l’on veut. Je l’ai vu pratiquer par quelques PO, le résultat est mal vu des équipes.
Pour terminer, vous faites référence au kaizen, dans ce terme, il y a changement. Le changement doit être associé à la valeur (faire mieux) et ne pas se faire n’importe comment. On l’utilise à tort avec les méthodes Scrum. Scrum n’est pas une méthode de changement.
Bonne journée
Désole de vous contredire mais la dimension changement est inscrite dans l’agilité. Et changement signifie aussi rupture avec nos habitudes et autres schéma de pensèe…
80% des remarques ou coorections demandées en demo pourraient être corrigées avant avec plus de feedback…
Le feedback permanent est la marque des équipes agiles performantes; évidemment toutes n’ont pas ce niveau ! Il faut travailler pour l’obtenir!
Bonsoir JC,
« Désole de vous contredire », ne le soit pas au contraire, c’est qui fait le débat et surtout aide à construire les idées.
Je suis d’accord avec toi sur « dimension changement », mais il est aussi dit qu’une fois un sprint commencé, on ne change plus.
« 80% des remarques ou coorections demandées en demo pourraient être corrigées avant avec plus de feedback… » Je pense qu’il y a donc un problème, si tu arrives à 80% au moment dela démo.
Si tu as tes user story, ton UI et la conception technique pour commencer ton sprint, tu ne dois pas te retrouver à 80%. Pour ma part, nous sommes à peine à 15%
« Le feedback permanent est la marque des équipes agiles performantes; évidemment toutes n’ont pas ce niveau ! « ,
j’ai de la chance de travailler avec des gars performants, c’est le contraire qui se produit, il capte vite, sont des pros dans leur domaine, ils vont à l’essentiel. Le feedback est minime. Si j’ai besoin de revenir tout le temps, c’est que j’ai un problème avec mon équipe ou je n’ai pas su me faire comprendre.
Attention au perpétuel changement, cf. http://www.amazon.fr/Alerte-sur-banquise-changement-conditions/dp/2744063487/ref=sr_1_1?ie=UTF8&s=books&qid=1278886282&sr=8-1 (très intéressant à lire)
Bonne soirée, au plaisir de te lire de nouveau
Yannick