Guide de mêlée | 39. Erreurs les plus courantes lors d'une rétrospective de sprint

La rétrospective de sprint est l'événement qui met fin à chaque sprint. Et en même temps l'une des réunions Scrum Team les plus difficiles. Les erreurs les plus courantes lors d'une rétrospective de sprint consistent à éviter les conversations sur des questions sensibles, ainsi que le manque 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. Concentrez-vous sur des problèmes ou des succès ponctuels
4. Surreprésentation du Product Owner
5. Problèmes d'autogestion
6. Trop d'engagements
7. Erreurs courantes lors d'une rétrospective de sprint - Résumé

Introduction

Les erreurs lors d'une Rétrospective Sprint sont malheureusement très fréquentes. En effet, c'est l' une des réunions les plus difficiles à mener à bien car elle demande beaucoup de maturité de la part de l'équipe. C'est pourquoi il vaut la peine de jeter un coup d'œil aux problèmes qui surviennent le plus souvent dans d'autres équipes afin de pouvoir repérer plus facilement leurs symptômes lors de la réalisation d'une rétrospective de sprint dans votre équipe Scrum.

Transparence insuffisante

Selon le Scrum Guide, chaque membre de l'équipe Scrum est obligé d'être honnête et audacieux pour exprimer ses préoccupations et exprimer son opinion lors de la rétrospective Sprint. Cependant, dans la pratique, l'engagement de transparence est très exigeant. Pour cette raison, les membres de l'équipe Scrum essaient souvent de le contourner.

Un problème 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 Sprint.

Concentrez-vous sur des problèmes ou des succès ponctuels

Un autre problème qui peut survenir lors de la rétrospective de sprint est d'accorder une attention insuffisante 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 obtenu un succès exceptionnel. Cependant, Sprint Review ne devrait pas être dédié à le célébrer. Il en est de même des échecs. Si quelque chose a échoué pour des raisons fortuites ou une erreur déjà diagnostiquée, cela ne vaut pas la peine de sur-analyser l'événement lors de la Sprint Review.

Parfois, cependant, l'équipe consacre une grande partie de la rétrospective Sprint à de tels événements. Gardez cependant à l'esprit que le but de Sprint Retrospective est de rechercher des moyens d'améliorer le travail quotidien de l'équipe. Par conséquent, la réunion ne doit pas tourner autour de succès ponctuels ou de problèmes qui ne se reproduiront probablement pas.

Surreprésentation du Product Owner

Dans de nombreuses organisations, le poste de Product Owner est assimilé à 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 d' établir une confiance mutuelle entre l'équipe de développement et le propriétaire du produit. Malheureusement, le processus d'établissement de la confiance est long et difficile. C'est pourquoi il est parfois judicieux que le Product Owner renonce à participer à tout ou partie de la Rétrospective Sprint pour laisser un espace au reste de l'équipe pour discuter librement.

Problèmes d'autogestion

L'autogestion 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 Sprint Retrospective, l'équipe discute des personnes, de leurs interactions ainsi que des pratiques d'équipe. Il décide ensuite quels problèmes doivent être résolus dans le prochain Sprint, comment le faire avec qui sera responsable de prendre des mesures.

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

Parfois, les membres de l'équipe ne veulent pas participer à la discussion et essaient de rejeter la responsabilité de la gestion sur 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 opérant selon les trois piliers de l'empirisme : transparence, inspection et adaptation, peut rencontrer le problème de prendre trop d'engagements à la fois.

Si les engagements pris par la Scrum Team lors d'une Rétrospective Sprint sont trop nombreux, il y a un risque considérable que :

• aucun des engagements ne sera mis en œuvre correctement
• certains engagements ne seront pas du tout mis en œuvre
• les modifications apportées ne seront pas permanentes

Par conséquent, une bonne pratique consiste à ne pas entreprendre plus de quatre améliorations dans 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 Sprint est un événement difficile, des problèmes surviennent souvent lors de son déroulement. Pour les traiter plus facilement, il convient de noter celles 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 face à l'honnêteté dans des situations d'équipe plus difficiles
• se concentrer sur des problèmes ou des 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
• Surrepré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'autogestion - 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é d'abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Auteur : Caroline Becker

En tant que chef de projet, Caroline est experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous la pression du temps font d'elle la meilleure personne pour concrétiser des projets complexes.

Afficher tous les articles

Guide de mêlée :

1. Glossaire des termes, rôles et notions de base
2. Qu'est-ce que Scrum ?
3. Valeurs Scrum
4. Comment implémenter Scrum dans votre entreprise ?
5. Scrum Team - qu'est-ce que c'est et comment ça marche ?
6. Qui est un Product Owner ?
7. Les erreurs les plus courantes du Product Owner
8. Qui est le Scrum Master ?
9. Caractéristiques d'un bon Scrum Master
10. Les erreurs les plus courantes du Scrum Master
11. Quelles statistiques et métriques le Scrum Master doit-il suivre ?
12. Coopération entre Product Owner et Scrum Master
13. Équipe de développement dans Scrum
14. Les erreurs les plus courantes des développeurs
15. Artefacts Scrum
16. Mise à l'échelle Scrum
17. Carnet de sprint
18. Qu'est-ce que le carnet de produit ?
19. Qu'est-ce qu'une User Story ?
20. Créer la meilleure User Story avec INVEST
21. Les erreurs les plus courantes de la User Story
22. Critères d'acceptation des user stories
23. Estimation et Story Points dans Scrum
24. Planification Poker
25. Jeu d'estimation d'équipe
26. Définition de l'incrément
27. Événements Scrum
28. Qu'est-ce que Sprint dans Scrum ?
29. Engagements de l'équipe Scrum - Objectif du produit, objectif du sprint et définition de l'achèvement
30. Qu'est-ce qu'un Burndown Chart ?
31. Comment créer et interpréter un burndown chart ?
32. Avantages et inconvénients du burndown chart
33. Tableaux Kanban dans Scrum et Scrumban
34. Velocity in Scrum - Vitesse de l'équipe de développement
35. Mêlée quotidienne
36. Planification des sprints
37. Revue de sprint
38. Qu'est-ce qu'une rétrospective Sprint ?
39. Erreurs courantes lors d'une rétrospective de sprint
40. Nourrir le backlog produit