Rétrospective sur les 12 principes agiles
- Retour libre sur le sprint passé et récolte de données (gather data)
- Présentation des 12 principes agiles
- Positionnement des post-it
- Choix des principes à améliorer
- Décider des actions
- Ressenti de l’équipe
- Conclusion
La rétrospective est le moment où l’équipe reprend son souffle et évalue ce qu’il s’est passé pendant le sprint. J’ai voulu profiter de ce moment pour reconnecter mon équipe avec les valeurs de l’agilité. L’objectif de cette rétrospective est de faire découvrir ou redécouvrir les 12 principes agiles sous-jacents aux 4 valeurs du Manifeste Agile tout en permettant à l’équipe d’évaluer sa maturité Agile.
Selon Esther Derby, une rétrospective comprend 5 parties :
- Set the stage ou Check-in (entrée dans la rétrospective)
- Gather data (récolte de données)
- Generate insight (Générer des idées)
- Decide what to do (mettre en place des actions)
- Close the retrospective ou Check-out (conclusion)
Cette rétrospective détaille trois de ces parties : “gather data”, “generate insight” et “decide what to do”, elle ne comprend pas de “check-in” ou de “check-out”.
Matériel
- Des post-its
- Des feutres
- Les 12 principes agiles imprimés ou écrits sur des feuilles (2 principes par feuille A4)
Retour libre sur le sprint passé et récolte de données (gather data)
Après le check-in, j’ai commencé par proposer à l’équipe d’écrire sur les post-its ce qu’ils avaient ressenti ou vécu pendant le sprint passé. Cette fois-ci, pas de catégories, j’ai proposé une écriture libre. Cela a plu à certains, qui se sont sentis libre de s’exprimer sans cadre tandis que d’autres ont eu plus de mal à se lancer.
Pour ces derniers, je leur ai proposé de réfléchir aux habituels points positifs ou négatifs et aux remerciements qu’ils pouvaient avoir afin qu’ils ne soient pas déboussolés par ce format. Ils ont globalement été plutôt emballés à l’idée de ne pas avoir de “cadre” où chaque post-it devait rentrer dans une colonne (+, – et remerciements) comme on peut le voir dans les rétrospectives plus classiques.
Présentation des 12 principes agiles
J’ai ensuite présenté les douze principes agiles sur les feuilles préparées pour l’atelier. J’ai préféré les écrire à la main pour m’en réimprégner à nouveau. J’ai proposé à l’équipe que chacun en lise un à voix haute en faisant un tour de table : chacun pouvant poser des questions si nécessaire.
Rappel des 12 principes agiles
“Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.”
“Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.”
“Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.”
“Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.”
“Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.”
“La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.”
“Un logiciel opérationnel est la principale mesure d’avancement.”
“Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.”
“Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.”
“La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.”
“Les meilleures architectures, spécifications et conceptions émergent d’équipes autoorganisées.”
“À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.”
Positionnement des post-it
J’ai ensuite demandé à chaque personne de l’équipe de lire ses post-its (un à la fois) et que l’équipe discute ensuite sur le principe auquel il correspond.
Exemples : un ticket “la mise en production s’est bien passée” peut se placer au niveau de “Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.”
Ou encore “Un logiciel opérationnel est la principale mesure d’avancement.”. Cependant, ce que la personne a voulu dire en écrivant ce post-it c’est plutôt : “grâce aux différentes bonnes pratiques mises en place (refacto, code review, tests etc…), il n’y avait pas eu de remontées de bugs lors de la mise en production et l’équipe était donc plus sereine”. Avec ces explications, on s’aperçoit alors que ce ticket correspond peut être plutôt au principe suivant : “Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité.”
À ce moment là, l’équipe peut choisir de découper ou d’approfondir l’idée en ajoutant de nouveaux post-it. J’ai proposé de faire plusieurs tours de tables pour cette étape et que chaque personne de l’équipe lise 2 post-its puis passe au voisin afin de rendre cette étape plus dynamique.
À cette étape, il y a eu beaucoup plus de discussions concernant la compréhension des principes. Et c’est ici que l’on s’aperçoit que tout le monde ne comprend pas les principes de la même manière. La compréhension des principes étant parfois subjective, cela permet également de s’assurer que l’équipe communique de manière bienveillante, car il faut que chacun puisse se faire comprendre des autres sans se faire écraser ou écraser les autres. Le rôle du facilitateur ici est donc de bien s’assurer que chacun puisse s’exprimer.
Une fois les différents post-its triés, j’ai demandé si l’équipe pensait à autre chose en dehors des post-its déjà placés. Puis nous sommes revenus sur les douze principes en les relisant tous ensemble et l’équipe devait attribuer à main levée une note entre 0 et 5 sur la position de l’équipe par rapport au principe. 0 correspondant à : l’équipe ne respecte pas du tout ce principe et 5 correspondant à : l’équipe respecte complètement ce principe.
Les résultats obtenus permettront à chacun de savoir sur quoi l’équipe doit s’améliorer. Le but étant de refaire cette rétrospective de manière régulière (tous les 3 ou 4 mois) pour voir l’évolution des résultats.
Choix des principes à améliorer
Je n’ai pas choisi de sélectionner automatiquement le ou les principes avec la moins bonne note. Il peut aussi être intéressant de ne pas choisir un principe qui n’est pas du tout respecté dans le but de faire un peu mieux mais plutôt de choisir un principe qui a une bonne note dans le but d’aller encore plus loin. J’ai donc laissé à l’équipe choisir les principes qui leur tenait le plus à cœur d’améliorer en leur proposant la technique du dot voting.
D’autres techniques peuvent également être utilisées, selon les préférences de l’animateur.
Décider des actions
Nous sommes revenus ensemble sur les principes choisis par l’équipe (le top 2 ou 3). Et selon la note attribuée à l’équipe par rapport à ce principe, je leur ai demandé : “Si dans 3 mois, on refait l’exercice, “que pourrait-on mettre en place pour avoir 1 point de plus ?”. Le choix de trois mois est arbitraire, libre à vous de proposer une autre durée, il est toutefois important de poser cette question en se positionnant dans le temps. Nous n’oublions pas que les actions que nous décidons de prendre doivent être SMART.
Ressenti de l’équipe
L’équipe commençant à être bien mature et à avoir l’habitude des rétrospectives, ils ont accueilli ce nouveau format avec beaucoup d’enthousiasme. Chacun, à son niveau, a pu en apprendre un peu plus sur l’agilité.
L’équipe a aussi apprécié de pouvoir écrire des post-its librement sans avoir le cadre forcé avec les +, les – etc. Pour certains cela a été plus facile que pour d’autres. Il ne faut donc pas hésiter à cadrer un peu en leur proposant des catégories qui ont pu être vues dans des rétrospectives précédentes.
Le ROTI (Return On Time Invested) a été de 4,75 donc l’équipe a globalement bien apprécié cette rétrospective avec un format qui change radicalement des classiques (la moyenne des ROTI étant à 4,25).
Conseils pour faciliter cette rétrospective
Je conseille de garder bien précieusement les différentes notes que l’équipe s’est attribuée (possibilité de calculer une moyenne également) et de refaire cet exercice tout au long de la vie de l’équipe. Tous les 3 mois par exemple pour laisser la possibilité et le temps à l’équipe de pouvoir faire +1 entre 2 sessions.
A l’étape de positionnement, quand plusieurs personnes ne sont pas d’accord sur la place d’un post-it, il ne faut pas hésiter à leur demander ce qu’ils ont compris des principes entre lesquels ils hésitent. Il arrive souvent qu’ils n’aient pas compris le principe de la même manière, ou que certains aient du mal à différencier ceux qui se ressemblent.
Conclusion
Pour créer cette rétrospective, je me suis inspirée d’une rétrospective similaire : vis mon manifesto. La démarche est la même. Cette fois, au lieu de se baser sur les principes, on se base sur les valeurs du manifeste agile. Les valeurs portant sur des concepts plus abstraits, l’équipe peut avoir un peu plus de mal à positionner les post-its. C’est pour cette raison que j’ai choisi de faire cette rétrospective avec les 12 principes agiles.
J’ai trouvé cet exercice intéressant car il permet à l’équipe de redécouvrir en douceur les principes agiles et de se les approprier. Il permet à l’équipe de s’aligner sur une pensée commune de ces principes et de s’assurer que leurs communications restent équilibrées et bienveillantes par rapport à ces concepts plus ou moins abstraits, comme on peut en retrouver régulièrement en informatique, dans le fonctionnel ou dans la technique.