Beaucoup disent que la rétrospective est la cérémonie la plus importante dans la boîte à outils agile. Woody Zuill l'exprime ainsi : 

Si tu n'introduis qu'une pratique #agile, il devrait s'agir de rétrospectives. Tout le reste suivra.

Woody Zuill

Alors pourquoi est-il possible qu'une équipe de développement considère la rétrospective de sprint comme superflue ? D'après mon expérience en tant que Scrum Master et psychologue, cela est généralement lié au niveau de maturité de l'équipe.

Que peux-tu donc faire pour améliorer le niveau de maturité de ton équipe – dans ce contexte et aussi en général ? Voici 7 réflexions, 7 conseils qui t'aideront à relever ce défi.

L'équipe pense que la rétrospective est superflue : que faire ?

D'ailleurs, la réponse officielle selon l'examen de certification Scrum est celle-ci : Le Scrum Master devrait travailler sur l'équipe pour la rendre plus efficace (en anglais : "The Scrum Master would work on the team to make it more efficient"). Mh, ça n'aide pas vraiment. Qu'est-ce que cela pourrait vouloir dire ?

Le Scrum Master doit travailler sur l'équipe pour la rendre plus efficace.

Le rôle officiel d'un Scrum Master est le suivant, si l'on considère le Guide Scrum regarde : "Le Scrum Master encourage l'équipe Scrum à améliorer son processus de développement et ses pratiques dans le cadre du processus Scrum afin de le rendre plus efficace et agréable pour le prochain sprint".

En théorie, cela signifie que la rétrospective devrait être un événement central du Scrum Master, puisque le but principal de la rétrospective est d'aider l'équipe à s'améliorer continuellement. Cependant, dans la pratique, l'équipe n'a peut-être pas le niveau de maturité nécessaire pour utiliser réellement une rétrospective et ne voit donc pas sa valeur. C'est pourquoi j'interprète personnellement l'affirmation "rendre l'équipe plus efficace" à un niveau abstrait comme "augmenter le niveau de maturité de l'équipe". Comment faire cela dans ce contexte ? Avant de commencer à donner des conseils à ce sujet, une explication s'impose.

La rétro est considérée comme précieuse lorsque l'on s'améliore réellement de manière continue. Alors le sentiment d'autonomie, d'auto-organisation et d'auto-efficacité est élevé. Ce qui conduit à l'hypothèse suivante : La qualité perçue des rétrospectives est l'un des meilleurs indicateurs de la maturité (agile) d'une équipe. 

Si tu veux mesurer la maturité agile –, tu devrais utiliser la qualité des rétrospectives comme indicateur. C'est la relation typique dans le temps entre la "qualité perçue de la rétrospective" et la "maturité agile" d'une équipe.

Voici comment cela se passe : 

1. Les premières rétros sont effectuées, des mesures sont écrites. Le sentiment naît : il se passe enfin quelque chose ! 
2. Les mesures ne sont pas vraiment mises en œuvre. On parle beaucoup, mais peu de choses se passent. 
3. Après un certain temps, la frustration s'installe ou tout simplement ce qu'on appelle la "rétro-fatigue". C'est alors que le phénomène de cet article apparaît : La rétrospective est considérée comme superflue. L'équipe elle-même se perçoit comme relativement mûre et ne voit aucun problème.
4. Ce point n'est atteint que par quelques équipes. C'est-à-dire lorsque la qualité des rétros augmente à nouveau et qu'elle conduit finalement à des améliorations tangibles et que le sentiment d'efficacité personnelle mûrit ainsi lentement. 

J'espère que les conseils de ce texte t'aideront à faire quelques pas dans cette direction. Mais je recommande aussi notre texte sur "7 conseils pour de bons objets d'action", qui jouent un autre rôle dans ce sujet.

1. comprendre pourquoi l'équipe pense qu'une rétrospective n'est pas nécessaire

En tant que Scrum Master, tu as peut-être une hypothèse sur la raison pour laquelle l'équipe pense que la rétrospective de sprint est superflue. Mais s'il te plaît, vérifie cette hypothèse. Demande expressément à l'équipe ce qu'il en est.

Souvent, il y a un "leader d'opinion" dans l'équipe qui a une grande influence sur l'équipe. Essaie de choisir cette personne, de comprendre son point de vue et, dans le meilleur des cas, de concevoir avec elle les contre-mesures (voir ci-dessous).

Plus tu comprends l'équipe, plus tu peux développer un plan pour augmenter le niveau de maturité de l'équipe et choisir parmi les conseils suivants ceux qui sont les plus appropriés.

2. réalise la rétrospective

Tu devrais toujours faire une rétrospective. Supposons que l'équipe a simplement besoin de plus de temps pour atteindre son objectif de sprint – et qu'une heure de codage au lieu de la rétro pourrait être décisive. Dans ce cas, il est acceptable de reporter la rétrospective de quelques jours.

Tu peux aussi changer le type de rétrospective, la rendre plus courte, etc. Mais la meilleure façon de montrer à l'équipe la valeur d'une rétrospective est d'en faire une vraiment bonne. C'est pourquoi mon appel est le suivant : réserve dans tous les cas un créneau dans le calendrier de ton équipe pour la rétro.

3. mesure la valeur ROTI

On ne peut pas changer ce que l'on ne mesure pas. Une habitude simple et rapide qui t'aide à évaluer en permanence la façon dont l'équipe perçoit les rétros est de mesurer le score ROTI : le "retour sur investissement en temps". Pose simplement la question suivante après chaque rétrospective, peut-être comme check-out : "Sur une échelle de 0 à 10, à quel point le temps de cette rétrospective a-t-il été bien investi ? Mesure la moyenne sur le temps – espérons que tu pourras bientôt voir une tendance positive !

