10. Comment nous faisons les rétrospectives de sprint▲
10-1. Pourquoi nous insistons pour que toutes les équipes fassent des rétrospectives▲
La chose la plus importante à propos des rétrospectives est de s'assurer qu'elles ont lieu.
Pour certaines raisons, les équipes ne semblent pas toujours enclines à faire des rétrospectives. Si on ne les aiguille pas délicatement, la plupart des équipes laissent tomber la rétrospective et passent directement au sprint suivant. Il s'agit peut-être d'un truc culturel en Suède, pas sûr.
Cependant, tout le monde semble d'accord, les rétrospectives sont extrêmement utiles. En fait, je dirais que la rétrospective est la seconde partie la plus importante de Scrum (la première étant la réunion de planification de sprint) parce que c'est la meilleure chance de vous améliorer !
Bien sûr, vous n'avez pas besoin d'une réunion de rétrospective pour avoir de bonnes idées, vous pouvez le faire dans votre baignoire à la maison ! Mais l'équipe va-t-elle accepter votre idée ? Peut-être, mais la probabilité d'avoir l'adhésion de l'équipe est beaucoup plus importante si l'idée vient « de l'équipe », c'est-à-dire si elle vient pendant la rétrospective quand tout le monde est autorisé à contribuer et à discuter des idées.
Sans les rétrospectives vous trouverez des équipes qui reproduiront les mêmes erreurs, encore et encore.
10-2. Comment nous organisons les rétrospectives▲
Le format général varie un peu, mais généralement nous faisons quelque chose comme ça :
- Nous allouons 1 à 3 heures selon le volume de discussions qui est anticipé.
- Participants : le directeur de produit, l'équipe complète, et moi-même.
- Nous allons dans une pièce fermée, un coin avec un canapé confortable, un patio, ou une place du même style. Du moment que nous pouvons discuter sans être dérangés.
- Nous ne faisons pas les rétrospectives dans le bureau de l'équipe, car l'attention des membres a tendance à se relâcher.
- Quelqu'un est désigné comme secrétaire.
- Le Scrum master montre le sprint backlog et, avec l'aide de l'équipe, résume le sprint. Les évènements et décisions importantes, etc.
- Nous faisons «des tours de table». Chaque personne a une chance de dire, sans être interrompu, ce qu'elle pense être bien, ce qu'elle pense qui peut être mieux, et ce qu'elle pense qui devrait être différent pour le prochain sprint.
- Nous comparons la vélocité estimée et la vélocité effective. S'il y a une grosse différence nous essayons d'analyser pourquoi.
- Quand le temps est presque écoulé le Scrum master essaie de résumer les suggestions concrètes pour améliorer le prochain sprint.
Nos rétrospectives ne sont généralement pas très structurées. Le thème implicite est toujours le même : « que pouvons-nous améliorer au prochain sprint ».
Ceci est un exemple de tableau blanc lors d'une récente rétrospective :
Trois colonnes :
- Bien : Si nous pouvions refaire le même sprint, nous ferions ces choses exactement pareil.
- Peut mieux faire : Si nous pouvions refaire le même sprint, nous ferions ces choses différemment.
- Améliorations : Idées concrètes pour s'améliorer dans le futur.
Les colonnes 1 et 2 concernent le passé, tandis que la colonne 3 concerne le futur.
Après que les membres de l'équipe aient déballé tous ces post-its, ils utilisent « le vote par points » pour déterminer quelles améliorations prendre en compte au prochain sprint. Chaque membre de l'équipe dispose de 3 aimants et sont invités à voter pour les améliorations qu'ils aimeraient voir pris en compte en priorité pendant le prochain sprint. Chaque membre peut distribuer ces aimants comme il veut, il peut même placer les 3 sur le même post-it.
En se basant là-dessus ils sélectionnent les 5 améliorations à faire en priorité, et les suivront à la prochaine rétrospective.
C'est important de ne pas être trop ambitieux ici. Concentrez-vous sur un petit nombre d'améliorations par sprint.
10-3. La diffusion des enseignements tirés entre équipes▲
Les informations tirées d'une rétrospective de sprint ont généralement beaucoup de valeur. Est-ce que cette équipe a du mal à se concentrer parce que le directeur des ventes kidnappe les programmeurs en tant « qu'experts techniques » dans les réunions de vente. ? C'est une information importante. Peut-être que les autres équipes ont le même problème ? Devrions-nous mieux éduquer la direction à propos de nos produits, afin qu'ils puissent faire eux-mêmes le support des ventes ?
Une rétrospective ne se limite pas à comment cette équipe peut faire mieux le prochain sprint, ça a des implications plus larges.
Notre stratégie pour appréhender ça est très simple. Une personne (dans ce cas, moi) assiste à toutes les rétrospectives de sprint et agit comme un pont de connaissance. Assez simple.
Une alternative serait que chaque équipe Scrum publie un rapport de rétrospective de sprint. Nous avons essayé ça mais nous trouvons que peu de gens lisent les rapports, et encore moins s'y conforment. C'est pourquoi nous faisons ça de manière simple à la place.
Les règles importantes pour la personne qui fait le « pont de connaissances » :
- Il doit savoir écouter.
- Si la rétrospective est trop silencieuse, il doit être prêt à poser des questions simples mais ciblées afin de stimuler les discussions au sein du groupe. Par exemple « si vous pouviez remonter le temps et refaire le même sprint depuis le 1er jour, qu'est-ce que vous changeriez ? ».
- Il devrait prendre le temps d'aller aux rétrospectives de toutes les équipes.
- Il devrait avoir une certaine autorité, de façon à mettre en oeuvre les suggestions d'amélioration qui ne sont pas sous le contrôle de l'équipe.
Cela marche assez bien mais il peut y avoir d'autres approches qui fonctionnent encore mieux. Dans ce cas, éclairez-moi.
10-4. Changer ou ne pas changer▲
Disons que l'équipe conclut que « nous ne communiquons pas assez dans l'équipe, nous nous marchons dessus et nous mettons la pagaille dans la conception des autres. »
Que feriez-vous pour y remédier ? Introduire des réunions quotidiennes sur la conception ? Introduire de nouveaux outils pour faciliter la communication ? Ajouter plus de pages dans le wiki ? C'est bien, peut- être. Mais encore une fois, peut-être pas.
Nous avons observé que, dans beaucoup de cas, identifier clairement un problème est suffisant pour qu'il se résolve tout seul au prochain sprint. Surtout si vous accrochez la rétrospective de sprint sur le mur du bureau de l'équipe (ce que nous oublions toujours de faire, honte à nous !). Chaque chose que vous introduisez a un coût, aussi avant d'introduire des changements, envisagez de ne rien faire du tout et espérez que le problème disparaîtra (ou réduira) automatiquement.
L'exemple ci-dessus (« nous ne communiquons pas assez dans l'équipe... ») est un exemple typique où la meilleure solution est de ne rien faire.
Si vous introduisez un nouveau changement à chaque fois quelqu'un se plaindra, les gens seront réticents à remonter les problèmes mineurs, ce qui serait terrible.
10-5. Exemples de choses qui peuvent remonter pendant les rétrospectives▲
Voici quelques exemples typiques de ce qui peut arriver pendant un sprint planning, et les actions typiques.
10-5-1. « Nous devrions passer plus de temps à décomposer les histoires en sous-éléments et tâches »▲
C'est assez courant. Chaque jour lors de la mêlée quotidienne, des membres de l'équipe se retrouvent à dire « Je ne sais pas trop quoi faire aujourd'hui ». Alors après chaque mêlée quotidienne vous passez du temps à trouver des tâches concrètes. C'est généralement plus efficace de faire ça en amont.
Actions typiques : aucune. L'équipe règlera ça probablement d'elle-même à la prochaine réunion de planification de sprint. Si cela se répète, prévoyez plus de temps pour le sprint planning.
10-5-2. « Trop de dérangements extérieurs »▲
Actions typiques :
- demandez à l'équipe de réduire leur facteur de focalisation pour le prochain sprint, afin d'avoir un plan plus réaliste
- demandez à l'équipe de bien noter les dérangements pendant le prochain sprint. Qui les dérange, combien de temps. Ca aidera à résoudre le problème plus tard.
- demandez à l'équipe d'essayer de rediriger tous les dérangements vers le Scrum master ou le directeur de produit.
- demandez à l'équipe de désigner une personne comme « gardien », tous les dérangements sont redirigés vers lui, ainsi le reste de l'équipe peut se concentrer. Ce peut être le Scrum master ou quelqu'un à tour de rôle.
10-5-3. « Nous nous sommes trop engagés et nous n'avons terminé que la moitié du travail »▲
Actions typiques : aucune. L'équipe ne s'engagera probablement pas trop au prochain sprint. Ou du moins pas autant que cette fois.
10-5-4. « Notre bureau est trop bruyant et bordélique »▲
Actions typiques :
- essayez de créer un meilleur environnement, ou déménagez l'équipe. Louez une chambre d'hôtel. Ce que vous voulez. Voir page 68 « Comment nous organisons le bureau de l'équipe »).
- Si ce n'est pas possible, dîtes à l'équipe de réduire leur facteur de focalisation, et indiquez clairement que c'est à cause du bruit et du désordre. En espérant que le directeur de produit commencera à harceler la direction à ce sujet.
Heureusement je n'ai jamais eu à menacer de déménager l'équipe. Mais je le ferai si je le devais :o)
11. Relâcher le rythme entre les sprints▲
Dans la vraie vie, vous ne pouvez pas sprinter tout le temps. Vous avez besoin de vous reposer entre deux sprints. Si vous sprintez tout le temps, vous êtes en effet juste en train de faire un jogging.
C'est la même chose avec Scrum et le développement logiciel en général. Les sprints sont plutôt intenses. En tant que développeur vous ne vous relâchez jamais, chaque jour vous devez assister à cette fichue réunion et dire à tout le monde ce que vous avez fait la veille. Peu auraient tendance à dire «J'ai passé la majeure partie de la journée à mon bureau à surfer sur des blogs et siroter du capuccino».
En plus de la vraie pause elle-même, il y a une autre bonne raison d'avoir un relâchement entre les sprints. Après la démo du sprint et la rétrospective, à la fois l'équipe et le directeur de produit seront saturés d'informations et d'idées à digérer. S'ils se remettent immédiatement à courir et commencer à planifier le sprint suivant, il est peu probable que quiconque ait l'occasion de digérer une information ou des leçons apprises, que le directeur de produit n'aura pas le temps d'ajuster ses priorités après la démo de sprint, etc.
Nous essayons d'insérer du relâchement avant de commencer un nouveau sprint (plus spécifiquement, la durée après la rétrospective de sprint et avant la prochaine réunion de planification de sprint).
Tout au moins, nous essayons de faire en sorte que la rétrospective de sprint et la réunion de planification du sprint à venir n'arrivent pas le même jour. Tout le monde devrait avoir au moins une bonne nuit de sommeil « sans sprint » avant de démarrer un nouveau sprint.
Une façon de faire cela sont les «jours labo» (ou quoique vous choisissiez de les appeler). Ce sont des journées où les développeurs sont autorisés à faire essentiellement ce qu'ils veulent (OK, je le reconnais, inspiré par Google). Par exemple, étudier à fond les derniers outils et APIs, suivre une formation, discuter de trucs d'informatique avec les collègues, coder un projet perso, etc.
Notre but est d'avoir un jour labo entre chaque sprint. De cette façon vous avez naturellement une pause entre les sprints, et vous avez une équipe de développement qui a de réelles chances de garder à jour leurs connaissances. De plus, c'est un avantage plutôt attractif pour l'employeur.
Actuellement nous avons des «jours labo» une fois par mois. Le premier vendredi de chaque mois pour être précis. Pourquoi pas entre les sprints à la place ? Eh bien, parce que j'ai pensé que c'était important que toute l'entreprise soit en journée labo en même temps. Autrement les gens ont tendance à ne pas le faire sérieusement. Et comme nous (jusque là) n'avons pas aligné les sprints à travers tous les produits, j'ai du choisir à la place une journée labo indépendamment des sprints.
On pourrait un jour tenter de synchroniser les sprints à travers tous les produits (i.e. même démarrage et fin de sprint pour tous les produits et les équipes). Dans ce cas nous mettrons définitivement un jour labo entre chaque sprint.