Guide Scrum | 39. Les erreurs les plus courantes lors d’une rétrospective de Sprint

La rétrospective de sprint est l’événement qui clôt chaque sprint. Et en même temps, c’est l’une des réunions les plus difficiles pour l’équipe Scrum. Les erreurs les plus courantes lors d’une rétrospective de sprint consistent à éviter les conversations sur des sujets sensibles, ainsi qu’à l’absence d’engagements concrets menant à la résolution de problèmes déjà diagnostiqués.

Erreurs courantes lors d’une rétrospective de sprint – table des matières :

1. Introduction
2. Transparence insuffisante
3. Concentration sur des problèmes ou succès ponctuels
4. Surréprésentation du Product Owner
5. Problèmes d’auto-gestion
6. Trop d’engagements
7. Erreurs courantes lors d’une rétrospective de sprint – Résumé

Introduction

Les erreurs lors d’une rétrospective de sprint sont malheureusement très courantes. Cela est dû au fait que c’est l’une des réunions les plus difficiles à exécuter avec succès car cela nécessite beaucoup de maturité de la part de l’équipe. C’est pourquoi il vaut la peine de jeter un œil aux problèmes qui surviennent le plus souvent dans d’autres équipes afin que vous puissiez plus facilement repérer leurs symptômes lors de la conduite de la rétrospective de sprint dans votre équipe Scrum.

Transparence insuffisante

Selon le Guide Scrum, chaque membre de l’équipe Scrum est obligé d’être honnête et audacieux dans l’expression de ses préoccupations et de faire entendre son opinion lors de la rétrospective de sprint. Cependant, en pratique, l’engagement envers la transparence est très exigeant. De ce fait, les membres de l’équipe Scrum essaient souvent de l’éviter.

Un problème qui est difficile à repérer et à résoudre est d’éviter de discuter des lacunes observées dans le travail de l’équipe Scrum. Cela peut entraîner des problèmes beaucoup plus graves à long terme.

La tâche du Scrum Master est donc de surveiller de près la situation dans l’équipe et d’encourager tous les membres de l’équipe à être proactifs dès le début de la rétrospective de sprint.

Concentration sur des problèmes ou succès ponctuels

Un autre problème qui peut survenir lors de la rétrospective de sprint est de ne pas prêter suffisamment attention aux comportements d’équipe cycliques et répétitifs, et à leur impact sur l’efficacité de l’équipe.

Il est toujours bon de féliciter les membres de l’équipe Scrum s’ils ont réalisé un succès exceptionnel. Cependant, la revue de sprint ne devrait pas être consacrée à célébrer cela. Il en va de même pour les échecs. Si quelque chose a échoué pour des raisons fortuites ou une erreur déjà diagnostiquée, il n’est pas utile de sur-analyser l’événement lors de la revue de sprint.

Cependant, parfois, l’équipe consacre une grande partie de la rétrospective de sprint à de tels événements. Gardez à l’esprit que le but de la rétrospective de sprint est de chercher des moyens d’améliorer le travail quotidien de l’équipe. Par conséquent, la réunion ne devrait pas tourner autour de succès ou de problèmes ponctuels qui sont très peu susceptibles de se reproduire.

Surréprésentation du Product Owner

Dans de nombreuses organisations, le poste de Product Owner est équivalent à celui de Product Manager. Le Product Owner est alors souvent considéré comme le superviseur de l’équipe Scrum. Pour cette raison, il arrive que l’équipe de développement ne veuille pas parler des problèmes de travail d’équipe en sa présence.

C’est pourquoi il est si important de construire une confiance mutuelle entre l’équipe de développement et le Product Owner. Malheureusement, le processus de construction de la confiance est difficile et long. C’est pourquoi il est parfois judicieux que le Product Owner renonce à participer à tout ou partie de la rétrospective de sprint pour laisser de l’espace au reste de l’équipe pour discuter librement.

Problèmes d’auto-gestion

L’auto-gestion signifie que les membres de l’équipe Scrum prennent leurs propres décisions sur qui parmi eux effectuera certaines tâches, quand et comment. Lors de la rétrospective de sprint, l’équipe discute des personnes, de leurs interactions ainsi que des pratiques de l’équipe. Elle décide ensuite quels problèmes doivent être résolus lors du prochain sprint, comment le faire ensemble et qui sera responsable de la mise en œuvre.

Si des problèmes plus graves surviennent dans une équipe auto-gérée, il peut y avoir une tentation dans l’équipe Scrum d’abdiquer la responsabilité.

Occasionnellement, les membres de l’équipe ne veulent pas participer à la discussion et essaient de transférer la responsabilité de la gestion à quelqu’un d’autre. Pour éviter cela, il est extrêmement important de discuter régulièrement même des petits problèmes pour éviter leur accumulation.

Trop d’engagements

Une équipe Scrum active fonctionnant selon les trois piliers de l’empirisme : transparence, inspection et adaptation, peut rencontrer le problème de faire trop d’engagements à la fois.

Si les engagements pris par l’équipe Scrum lors d’une rétrospective de sprint sont trop nombreux, il y a un risque considérable que :

• aucun des engagements ne soit correctement mis en œuvre
• certains engagements ne soient pas mis en œuvre du tout
• les changements effectués ne soient pas permanents

Par conséquent, une bonne pratique est de ne pas entreprendre plus de quatre améliorations à chaque sprint. Cela permet une amélioration progressive mais efficace des performances de l’équipe.

Erreurs courantes lors d’une rétrospective de sprint – Résumé

Étant donné que la rétrospective de sprint est un événement difficile, des problèmes surviennent souvent lors de sa conduite. Pour y faire face plus facilement, il vaut la peine de noter ceux qui surviennent le plus souvent. Les erreurs courantes lors d’une rétrospective de sprint sont :

• transparence insuffisante – lorsque les membres de l’équipe Scrum ne parviennent pas à faire preuve d’honnêteté dans des situations d’équipe plus difficiles
• concentration sur des problèmes ou succès ponctuels – lorsque les membres de l’équipe Scrum se concentrent sur la discussion des succès et des échecs, au lieu de discuter de l’efficacité à long terme du travail de l’équipe
• surréprésentation du Product Owner – lorsque les membres de l’équipe Scrum traitent le Product Owner avec une confiance limitée comme s’il était quelqu’un d’extérieur à l’équipe ou un superviseur
• problèmes d’auto-gestion – lorsque les membres de l’équipe Scrum essaient de transférer la responsabilité des problèmes et de la prise de décision.

Si vous aimez notre contenu, rejoignez notre communauté de abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.