Le score moyen "Return-on-time-invest" sur une échelle de 0 à 10 par mois dans l'outil Echometer – les retros en valent-elles la peine ? Il semblerait que oui !

4. fais en sorte que ta rétrospective de sprint soit très courte

L'équipe de développement estime donc que la rétrospective de sprint est superflue – que devrais-tu faire maintenant en tant que Scrum Master ?

Comme je l'ai mentionné au début, l'équipe pense probablement qu'une rétrospective de sprint n'est pas nécessaire parce qu'elle pense que c'est une perte de temps.

En d'autres termes, tu as raison : Au cours des dernières rétrospectives, ils ont apparemment "appris" que le ROTI d'une rétrospective –, c'est-à-dire la qualité du temps investi, voir ci-dessus – est plutôt mauvais. Il existe une approche très simple pour y remédier : investir moins de temps pour la même production.

C'est peut-être le meilleur conseil si l'équipe pense que la rétrospective du sprint est superflue. Dis à ton équipe : ok, nous allons la garder aussi courte que possible (plus d'informations dans notre article de blog "Brève rétrospective – mieux vaut vite que pas du tout"). 

Important : tu ne veux pas signaler que les choses resteront ainsi pour toujours. Ton message reste le même : Les rétrospectives sont vraiment importantes. Tôt ou tard, les rétrospectives ne seront plus aussi courtes.

Mais tu réduis la durée de la rétrospective (par exemple de 60 minutes à 30 minutes), car l'équipe apprend de cette manière à quel point il peut être important d'investir ce temps. Et tu fais croître la durée de la rétrospective de manière quasi "organique", par un "pull" ou un "souhait" de l'équipe, car à un moment donné, elle souhaitera avoir plus de temps pour la rétrospective. Comment faire ? 

Il suffit de poser la question la plus importante :

"Pourquoi n'avons-nous pas réussi à terminer toutes les user stories définies pour la dernière itération ?"

Cela donnera lieu à quelques discussions intenses et probablement à des idées d'actions en peu de temps. Cela pourrait même conduire à des discussions plus longues. Et déjà, l'équipe a signalé qu'elle avait besoin de plus de temps pour une rétrospective (bien sûr, c'est à toi de garder la discussion constructive).

Tu devrais toujours poser la question qui, selon toi, déclenche de bonnes pensées ou discussions au sein de l'équipe. Et tu devrais toujours avoir pour objectif d'enregistrer une expérience que tu essaieras lors du prochain sprint (également connu sous le nom d'action item).

5. suggère de laisser tomber d'autres routines aussi

L'équipe pense donc qu'une rétrospective est une perte de temps. D'accord. En tant que Scrum Master, ton objectif principal ne devrait jamais être d'être la personne qui met en œuvre Scrum. Non, il ne s'agit pas de "Scrum". 

Il s'agit pour l'équipe de réussir et d'apporter une valeur ajoutée au client et aux parties prenantes. Scrum doit aider l'équipe à y parvenir. Mais ce n'est qu'un cadre, un kit de méthodes (plutôt bon) parmi de nombreuses approches possibles pour fournir une valeur ajoutée rapidement, durablement et avec une grande qualité.

Si l'équipe n'est pas satisfaite des rétros, tu peux souligner que tu considères Scrum du point de vue que je viens de décrire. Ensuite, tu ajoutes que tu penses que certaines des autres routines que vous avez sont en fait moins importantes que la rétrospective. 

La rétrospective est le moteur de l'amélioration continue. Elle doit aider les membres de l'équipe à découvrir ce qui a bien fonctionné et ce qui n'a pas fonctionné. Si tu supprimes cette partie de la boucle continue, tu risques de voir la boucle d'amélioration continue s'arrêter.

 

Que se passerait-il, par exemple, si tu laissais tomber quelques rushes ? Sais-tu ce qui se passerait ? Peut-être que cela n'aura aucun effet – parfait, alors autant le garder tel quel et gagner du temps. 

D'un autre côté, cela peut aussi conduire à une mauvaise communication au sein de l'équipe. L'équipe commet donc des erreurs. Finalement, il y aura un besoin organique de plus de communication, ce que tu remarqueras probablement dans la rétrospective. Cette fois-ci, une cérémonie agile n'est pas introduite sur ton insistance, mais sur la base de la "douleur" de l'équipe. Ainsi, l'acceptation de cette cérémonie par l'équipe sera beaucoup plus grande.

6. regarde les rétrospectives passées et montre leur valeur

Une approche qui peut compléter les autres approches est de jeter un coup d'œil à "l'histoire des rétrospectives" de l'équipe sur une plus longue période. La condition préalable est que certaines des dernières rétrospectives soient réussies.

Par exemple, tu regardes la rétrospective d'il y a un an et tu réalises à quel point ces défis étaient difficiles l'année dernière. Et tu réalises alors qu'il serait tellement plus facile de résoudre les mêmes défis aujourd'hui si tu avais toutes les connaissances et l'expérience que tu as acquises.

En d'autres termes, il faut : Tu réalises à quel point tu t'es amélioré entre-temps. Peut-être que cette approche d'"amélioration continue" pourrait fonctionner après tout ? Et les rétrospectives peuvent en effet avoir joué un rôle important. Utilisée correctement, elle peut tout à fait provoquer un moment d'aha dans l'équipe.

En outre, tu peux aussi jeter un coup d'œil sur la valeur ROTI (Return on time investment) de tes dernières rétros (voir ci-dessus) : Si tu peux prouver que la rétrospective a un ROTI de 8 à 10, le temps est manifestement bien investi. Notre outil de rétrospective Echometer, par exemple, demande le ROTI après chaque rétrospective et te donne ainsi un indicateur régulier de la qualité de cette dernière. Performance de toi en tant que Scrum Master.