Comprendre le but de la Sprint Rétrospective

En tant que Scrum Master, je remarque que Scrum se démocratise de plus en plus ce qui, de mon point de vue, est une bonne chose. Les entreprises font le constat que ce qui fonctionnait il y a 40 ans n’est plus applicable dans le monde d’aujourd’hui et qu’un changement est nécessaire.

Ces nouvelles mises en pratique de Scrum se basent parfois sur l’expérience de collègues ou sur des articles lus sur Internet. Je constate que peu de personnes prennent le temps de revenir à la source et lire le Scrum Guide, un fascicule de 13 pages qui comme son nom l’indique contient les règles du jeu de Scrum. Du coup, Scrum est appliqué sans forcément comprendre le but derrière certains événements ou certaines responsabilités de l’équipe Scrum (comme celle du Scrum Master de faire comprendre et respecter Scrum).

C’est dans ce contexte que j’ai imaginé l’écriture de cette série d’articles sur les événements Scrum. J’ai le désir ici de réexpliquer les fondamentaux autour des événements, de présenter les améliorations liées à la nouvelle version du Scrum Guide sorti en novembre 2020 et de dézinguer certains mythes autour de Scrum.

Voici donc le quatrième et dernier article de cette série sur la Sprint Retrospective.

(Les autres articles de la série : Comprendre le but d’un Daily et Comprendre le but d’un Sprint Planning, Comprendre le but d’une Sprint Review).

But de la Sprint Rétrospective

Réfléchir à des pistes pour améliorer la qualité et l’efficacité.

Qui participe à une Sprint Rétrospective

La Scrum Team, à savoir les Developers, le Scrum Master et le Product Owner.

Planning

À la fin de chaque sprint, après la Sprint Review, une réunion d’au maximum 3h pour un Sprint d’un mois.

Pourquoi une Sprint Rétrospective

La Sprint Retrospective semble être l’événement Scrum le mieux compris en termes d’objectif et de structure : comme tous les autres événements Scrum, il permet de s’inspecter et de s’adapter. Lors de ce rendez-vous, la Scrum Team se focalise sur son propre fonctionnement. Cela peut être au sujet :

• des individus
• des interactions
• des processus
• des outils
• de la Definition of Done
• …

En résumé, l’équipe analysera ce qui s’est passé et ce qu’elle aimerait améliorer pour l’avenir. Au sortir de l’événement, des améliorations sont attendues.

Même si le but théorique est souvent clair, il est commun de constater que cet événement n’est pas aussi porteur de valeur que nous l’aimerions, ce qui amène souvent aux mythes décrits plus bas.

Le Scrum Guide 2020

En novembre 2020, un nouveau Scrum Guide est sorti avec plusieurs améliorations.

Dans le cas de la Sprint Retrospective, je résumerais les différences entre le Scrum Guide 2020 et le Scrum Guide 2017 par “moins de blabla”. Il est dit la même chose, mais de manière plus succincte et plus efficace.

Il y a tout de même deux différences à noter.

Le Scrum Master

Dans le paragraphe sur la Sprint Retrospective, il n’y a plus aucune mention au Scrum Master. Il est à chaque fois fait mention de la Scrum Team. Comme nous l’avons vu dans les articles précédents, un focus est mis sur l’autogestion de la Scrum Team dans ce nouveau Scrum Guide. Pour cet événement aussi, nous comprenons mieux à présent que la Sprint Retrospective n’est pas l’événement du Scrum Master ou facilité par le Scrum Master. C’est un événement qui est présent pour l’inspection et l’amélioration de la Scrum Team dans son ensemble et qui n’est pas porté par quelqu’un en particulier au sein de l’équipe.

Le Sprint Backlog

Lors de la précédente version du Scrum Guide, il était précisé qu’au moins une amélioration définie lors de la Sprint Retrospective devait se retrouver dans le Sprint Backlog. Cette injonction a été retirée et est remplacée par une proposition : “Elles [les améliorations] peuvent même être ajoutées au Sprint Backlog pour le prochain Sprint.”

Mythes

La rétro n’est pas utile… ou 15 minutes suffisent

Tout Scrum Master a entendu au moins une fois dans sa carrière : “Nous n’avons plus besoin de nous améliorer” ou alors “Les rétrospectives, ça ne sert à rien”.

Dans un cas, comme dans l’autre, une belle discussion entre le Scrum Master et le reste de la Scrum Team doit avoir lieu.

Les raisons qui peuvent amener à cela sont multiples et il est difficile de toutes les lister ici. Cela peut être dû à la peur du changement et de la remise en question ; Peut-être à l’environnement dans l’organisation qui ne permet pas de s’arrêter pour s’inspecter sans blâmes, une organisation pour laquelle changer signifie s’être trompé, avoir commis une erreur. La culture de l’entreprise peut aussi amener à croire que le travail effectif ne se fait que lorsqu’on développe concrètement le produit, derrière son ordinateur, par exemple. Les réunions sont juste une perte de temps.

