J'ai donc soigneusement planifiée la rétrospective, notamment à l'aide de ce livre, qui est une véritable mine d'or d'activités et de jeux de groupe permettant à la fois d'introduire la rétrospective, collecter les informations, en extraire l'essentiel, prendre des décisions et clôturer la rétrospective.
La veille au soir, j'ai donc vidé mon mur d'information et préparé mon paperboard
en fonction des activités que j'avais sélectionné, et j'ai programmé le chauffage dans la salle de réunion afin qu'elle soit confortable lors du début de la rétrospective, prévue pour le lendemain matin.
J'ai commencé la séance de manière relativement traditionnelle, en présentant le principe de la rétrospective et son objectif.
J'ai ensuite poursuivi en demandant à chacun de décrire en quelques mots ce qu'ils attendaient de cette réunion, puis de définir à bulletin secret leurs états d'esprit respectifs, à choisir parmi les possibilités suivantes :
- Explorateur
- Acheteur
- Vacancier
- Prisonnier
L'objectif de cette activité est de permettre au meneur de la rétrospective de saisir l'état d'esprit des participants et d'adapter les activités suivantes en fonction du résulat.
À ma grande joie, je n'ai eu ni vacancier ni prisonnier, et nous avons donc pu poursuivre par la timeline
, qui nous a servit de base pour poursuivre notre réflexion collective.
Chaque participant a donc disposer de 10 minutes pour écrire sur des post-its verts, jaunes et oranges les événements respectivement positifs, neutres ou négatifs qui l'ont marqué au cours du sprint écoulé, pour ensuite les classer par ordre chronologique sur une frise commune.
Le résultat a été relativement surprenant, dans le sens ou le niko niko
n'a pas fait ressortir de mécontentement significatif au quotidien alors que la timeline
a fait ressortir, via une majorité de ticket orange, une insatisfaction sur la durée.
Il faut dire que j'ai participé à la timeline
, alors que je n'ai pas participé au niko niko
, et j'ai donc forcément biaisé quelque peu le résultat car j'ai apporté un bon lot de ticket orange, mais cela n'explique pas une divergence aussi importante.
Cela a été confirmé par le fait que lorsque j'ai demandé aux autres participants de noter le travail de l'équipe à bulletin secret, il en est ressorti qu'ils ne sont effectivement pas content du travail fourni, alors que je n'ai pas participé au vote.
J'en ai donc conclus que les membres de l'équipe ne sont pas satisfait de leur travail ou de leurs conditions de travail au quotidien, mais qu'ils font contre mauvaise fortune bon cœur, et après discussion, il semble que ce soit là la bonne explication.
L'autre chose qui m'a choqué est qu'aucun autre membre de l'équipe n'a été dérangé par le fait que le sprint n'ai pas été achevé et qu'en conséquence le travail réalisé ne soit pas livrable.
J'avoue que cela m'a profondément dérangé car cela prouve que la notion d'engagement et de responsabilité de l'équipe n'a pas été du tout assimilée et qu'actuellement, l'équipe ne semble pas avoir de problèmes particulier à ne pas avoir réalise le travail demandé.
À ce stade, j'avais donc déjà obtenu deux axes de travail sur lesquels concentrer mes efforts pour les sprints suivants, indépendamment de ceux que l'équipe aura fait ressortir d'elle-même au cours de la rétrospective.
Après une pause d'une quinzaine de minutes, nous avons rassemblé les tickets de la timeline
par problématique et chaque membre de l'équipe a ensuite réparti 4 points entre chacune d'elles, afin de faire ressortir celles sur lesquelles il était nécessaire de travailler en priorité.
Deux problématiques sont ressorties très nettement du lot, conformément aux problèmes que j'avais constaté au cours du sprint, à savoir la technique et les problèmes de qualité, et afin de trouver les causes réellement à l'origine de ces deux problèmes, nous avons appliqué la méthode des 5 pourquoi ?
.
Un membre de l'équipe a donc demandé à l'un des autres membres de l'équipe pourquoi la technique est actuellement un problème, la personne interrogée a alors répondu, par exemple, que l'équipe était souvent dérangée et a relancé le débat en demandant à son tour à un autre participant la raison pour laquelle l'équipe était souvent dérangée, et ainsi de suite jusqu'à 5 fois.
L'idée peut paraître saugrenue mais donne étonnamment de très bon résultat, car elle permet de dépasser les réponses évidentes et la langue de bois et faire ainsi ressortir les vrais problèmes, généralement à partir du troisième échange de pourquoi ?
, et cela a encore été une fois confirmé.
Nous avons alors obtenu une matière suffisante pour faire un brainstorming afin de trouver un moyen de supprimer les causes de nos problèmes.
Pour cela, nous avons commencé par rédiger nos idées individuellement sur des tickets, à raison d'une idée par ticket, avant de les faire tourner de façon à ce chaque ticket passe entre les mains de chaque membre de l'équipe pour qu'il l'enrichisse au besoin ou donne son avis.
À l'issue du tour de table, nous avons dépilé les tickets et sélectionné collectivement les solutions que nous avons jugé, après débat, les plus pertinentes.
Avant de clôturer la rétrospective, j'ai également souhaité que nous évaluer sur 4 axes que j'ai, pour une fois, défini arbitrairement à partir des problèmes que j'avais constaté au cours du sprint, à savoir la simplicité, la qualité, la communication et la productivité.
Afin d'adoucir le côté dictatorial de mes choix, j'ai proposé à l'équipe de les compléter, mais elle n'a pas jugé nécessaire de le faire.
Pour obtenir la notation, j'ai utilisé la technique du radar, qui consiste a dessiner sur une feuille les axes mentionnés précédemment en étoile, et de demander à chacun des participants de noter chaque axe à bulletin secret.
Je n'ai eu ensuite qu'à dépouiller les bulletins et à reporter les notes sur chacun des axes correspondants pour obtenir une représentation graphique de la notation, que nous pourrons mettre à jour lors de chacune de nos prochaines rétrospectives afin de mesurer les progrès réalisés.
Enfin, j'ai demandé aux participants leur feedback sur la rétrospective, afin de savoir ce qui doit être amélioré, modifié ou abandonné lors de la prochaine.
Il en est ressorti notamment que l'ensemble manquait de rythme, malgré le nombre d'activité relativement important que nous avons effectué.
Je n'ai pu qu'être d'accord avec cela, car la rétrospective a durée quasiment une journée, alors que j'avais espéré pouvoir la faire en une demie-journée.
Il faut dire que j'ai pris le temps d'expliquer beaucoup de choses et que je n'ai pas, volontairement, spécialement dirigé les débats, afin de laisser l'équipe s'approprier le processus et aller à la racine des problèmes.
Une fois l'effet découverte passé et lorsque l'équipe aura compris que c'est elle qui est au commande, j'ai bon espoir que les choses se déroule beaucoup plus rapidement.
Dans l'intervalle, je n'ai, entre guillemet, qu'à faire en sorte de responsabiliser l'équipe, à améliorer ses conditions de travail et à mettre en œuvre les décisions prises lors de cette rétrospective et à mesurer leurs impacts à l'aide de notre radar lors de celles à venir.
Je sens que je vais m'amuser !
12 réactions
1 De Ubikuity - 10/12/2011, 19:41
Merci. Billet très intéressant.
Est ce que tu peux juste me confirmer le nombre total de personnes dans l'équipe ? 4 ou 6 personnes ?
Est ce que les membres de l'équipe doivent travailler sur le même projet ? Ou est-ce qu'il peuvent être répartis sur plusieurs projet (avec au minimum 2 personnes par projet afin de faire un minimum de "pair programming" et de "code review") ?
2 De mageekguy - 10/12/2011, 23:37
@Ubikuity : L'équipe qui a fait la rétrospective était composée de 4 personnes, moi compris.
J'ai également un autre développeur qui travaille avec le département marketing pour tout ce qui concerne le SEO et les sites web commerciaux et qui travaille donc pour l'instant sur des projets distincts.
Enfin, j'ai un administrateur système et réseau, qui par définition, est transverse à l'ensemble des projets.
Durant les semaines qui viennent, nous allons certainement bouleverser un peu tout cela afin de pouvoir mener plus efficacement deux gros projets de front, en formant deux équipes de deux personnes dont les effectifs changeront régulièrement afin de mutualiser la connaissance du code et effectivement pouvoir continuer à faire du pair-programming, de la revue de code, etc.
3 De Nauw - 11/12/2011, 23:25
Bonsoir,
Merci pour cet article intéressant.
J'ai quelques questions sur plusieurs points.
Pourquoi abandonner Redmine?
Nous l'utilisons pour que les équipes non techniques se forcent a formaliser leur demandes, et cela nous permet efficacement de suivre chaques tâches. (report, status,bug lies).
Le côté ludique (planning poker) semble intéressant, mais comment faire passer ce genre de pratique auprès de ses supérieures et collègues plus "old school"?
Concernant Le Niko-Niko , il me semble que c'est Le rôle de manager de percevoir l'humeur de son équipe. Pourquoi est-il utile de Le faire formaliser par l'equipe?
Dernière question... Comment gérer Le pair programming entre des développeurs de niveau différent, dont l'égau des plus fort est souvent écrasant?
Merci pour ton blog il est très intéressant.
4 De mageekguy - 12/12/2011, 09:28
@Nauw : Dans notre cas, l'utilisation de Redmine apporte trop de contraintes pour aucun avantage.
Il faut en effet le remplir, ce qui prend plus de temps que de d'écrire un descriptif sur un post-it en quelques lignes.
Il coupe la communication physique entre les personnes car il devient le canal de discussion privilégié, et du coup, les informations circulent mal voir pas du tout.
Ce phénomène est de plus amplifié par le fait qu'il faut maintenir les tickets à jour, ce qui n'est pas toujours fait et reste toujours plus complexe que de mettre un post-it à la poubelle et en refaire un nouveau.
De plus, le code et les tests contiennent déjà la mémoire de l'application et je ne vois pas d'intérêt à créer un doublon qu'il faut maintenir.
Cependant, ce qu'il faut bien comprendre, c'est que j'ai pris cette décision mais qu'elle n'est pas gravée dans le marbre.
C'est peut être une bonne idée, ou pas, et si l'équipe décide d'utiliser à nouveau Redmine, je n'y verrais aucun inconvénient.
Concernant le planning poker, suivant le contexte, sa mise en œuvre peut demander peu ou beaucoup de diplomatie, comme tout ce qui touche à l'agile, d'ailleurs.
Je pense que la meilleure stratégie pour faire accepter ce genre de pratique consiste à demander une période d'essai afin que les gens concernés se rendent compte de leur efficacité.
Quand au niko niko, il permet de prendre une photographie sur la durée de l'humeur individuelle de chacun, et non de l'équipe, au cours du temps.
En tant que manager je sens de manière ponctuelle que tel ou tel personne est heureuse, à un problème ou fait la gueule.
Mais mémoriser tout cela quotidiennement, sur 3 semaines, pour 5 personnes est clairement hors de ma portée, car malheureusement, je n'ai pas que cela à faire de mes journées.
De plus, je suis qu'un humain et je ne peux donc pas lire dans les pensée.
À ce titre, je suis donc faillible, et d'ailleurs, 80% du temps, lorsque je demande à quelqu'un s'il a un problème parce que je pense qu'il a un problème, la réponse est négative.
J'ajouterais que je pourrais prendre un accès d'humeur ponctuel causé par une frustration passagère pour une généralité, et qu'en conséquence, mon ressenti serait encore une fois complètement faux.
Autant donc laisser à chacun le soins de s'exprimer sur sa journée de travail tout au long du sprint, puisqu'il est le plus à même de répondre.
Pour terminer, je n'ai pas de recette magique concernant la mise en œuvre du pair-programming dans le contexte que tu décris.
L'agilité ne peut fonctionner que si tous les intervenants font de leur mieux pour le bien de l'équipe et du projet et que tout les intervenants en sont intimement persuadés.
Bref, le développement logiciel en équipe est basé sur la confiance mutuelle et le respect des autres.
Cela suppose donc que les jedi acceptent de partager leur savoir avec leur padawan dans le respect et la franchise, pour le bien de tous.
Si ce n'est pas le cas, la rétrospective est un bon moyen de mettre en lumière le problème et d'y trouver une solution, la plus extrême était l'exclusion de l'équipe du membre n'adhérant pas à ses valeurs.
Chacune de tes questions mériterait presque un billet dédié.
5 De bourvill - 12/12/2011, 10:02
Super retour.
Et la question de @nauw et ta reponse sont vraiment intéressantes.
L'agile est vraiment un échange pour avancer ensemble. Et avoir une bonne vision des choses avec des rétrospectives donnent vraiment bien la température de l’équipe.
Merci
6 De David - 12/12/2011, 15:03
Ah l'agilité...
De mon avis de développeur avec 1ans d'agilité (made by Octo), la rétrospective, dans sa forme originale est à réserver aux entreprises qui ont les moyens de perdre du temps. (Comme tout l'agilité diront certains mais bon, il y a de bonnes choses quand même!)
De ce fait, elle doit allé à l'essentiel si il y a des problèmes et sinon, ne pas essayé de s'en inventer comme elle a la fâcheuse tendance quand on planche sur le remplissage des post it.
Un bref mot sur les jeux de rôle de celle-ci (j'ai des souvenirs de Playmobil à ce sujet..), ils sont non professionnel et décrédibilisent le travail de ceux qui les mettent en place. Le Niko Niko est de même augure... Et le daily-srcum ou stand-up meeting est auto-suffisant pour les problèmes rencontrés.
L'agilité oui, mais épurée pour ne garder que l'essentiel, sans perte de temps, et plus professionnel.
7 De Kyoku57 - 12/12/2011, 17:41
@David
Tout partage d'expériences, peu importe la forme, est bon à prendre et ne peut pas être assimilé à une perte de temps. Pouvoir faire un point avec son équipe c'est important et si cela peut se faire sur l'ensemble des aspects du métier, c'est encore mieux. Perdre son temps pour ce genre de choses, ça devrait être obligatoire.
Par contre, c'est quoi l'agilité "épurée" ? Il y a un label PUR pour l'agilité maintenant ?
8 De David - 13/12/2011, 12:29
@Kyoku57 : "Epurée", car de mon avis et de ceux de la majorité de mes collègues, pour ne pas dire tous, il y a du bon et du mauvais dans l'agilité et il ne faut donc pas s'acharner à mettre en place tous ses outils mais sélectionner et adapter.
Et en se plaçant du coté du chef d'entreprise, mais aussi des développeurs qui aiment coder, il y a des largesses sur les temps de dialogues et autres activités ludiques qui devrai plutôt être mis au profit de l'action.
9 De Olivier - 15/12/2011, 11:04
Très bon billet, hyper complet.
De mon point de vue, la timeline est l'élément clé de la retro et permet de faire ressortir, dans la durée du sprint, nombre de faits marquants.
Autre activité qui fonctionne : les "5 pourquoi". Elle permet d'aller au bout des choses et de passer outre la bienséance initiale.
Disclosure : j'ai assisté à cette rétro.
P.S. : on voit le grand professionnalisme à des comme ça "La veille au soir, [...] j'ai programmé le chauffage dans la salle de réunion"
10 De francois.m - 16/12/2011, 00:37
Le retour d'un des 4 de la rétro.
Un des gros avantages de la rétro, c'est de prendre le temps de lever le nez du guidon et de voir ce qui s'est passé avec un peu de recul, non seulement autour de soi (l'équipe) mais sur soi aussi.
Jusqu'à maintenant, nous avions la fâcheuse tendance de pédaler comme des fous et de ne pas aller au bout des choses. C'est le problème quand personne ne sait dire "non" dans le tandem commercial - prod : on fait tout vite, mal et pas fini.
Ceci étant dit, tu comprendra que personne ne s'indigne de ne pas avoir atteint l'objectif du sprint. Et tu es aussi là pour nous remettre dans le bon chemin et nous reconcentrer sur les fondamentaux.
Pour ce qui est post it, je suis encore mitigé : la surface utile offrant peu de place pour la description de la tâche, on en arrive quasiment à de la culture orale et de fait volatile.
On en parlera à la prochaine rétro ...
11 De hub - 17/12/2011, 05:42
Tu bosses plus chez PMSIPilot donc ?
12 De mageekguy - 17/12/2011, 14:49
@hub : cf ce billet.