L’une des raisons qui peut faire penser que cet événement n’est pas utile vient du fait d’avoir expérimenté la Sprint Retrospective et de n’en avoir retiré aucun bénéfice, en particulier à cause des améliorations qui ne sont pas mises en action.

Pour combattre ce mythe, il conviendra entre autres au Scrum Master d’avoir les discussions nécessaires que ce soit au sein de la Scrum Team ou au sein de l’organisation et du management. Ces discussions pourront par exemple tourner autour de :

• la confiance et le respect au sein de l’équipe et du management, ce qui va amener des notions comme le droit à l’erreur, l’empirisme et la transparence.
• la compréhension des événements Scrum et en particulier la Sprint Retrospective, comme le fait que le management ne participe pas à l’événement, ou encore sur l’amélioration continue.
• la capitalisation de ce qui fonctionne : comment faire en sorte que cela continue à bien aller.

Le Scrum Master devra également faire preuve d’exemplarité en osant se remettre en question et en faisant preuve d’humilité en admettant qu’il a sûrement lui-aussi des axes d’amélioration à explorer.

Enfin, la mise en place des Sprint Retrospective devra être particulièrement travaillée et cadrée afin de bien faire comprendre l’utilité, intégrer le bon état d’esprit et prendre les actions nécessaires en vue de l’amélioration continue.

Des améliorations ? Quelles améliorations ?

Les améliorations, souvent sous forme d’actions, sont la clé de la Sprint Retrospective et nous constatons malheureusement qu’il est parfois bien difficile d’en prendre, tout simplement, et d’en prendre qui soient réalistes et concrètes. La Scrum Team doit ensuite se sentir responsable de la mettre en pratique. Pour cela, il pourra être plus facile dans un premier temps d’avoir une personne responsable de cette action, qui en fera le suivi et s’assurera qu’elle est bien appliquée. Sans suivi, lister des actions n’a pas de valeur, car il y a de fortes chances pour qu’elles soient oubliées.

Dans ce cas de figure, nous arrivons souvent à du ressassement dans les sujets. Si un sujet est discuté à chaque Sprint Retrospective et que l’on constate qu’il n’y a pas eu d’évolutions, cela est très frustrant et inutile. Le suivi des actions est indispensable.

Cependant, les sujets reviennent également souvent, car soit ce n’est pas le bon moment de s’en occuper (s’il y a d’autres problématiques plus importantes à régler avant), soit ils ne sont pas dans la sphère de contrôle de l’équipe (voir dans la sphère d’influence). Dans ce cas, la responsabilité du Scrum Master prend toute sa valeur, car c’est l’un des agents du changement qui va trouver dans l’organisation les leviers pour avancer.

La présence du Product Owner n’est pas obligatoire

Pour ce mythe aussi, les raisons sont multiples et dépendent du contexte.

Le Product Owner peut parfois s’exclure de la Sprint Retrospective pour les mauvaises raisons mentionnées sous “la rétro n’est pas utile”. Il peut également y avoir la perception que l’amélioration continue doit avoir lieu du côté des Developers et que cela ne concerne pas le Product Owner. Ceci peut être renforcé lorsque les Sprint Retrospective tournent beaucoup autour de problèmes techniques. Cependant, même si dans ce cas de figure, le Product Owner n’aura peut-être pas une participation très active lors de ces événements, il pourra au moins entendre les difficultés auxquelles font face les Developers, avoir une meilleure compréhension des éléments non-fonctionnels à développer pour les futurs Sprint et éventuellement être un soutien pour obtenir de l’aide externe.

En sens inverse, certains Developers pensent que le Product Owner ne fait pas vraiment partie de la Scrum Team, il est parfois même perçu comme “un client” qui ne doit surtout pas s’immiscer dans les discussions internes des Developers. La Sprint Retrospective pourra être le lieu idéal pour le critiquer et demander au Scrum Master de servir d’intermédiaire pour lui transmettre leurs doléances. Ceci est complètement faux, car la Scrum Team est bien composée des Developers, du Scrum Master ET du Product Owner. Les Developers sont au service du Product Owner pour lui permettre de réaliser l’optimisation de la valeur de son produit.

À ce titre, le Product Owner participe à la Sprint Retrospective et pourra discuter des améliorations continues qui lui sont propres, entendre celles qui seront peut-être plus liée aux Developers, mais surtout travailler en commun sur l’amélioration continue liées aux interactions entre les différentes responsabilités composant la Scrum Team et afin d’atteindre le but de toute l’équipe qui est de construire un produit de la plus grande valeur possible.

Conclusion

J’espère que cette remise en contexte de la Sprint Retrospective vous permettra de mieux comprendre ce qui vient de Scrum et ce qui est une adaptation liée à votre contexte ou peut-être à une mauvaise compréhension du Scrum Guide.

J’aimerais cependant souligner ici que les adaptations ne sont pas forcément mauvaises. L’important est de faire ces changements en pleine conscience et de comprendre ce que cela apporterait de le faire “selon la théorie”.

Avec cette article, nous arrivons au terme de la série. Je vous invite à lire les autres articles sur le Sprint Planning, le Daily Scrum et la Sprint Review.