# data[].attributes.attachment_link.readable_text
Ce matin, j'ai fait jouer une version adaptée du célèbre Lego4Scrum, le résultat est plutôt sympa (la ville idéale est vraiment chouette) vous trouverez ci-dessous les 4 variantes que j'y ai apporté.

Variante 1

Mon objectif pour cette variante était de donner des raisons d'utiliser une méthode agile sur un projet car la plupart des joueurs ne connaissaient que les méthodes traditionnelles.

J'avais préparé un Cahier des Charges de ma Ville Idéale qui tenait sur 1 page et qui décrivait mes attentes en termes de maison, d'immeuble, de bâtiments divers, de routes ...

Nous avons lu ensemble ce document puis je leur ai demandé s'ils se sentaient capable de réaliser cette ville idéale en 35 minutes avec le matériel dont ils disposaient ?

J'ai plutôt eu des questions que des réponses, et certaines questions concernaient le niveau de détail du CdC qui leur semblait insuffisant. J'ai alors ajouté que je n'étais pas vraiment certain de tout ce que voulait et qu'il me serait difficile de détailler le CdC. Par contre, j'avais les idées claires sur quelques éléments qui me paraissaient importants et que je leur proposait d'utiliser une méthode agile pour réaliser le projet ... et c'était parti !!

Variante 2

Mon objectif pour cette variante était de montrer l'utilité d'avoir un Product Owner un un Scrum Master proche de l'équipe.

J'avais donc fabriqué des Badges spécifiques que chaque joueur devait porter pour identifier son rôle.

En tant que Sponsor de la ville idéale, j'ai commencé à m'adresser uniquement aux Product Owner, et au fil du temps et des rétrospectives, les équipiers se sont directement adressés à moi, tout d'abord lors des démo, puis pour valider les livraisons au fur et à mesure.

En tant que Sponsor j'ai également apporté directement des exigences aux équipiers ... et j'avoue que les Scrum Master n'ont pas été suffisamment vigilants pour gérer cela correctement.

Variante 3

Mon objectif pour cette variante était de montrer que les développeurs et les opérations peuvent travailler ensemble.

J'avais donc identifié des " Equipiers 1 " qui pouvaient manipuler les lego sans accéder au plateau de la ville idéale (la prod) et des " Equipiers 2 " qui pouvaient accéder au plateau et reprendre des réalisations existantes (suite à des remarques du sponsor en cours de sprint sur les éléments du plateau) mais ne pouvaient pas créer un nouveau bâtiment à partir d'une exigence.

Au delà de la frustration des Equipiers 2 lors de la première itération, car ils n'avaient pas grand chose à faire, l'exercice à bien montré qu'il est indispensable de travailler ensemble (Dev & Ops).

Variante 4

Mon objectif pour cette variante était d'obliger les équipes à collaborer compte tenu de leurs spécialités, et au delà du fait qu'elles travaillent toutes sur la même ville idéale.

Il y avait dans chaque boîte de lego certains éléments que les autres équipes n'avaient pas à leur disposition. Certaines exigences n'étaient réalisables qu'avec ces éléments spécifiques et bien entendu ce sont ces exigences spécifiques que j'ai (en tant que sponsor) communiqué directement aux équipes qui n'étaient pas en mesure de les réaliser 🙂

Conclusion

Le débriefing a été très riche d'enseignements pour les participants et il m'a permis de souligner l'efficacité de certaines pratiques des méthodes agiles et des concepts qui vont avec.

Voilà pour aujourd'hui, si vous utilisez une de ces variantes, dites moi ce que vous en pensez ?

# data[].attributes.attachment_link.description
Ce matin, j'ai fait jouer une version adaptée du célèbre Lego4Scrum, le résultat est plutôt sympa (la ville idéale est vraiment chouette) vous trouverez ci-dessous les 4 variantes que j'y ai apporté. Mon objectif pour cette variante était de donner des raisons d'utiliser une méthode agile sur un projet car la plupart des joueurs ne connaissaient que les méthodes traditionnelles.

# data[].attributes.attachment_link.description
Facilitator's guides for Scrum with LEGO simulation for Agile trainers, coaches and practitioners.

# data[].attributes.attachment_link.readable_text
L'atelier du Lego for Scrum est un atelier Agile qui permet d'initier les équipes Agile au Scrum, à les confronter aux premières problématiques rencontrées et de découvrir pour un coach les différents types de profils (niveau comportement) des personnes qui vont constituer les futures équipes.

Cet atelier qui est parfois vu comme trop ludique par certains participants est très révélateur du travail que devra faire le Coach Agile et ses éventuels semblables pour amener les équipes au Scrum ou framework basés sur Scrum.

Démarrer sur de bonnes bases

Pour démarrer sur de bonnes bases, nous allons indiquer rapidement quelques éléments clés du déroulement de la séance.

Pour ma part, je fais toujours de jolis slides pour accompagner le déroulement de la séance afin d'avoir toujours un visuel de certaines choses. La présentation est à mes yeux très importante dans le coaching.

Si nous percevons un interne qui serait moteur de la transformation Agile et qui secondera notre rôle de coach Agile, nous n'hésiterons pas à le mettre en tant qu'observateur afin de déterminer différentes choses :

les réfractaires à la méthode

les leader

les personnes trop directives sur les autres

les personnes effacées

Cela permettra de mettre rapidement des attentions particulières sur ce type de personnes qui seront des atouts ou des problèmes pour la transformation Agile.

Nous indiquons aux gens que le jeu durera 2h30, que vous ferez des équipes de 4 à 6 personnes (une boite de Lego par équipe) et que chaque équipe aura son board personnalisé.

Les équipes travailleront sur la création d'une ville ensemble mais qu'ils construiront chacun de leur côté une partie de cette ville. On rassemblera la ville qu'en fin de séance.

Vous vous présenterez comme le Product Owner et que les autres personnes seront les devs.

Phase 1 : préparation du jeu

Auto-organisation des équipes (5 minutes)

Nous proposons aux devs de se réunir équitablement en équipe afin de voir les affinités éventuelles entre les personnes.

Définition du projet (5 minutes)

A présent, nous expliquons concrètement le contenu du projet.

"Je veux que vous me construisiez une jolie ville qui répondra à l'ensemble de mes demandes".

Les devs devront utiliser des Lego, une feuille A3 (ou kraft) et également d'éventuels éléments extérieurs.

Nous le dirons clairement que nous sommes les seuls à décider le contenu du produit final mais que nous serons disponibles pour répondre aux questions des développeurs.

Construction du Backlog (15 minutes)

A présent, nous allons donner la liste de nos demandes aux développeurs qui devront scrupuleusement les respecter :

Je veux au moins un bâtiment avec 1 étage

Je veux au moins un bâtiment sans étage

Je veux un magasin

Je veux une école

Je veux une église

je veux un hôpital

je veux une maternelle

je veux une intersection

je veux un jardin public

je veux une rivière

je veux un pont

je veux un arrêt de bus

Quand cela est fait (le mieux c'est d'avoir préparé les post'it avant), nous demandons aux équipes de poser toutes leurs questions pour avoir des précisions sur nos demandes.

Estimation des demandes (25 minutes)

Cette partie est la plus longue de la préparation car nous allons commencer par expliquer le concept de Poker Planning en utilisant comme points d'effort (complexité) 1, 2, 3, 5, 8 et 13.

Nous allons demander à l'équipe de définir ensemble une demande qui sera la référence pour la complexité "2".

Ensuite, nous demandons à l'équipe de juger chaque demande en expliquant les concepts de consensus quand on tombe sur les cas qui l'imposent.

Cette phase peut-être longue, il ne faut pas hésiter à accélérer si nous voyons que ça tarde trop afin de ne pas dépasser les 25 minutes prévues de base.

Pause (20 minutes)

Petite pause sachant que les équipes vont devoir être beaucoup plus actives sur la suite de l'atelier.

Phase 2 : Jeu

Nous allons faire 3 sprint complets lors de cette phase de jeu. Il y a de nombreuses erreurs que les équipes feront dès le premier Sprint.

Planification du Sprint (3 minutes)

Les équipes vont prendre 1 minute 30 pour se répartir les tâches (pas d'obligation de toutes les prendre) et les équipes auront 1 minute 30 pour s'organiser chacune de leur côté.

Au moment de la séparation, les équipes n'ont plus le droit de communiquer entre elles.

Nous demanderons au premier Sprint de privilégier la construction de l'école qui est la top priorité.

Sprint (7 minutes)

Les équipes vont devoir construire les éléments de la ville qu'ils ont réalisés.

Lors du dernier Sprint, nous tenterons de rajouter des tâches ultras prioritaires comme un nouveau bâtiment par équipe pour surcharger les équipes de travail ; la réaction de l'équipe sera soumise à discussion lors de la dernière review/retro. Il ne faudra pas hésiter à stresser les équipes en criant le temps restant jusqu'à faire un décompte oral à partir de 10 secondes ; rajouter des tâches pendant la planning est très utile aussi pour intensifier le stresse des équipes.

Les gens révèlent beaucoup plus leur comportement quand ils sont en stresse ; il ne faut cependant pas oublier de préciser en fin de séance que le Scrum a pour but justement de ne pas créer un stresse aussi intense.

Voici un petit résultat de Lego for Scrum :

Review/retro (5 minutes)

Nous demandons aux équipes de se retrouver et de faire le tour des morceaux de ville réalisés.

Nous vérifierons le board pour être sûr qu'il soit à jour et on trouvera plein de critiques pour montrer que les demandes sont pas totalement respectées.

Lors du premier Sprint, l'école sera potentiellement terminée et nous simulerons un accident avec notre bonhomme Lego ; nous demanderons alors d'avoir des feux pour sécuriser la zone (idée de tests d'acceptance de la story).

Voici des choses que nous pourrons souligner :

"Ne développez pas ce que je vous ai pas demandé, vous avez perdu du temps pour développer ce que je vous ai demandé."

"Pensez à mettre le board à jour"

"Respectez ce que je vous ai demandé"

"Faites de la qualité sur mon produit"

Debriefing (15 minutes)

Nous proposons aux équipes à présent de faire un debriefing complet sur l'atelier Lego for Scrum pour voir ce que l'ensemble en proposant les questions suivantes :

Vos impressions ? Le Scrum ?

Itérations courtes ?

Estimations étaient précises ?

Travail du Product Owner ?

Travail du Scrum Master ?

Que devait gérer le dev ?

Que feriez-vous si on rejouait ?

Comment avez-vous vécu la fin du premier Sprint ?

Si le Product Owner pas disponible, que feriez-vous ?

Comment était la communication entre les équipes ?

Conclusion

Pour ma part, j'aime beaucoup cet atelier qui permet d'initier les équipes au Scrum (certes de façon très basique) mais également de découvrir des profils.

# data[].attributes.attachment_link.title
L'atelier ludique du Lego for Scrum - Blog Myagile Partner

# data[].attributes.attachment_link.description
L'atelier du Lego for Scrum est un atelier Agile qui permet d'initier les équipes Agile au Scrum, à les confronter aux premières problématiques rencontrées et de découvrir pour un coach les différents types de profils (niveau comportement) des personnes qui vont constituer les futures équipes.

# data[].attributes.body
Ouvrir la rétrospective

Rassembler des informations

Générer des solutions

Décider quoi faire

Fermer la rétrospective

# data[].attributes.headline
SCRUM - Méthode de gestion de projet Agile

# data[].attributes.subject
SCRUM - Méthode de gestion de projet Agile

# data[].attributes.attachment_link.title
SCRUM - Méthode de gestion de projet Agile

# data[].attributes.attachment_link.description
SCRUM est une méthode de gestion de projet dite Agile. Le nom de SCRUM qui s'écrit en lettres majuscules n'est pas un acronyme mais bien un terme renvoyant au terme anglais de rugby signifiant " mêlée ".

# data[].attributes.headline
Animez vos rétrospectives – Première partie 

# data[].attributes.subject
Animez vos rétrospectives – Première partie 

# data[].attributes.attachment_link.readable_text
Il y a 7 années · 17 minutes · Agile

La rétrospective est l'une des cérémonies préconisées dans les méthodologies de développement agile. Son rôle est de permettre aux équipes de développement, et aux individus qui la composent, de continuellement s'améliorer.

Les rétrospectives pourront ainsi aider les équipes à améliorer leur productivité mais aussi les compétences de ses membres ou encore la qualité de ce que l'équipe produit. Leur but va donc bien au delà d'une analyse post-mortem d'une itération de développement de laquelle découlerait une amélioration des processus de développement.

Dans cet article, nous allons vous donner quelques clés pour vous aider à comprendre les enjeux et à mieux piloter vos rétrospectives.

L'origine des rétrospectives : le Kaizen ou la pratique Lean de l'amélioration continue

La rétrospective telle que nous la connaissons dans les méthodologies de développement agile tire son inspiration dans le milieu industriel et plus particulièrement automobile avec l'outil nommé Kaizen venant du Japon et faisant partie de l'outillage de la méthodologie Lean. Le Kaizen, littéralement " changement bon " est une méthodologie d'amélioration continue dont Toyota fut l'un des précurseurs.

Le Kaizen repose sur différents principes :

tenter d'améliorer chaque règle de travail (working agreements),

développer les compétences et l'implication de toute l'équipe,

se focaliser sur la cause racine des problèmes,

améliorer les processus afin de gagner en productivité.

Cette démarche de développement continu introduit le changement de manière graduelle et ne repose donc pas sur des réformes complètes et brutales du système du type " on efface tout et on recommence ". Dans cette démarche, chaque travailleur est impliqué et est force de proposition pour améliorer sa manière de travailler.

Les méthodes agiles ont repris ce principe pour l'intégrer au sein du cycle de développement. Dans la méthodologie agile Scrum par exemple, une itération de développement, est constituée de différentes cérémonies :

une session d'estimation en début d'itération,

un stand up meeting chaque jour,

une démonstration des fonctionnalités développées,

une rétrospective.

La rétrospective est donc une partie intégrante du cycle de développement, et du travail de l'équipe.

Pourquoi mettre en place une démarche d'amélioration continue ?

Nous vivons dans un monde où les besoins de nos clients, les technologies ou encore la concurrence évoluent en permanence. Dans ce contexte, il est donc nécessaire de faire évoluer nos méthodes de travail afin de rester en phase avec les attentes du marché.

De plus, le fonctionnement d'une équipe est rarement parfait, il peut exister des tensions, des malaises, des regrets et d'autres sources de démotivation que les rétrospectives peuvent aider à découvrir et à traiter. La motivation d'une équipe est effectivement quelque chose qui s'entretient en supprimant les causes de démotivation, et non en essayant de motiver coûte que coûte en faisant fi des problèmes.

Différents axes de progression sont possibles lorsque l'on cherche à améliorer le fonctionnement d'une équipe de développement comme par exemple :

la productivité de l'équipe,

les compétences et les connaissances de chacun,

la cohésion de l'équipe et la collaboration de ses membres,

la communication interne ou externe,

la qualité de ce qui est produit,

l'intérêt et la motivation des collaborateurs,

les règles de travail (working agreements),

etc.

Cette liste est loin d'être exhaustive et bien d'autres axes de progression peuvent être abordés au cours des rétrospectives.

Les rétrospectives permettent d'explorer différents axes de progression et permettent aux équipes de s'accomplir au mieux dans chacun d'eux. Avant de continuer, nous allons nous intéresser à la manière dont l'un de ces axes pourrait être abordé et ce qui pourrait en découler.

L'amélioration de la productivité de l'équipe

Avec l'évolution actuelle des méthodes de développement, qui portées par des mouvements tels que le Craftsmanship tendent à nous orienter vers une culture du travail bien fait, la recherche de la productivité pourrait être perçue comme allant à contre courant. Bien évidemment il n'en est rien si on part du principe que cette recherche de productivité ne va pas à l'encontre de la qualité et si elle s'inscrit dans la durée. En effet, une mauvaise productivité peut être le signe de nombreux problèmes que les rétrospectives peuvent aider à mettre en exergue et à résoudre.

Pour commencer, qu'appelle-t-on " mauvaise productivité " et qu'est ce qu'une " bonne productivité " ? Ces notions sont particulièrement subjectives et il est difficile d'établir une règle permettant de les définir. Nous recommandons donc de s'attacher à étudier l'évolution de la vélocité de l'équipe de développement plutôt que sa valeur absolue. Cette notion de vélocité est utilisée dans des méthodes de développement agile comme Scrum. Elle représente la somme de travail effectuée sur des tâches terminées (selon la Definition of Done de l'équipe).
Une évolution à la hausse de cette vélocité peut indiquer une prise de maturité de l'équipe par rapport au projet, un projet sain etc.
En revanche, une évolution à la baisse pourra soulever des problèmes de qualité (probablement dûs à une dette technique élevée), des conflits au sein de l'équipe, des problèmes d'organisation, etc.

L'étude de cette évolution devra se faire sur plusieurs itérations afin de permettre à l'équipe d'en tirer des conclusions pertinentes. En effet, une vélocité en dents de scie pourrait par exemple mettre en avant des développements rapides mais de piètre qualité, suivis d'itérations où l'équipe corrige les anomalies qui en découlent.

Une fois les problèmes détectés et les causes analysées, l'équipe cherchera des idées afin d'y remédier et mettra en place des actions permettant d'améliorer la productivité. Nous verrons dans la suite de cet article les méthodes permettant de conduire cette réflexion et d'établir les actions à entreprendre.

Pourquoi ne pas se contenter d'appliquer les " bonnes pratiques " ?

Dans le but de rester performant et concurrentiel, pourquoi ne pas se contenter d'un peu de veille et d'appliquer les différentes pratiques reconnues comme efficaces et développées par les experts des méthodologies de développement ?

Premièrement, il existe un nombre très important de bonnes pratiques et il est impossible de toutes les appliquer. De plus, les méthodologies n'étant pas toujours compatibles entre elles, nous nous retrouverions souvent à devoir faire un choix cornéliens entre telle ou telle méthodologie. Enfin, ces méthodologies elles même évoluent en permanence et nous incitent par la même occasion à faire de même, nous plongeant dans une spirale sans fin d'adoption de nouvelles méthodes de travail à appliquer " by the book ".
Une approche plus pragmatique est donc conseillée. Elle consiste à essayer et adapter tout ou une partie de ces méthodes, en réponse à un besoin ou à un problème. Ce dernier point est particulièrement important, les réponses apportées par une méthodologie doivent effectivement découler d'un problème levé par l'équipe de développement. Il n'est donc pas nécessaire d'apporter une réponse (nouvelle méthodologie) s'il n'y a pas de problème.

Deuxièmement, les équipes de développement sont différentes les unes des autres. Les personnes qui les constituent, le contexte du projet, les technologies employées, la culture de l'entreprise etc. sont autant de paramètres à prendre en compte dans le choix d'une méthodologie plutôt qu'une autre. Il est donc impératif que l'adoption d'une méthodologie soit unanime et non imposée. Prenons l'exemple du pair programming, cette méthodologie qui consiste à développer en binôme est assez peu répandue malgré ses vertus. Son adoption est souvent difficile pour plusieurs raisons : incompréhension de la direction, acceptation nécessaire du regard critique de son binôme sur notre manière de développer, adoption d'un rythme différent, etc. Sans un engagement complet de l'équipe, il ne sera pas possible de mettre en œuvre ce genre de méthodologie. Si les membres de l'équipe n'y adhèrent pas, il sera difficile de la mettre en place.

Devant l'opulence des méthodologies et les différences entre les équipes de développement, il est nécessaire de continuellement adapter nos méthodes de travail et d'en expérimenter de nouvelles. C'est précisément le but des rétrospectives, que nous allons étudier dans la suite de ce document.

Le principe " inspecter et adapter "

L'amélioration continue fait appel à la rétrospective comme outil d'analyse et de prise de décision. Elle repose globalement sur les phases suivantes :

identification des problèmes,

détermination des causes d'origine ( root cause analysis ),

définition des actions à entreprendre pour remédier à la cause racine.

Cette méthodologie nécessite une importante dose de courage afin d'aborder les problèmes et leurs causes racines. Il peut en effet être éprouvant d'effectuer cet exercice - qui est malgré tout nécessaire - car si les problèmes de fond ne sont pas abordés, l'équipe est condamnée à ne plus progresser.
Cette constatation rejoint le paradoxe de Stockdale qui peut être défini de la manière suivante :
" Nous devons croire en nos capacités à réussir " et en même temps " être capable de se confronter à la plus brutale des réalités, quelle qu'elle soit ".

La démarche d'amélioration continue nécessite donc que les problèmes ne soient pas " cachés sous le tapis " mais bien au contraire, exposés au grand jour afin de trouver leur origine et les actions à entreprendre afin de les régler.

Les working agreements

Un peu plus tôt dans cet article, nous avons parlé des règles de travail ou working agreements et nous allons maintenant les définir.

Les working agreements sont des valeurs et accords érigés par l'équipe de développement. Ils appartiennent à l'équipe et ont pour rôle de responsabiliser chaque membre. Certains accords définissent des interactions et processus entre les différents acteurs du projet dans le but d'optimiser l'efficacité de l'équipe. Ces working agreements se développent et s'ajustent au fil du temps. Afin que tout le monde les ait en tête, on peut les afficher sur un tableau à la vue de tous.

Voici quelques exemples de valeurs : qualité, simplicité, travail d'équipe, courage. Ou encore quelques exemples de règles: heure et lieu du stand-up meeting, définition d'une* user story "done", disponibilité du product owner, etc. Il peut être utile, voir nécessaire de définir des workings agrements dans le cadre d'une rétrospective lorsque l'équipe manque de discipline.

Structure d'une rétrospective

La rétrospective fait partie intégrante du cycle de développement. Elle se déroule à la fin de chaque sprint ( ou itération). Au démarrage de la rétrospective, l'animateur définit l'agenda, les enjeux et les objectifs de la rétrospective, et peut être amené à rappeler les working agreements. Le début de la réunion peut aussi être propice pour faire une petite synthèse du dernier sprint et remercier l'équipe pour ses efforts.

Basées sur le principe Inspect and Adapt présenté précedemment, les rétrospectives sont structurées en cinq étapes amenant l'équipe à identifier les problèmes et dysfonctionnements et à trouver des solutions afin d'améliorer le processus de développement. La rétrospective est une réunion timeboxée, la gestion du temps est très importante.
Ci-dessous, vous pouvez observer les cinq étapes d'une rétrospective, ainsi qu'un pourcentage de répartition de chacune sur la durée totale de la réunion:

définir la réunion (5%) : définir l'agenda, les enjeux et les objectifs de la rétrospective, et rappeler les working agreements si nécessaire,

collecter les données (30-50%) : créer une vision globale et partagée de tous,

trouver des idées (20-30%) : identifier les forces et les faiblesses, analyser les causes et trouver des solutions,

décider des actions à mener (15-20%) : sélectionner quelques actions à mener aux prochains sprints,

conclure la rétrospective (10%) : dé-briefer sur la réunion, noter les décisions et remercier les participants.

Par ailleurs, il peut être utile de garder du temps (5-10%) en réserve pour se prémunir des débordements.

L'organisation spatiale de la salle de réunion est aussi une donnée à ne pas négliger. En effet, une barrière physique peut rapidement devenir une barrière mentale. Éviter les salles de type " théâtre" et privilégier un espace circulaire ou semi-circulaire pour que tout le monde puisse se voir et communiquer facilement.

Les activités

A chaque étape d'une rétrospective sont associées des activités. Armé de papiers, de crayons, et de post-its, l'équipe travaille et réfléchit dans un cadre ludique et studieux. Selon la taille de l'équipe, et afin de favoriser la participation de tous, des sous-groupes peuvent être formés temporairement pendant la réalisation d'une activité. D'autre part, les activités sont sensées permettre d'apporter de nouvelles perspectives et un cadre pour aider les participants à réfléchir ensemble. Il peut y avoir plusieurs activités par étape.

Les activités sont étudiées pour répondre aux principes ARCS :

Attention : Garder la concentration des participants,

Relevant : Pertinent par rapport aux objectifs,

Competence : Tous les participants peuvent accomplir les tâches,

Satisfaction : Ne pas avoir le sentiment d'avoir perdu son temps.

Un prochain article présentera de manière plus détaillée chacune des étapes d'une rétrospective, et nous verrons aussi des exemples d'activités.

Les rôles du retrospective leader

L'animateur de la rétrospective (ou retrospective leader) n'est pas nécessairement le Scrum Master. Ce rôle peut tourner entre les différents membres de l'équipe.

Préparer la rétrospective

La première fonction du leader est de préparer la rétrospective. Pour deux heures de réunion, il faut parfois compter la même durée pour la préparation. Il définit alors les activités de la rétrospective en fonction de divers paramètres comme la taille de l'équipe, la complexité du projet, et choisit les activités. Pour se prémunir des débordements durant la réunion, une astuce est de sélectionner en seconde option des activités plus courtes.

Animer le groupe de travail

La seconde fonction du leader est d'animer la réunion. Tout d'abord, il contrôle le temps passé sur chaque activité. Cette tâche peut aussi être déléguée à un autre participant. Par ailleurs, il est le garant des Working Agreements et s'attache à les faire respecter par tous.
Avant de commencer une activité, l'animateur présente son déroulement et rappelle les objectifs de celle-ci (exemple: collecter un ensemble de données réparties sur une période afin d'obtenir une vision partagée par tous). Pendant l'activité, il répond aux questions et observe attentivement le niveau de participation. Il peut aussi être amené à recadrer l'activité en cas de débordement.

Le facilitateur

En tant qu'animateur d'un groupe de travail, le leader a aussi un rôle de facilitateur. Le facilitateur est une personne neutre qui ne prend pas parti, et n'expose pas son point de vue durant la réunion. Il met en place des méthodes pour aider le groupe à travailler efficacement. Pour parvenir à cela, il encourage la participation de tous, favorise la compréhension mutuelle et cultive la notion de responsabilité partagée.

L'art de gérer le " facteur humain "

Les individus d'une équipe en tant qu'êtres humains ont des émotions et sentiments. Les rétrospectives exposent un certain nombre de problèmes d'origines variées. Elles sont parfois sources de tensions et de conflits au sein de l'équipe. Chaque individu étant unique, celui-ci réagira différemment à une situation donnée. La manière de gérer les rapports humains et la communication avec les autres sont des enjeux importants pour que la réunion apporte une réelle valeur à l'équipe et au projet. On comprend alors la nécessité pour l'animateur de faire preuve d'empathie, d'avoir un sens de l'observation, et une certaine maîtrise de soi.
Son rôle consiste alors à désamorcer les tensions et attaques directes, qui n'apportent rien aux problèmes de fond. Il peut aussi amener les individus à exprimer leurs émotions de manière subtile, afin de libérer en eux des ressentiments inexprimés. Par exemple, au lieu d'employer la question directe à un membre: " Qu'as-tu ressenti durant ce dernier sprint ? ", utiliser plutôt celle-ci: " Quels sont les moments importants qui t'ont le plus marqué négativement et positivement ? ". Bien sur l'animateur n'est pas responsable des émotions de chacun. Il ne peut pas les contrôler, mais il doit faire en sorte que la réunion reste productive.
Par ailleurs, il peut s'appuyer avec parcimonie sur des méthodes et techniques psychologiques. Sans rentrer dans le détail de cette science, voici deux exemples pour illustrer notre propos.

Le langage Je/Il

Version Il: " Julien n'a pas arrêté de casser le build ! "
Version Je: " J'avais peur que nous rations notre objectif, car nous avons eu beaucoup de build cassés. "
Encourager l'emploie du pronom " Je " plutôt que " Il ". En effet, le " Je " centre le débat sur l'observation et l'expérience de l'intervenant, plutôt que de blâmer une personne. Lorsque quelqu'un critique ou attaque personnellement une autre personne, il faut intervenir et recadrer la discussion sur le contenu, afin de découvrir les causes réelles d'un problème.

Le triangle de Karpman

Le triangle de Karpman représente trois rôles: La victime, le persécuteur, et le sauveteur.
C'est un modèle qui tend à exprimer, que si une personne utilise un de ces rôles (par exemple la victime), elle entraîne l'autre à jouer un rôle complémentaire (le Sauveur ou le Persécuteur). Il peut aider à comprendre les mécanismes ayant généré un conflit. Ainsi, L'animateur avisé pourra éviter de rentrer dans le rôle du sauveteur, chose qui arrive bien souvent quand un membre s'en prend à un autre.

Conclusion

Dans ce premier article, nous avons introduit ce que sont les rétrospectives et leur utilité. Nous avons vu que les rétrospectives s'inscrivent dans une démarche d'amélioration continue. Elles permettent aux équipes et aux membres qui les composent de progresser et de mieux collaborer.
Nous avons aussi vu que les rétrospectives s'articulent autour du principe Inspect and Adapt qui nous force à réaliser une analyse en profondeur des problèmes avant de leur apporter des solutions.

Ces rétrospectives sont animées par un Leader ayant pour rôle de faire en sorte que le temps investi dans la rétrospective soit rentabilisé au mieux (ceci commence par le respect du temps imparti). Le retrospective leader est aussi responsable du choix des activités et du bon déroulement de la séance de travail.

Dans le prochain article, nous détaillerons les différentes phases des rétrospectives et nous vous proposerons quelques activités inspirées du livre d'Esther Derby et de Diana Larsen, Agile Retrospectives: Making Good Teams Great.

# data[].attributes.attachment_link.keywords[]
rétrospective méthodes agiles scrum lean xp

# data[].attributes.attachment_link.title
Animez vos rétrospectives - Première partie

# data[].attributes.attachment_link.description
Il y a 7 années · 17 minutes · Agile La rétrospective est l'une des cérémonies préconisées dans les méthodologies de développement agile. Son rôle est de permettre aux équipes de développement, et aux individus qui la composent, de continuellement s'améliorer.

# data[].attributes.headline
À chaque sprint sa rétrospective : les classiques

# data[].attributes.subject
À chaque sprint sa rétrospective : les classiques

# data[].attributes.attachment_link.readable_text
Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Doit-il se tourner vers la simplicité d'un format classique, l'amusement d'un format fun, ou chercher le format qui s'adaptera le mieux au sprint vécu ? Un grand nombre de formats existent sur le web, cette série d'articles va faire le tri et aidera le Scrum Master à choisir le meilleur format possible pour le jour J. Mais attention à ne pas brûler les étapes...

La rétrospective en rappel

De toutes les cérémonies préconisées par Scrum, la rétrospective est le principal vecteur de l'amélioration continue. L'équipe dispose d'une à deux heures pour inspecter ce qui a été fait durant le sprint et identifier des actions concrètes. Les axes d'améliorations touchent aussi bien la productivité, la qualité du produit, la motivation, les connaissances ou les relations entre individus. De nombreuses techniques d'animation ont vu le jour, cherchant à faire réfléchir les participants d'un point de vue particulier ou en les aidant à se détendre afin de les rendre plus actifs.

Quelle que soit la méthode envisagée, il est d'usage de structurer cette cérémonie en cinq grandes étapes :

L'ouverture (5-10 min).

Le recueil des données (15-30 min).

La génération d'idées (20-40 min).

La définition d'actions à mener (10-15 min).

La clôture (5-10 min).

Pour plus de détails, de nombreux écrits existent déjà comme par exemple Animez vos rétrospectives de David Galichet et Romain Schlick ou encore Donnez du peps à vos rétrospectives de Maria Frih.

Étape par étape

À chacune des cinq phases de la rétrospective, le Scrum Master fait face à un dilemme : quel format choisir ? Cette série d'articles traitera principalement des formats permettant le recueil des données. En effet, cette phase est déterminante pour avoir un contenu suffisamment intéressant pour le reste de la cérémonie. Répéter indéfiniment le même format peut avoir des conséquences sur la qualité de la rétrospective : avec le temps, les personnes vont se lasser, ne seront plus autant actives et finiront par ne plus voir l'intérêt de cette cérémonie. En revanche, conserver le même format sur les autres étapes de la rétrospective n'impactera que très peu la qualité de celle-ci.

Trouver l'atelier qui correspond le mieux au contexte d'un sprint requiert une certaine expérience. Avant d'atteindre ce stade, il faut d'abord connaître et maîtriser les bases. Les formats classiques restent simples mais néanmoins très efficaces. Une fois à l'aise avec ceux-ci, les transcender pour en tirer le meilleur parti deviendra un vrai jeu d'enfant !

Quand utiliser un format classique ?

Les formats classiques vont pouvoir s'appliquer facilement dans les situations suivantes :

Équipe débutante en Scrum

Lorsqu'on apprend à conduire, on ne commence pas avec une Ferrari sur l'avenue des Champs-Elysées mais plutôt avec une Twingo dans un parking vide. C'est la même chose pour la rétrospective. Si le Scrum Master est débutant, il se tournera vers un format simple à comprendre, à expliquer et donc à animer. Si c'est toute l'équipe qui débute en Scrum, un format simple permettra à tout le monde de se familiariser avec la rétrospective et d'apprendre doucement à structurer ses pensées dans le cadre de cette cérémonie. Dans les deux cas, la pratique successive de plusieurs formats classiques sera bénéfique à tout le monde.

La flemme du Scrum Master

Quel Scrum Master n'a pas déjà eu un oubli, un manque d'inspiration, voire même une flemme au moment d'aborder une rétrospective ? En manque de temps, il faut alors trouver un format relativement simple à animer. Généralement, se tourner vers un classique qui ne nécessite aucune préparation est une bonne alternative. Évidemment, si ce comportement est systématique il y a un souci, mais s'il survient de manière sporadique, la connaissance de ces formats est une excellente solution de secours.

Quand un sprint s'est déroulé sans encombre ou évènement majeur, il peut être difficile de contextualiser la rétrospective. Dans ce genre de situation, si l'équipe arrive toujours à trouver des actions d'amélioration et si elle ne s'est toujours pas lassée de faire des rétrospectives d'un même genre, le déroulement d'un format classique fera parfaitement le travail.

Exemples de formats

Content / Pas Content

Difficile de faire plus simple que ce format qui, de par son côté binaire, ne fera pas griller le cerveau des participants. Son approche est axée sur les émotions et les réduit à leur plus simple nature : content (qu'est-ce qui vous a plu ?) et pas content (qu'est-ce qui vous a déplu ?).

Préparation

# data[].attributes.attachment_link.title
À chaque sprint sa rétrospective : les classiques

# data[].attributes.attachment_link.description
Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Doit-il se tourner vers la simplicité d'un format classique, l'amusement d'un format fun, ou chercher le format qui s'adaptera le mieux au sprint vécu ?

# data[].attributes.attachment_link.readable_text
Il y a 1 année · 12 minutes · Agile

Suite de la série d'articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d'horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Aujourd'hui, parlons de la sprint rétrospective...

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

" Merci Michel pour les croissants ! "

La situation

C'est la deuxième rétrospective de suite qu'au moment de recueillir les données, seulement cinq post-it se battent en duel. De plus ces post-it sont d'une utilité approximative, allant de " Ce soir c'est les vacances ! " à " Merci Michel pour les croissants ce matin ! ".

Pourquoi ça sent mauvais ?

Si la rétrospective ne sert plus qu'à faire de l'humour, c'est que vous vous êtes éloigné de son but initial. Bien que l'humour soit généralement le signe d'une équipe qui s'entende bien, cette situation cache un problème qui peut être :

La routine : l'équipe a déjà effectué des dizaines d'itérations, il se forme une certaine routine accompagnée de lassitude. Les personnes ne font alors plus vraiment d'effort pour essayer de s'améliorer.

Je vais bien, tout va bien : tout va pour le mieux, l'équipe avance sans rencontrer de véritable problème, elle a du mal à trouver des axes d'amélioration. Il est effectivement toujours plus facile de corriger quelque chose qui fonctionne mal plutôt que d'améliorer quelque chose qui fonctionne déjà bien.

Le sentiment d'inutilité : les éléments remontés lors des précédentes rétrospectives n'ont toujours pas été résolus ou améliorés, l'équipe finit par ne plus croire en l'utilité de cette cérémonie.

Alzheimer : un syndrome plutôt répandu chez pas mal de personnes qui ont tendance à oublier ce qu'il s'est passé durant les deux ou trois dernières semaines.

Concrètement on fait quoi ?

La rétrospective est une brique essentiellement de l'amélioration continue de l'équipe. Pour ceux qui souhaitent se rafraîchir les idées sur le déroulement idéal d'une rétrospective, je vous conseille de lire Donnez du peps à vos rétrospectives.

Quelques pistes pour aller plus loin :

Chaque itération est unique, avec son propre lot d'événements. S'il s'est passé beaucoup d'événements durant l'itération ou si au contraire il n'y en a eu qu'un seul mais important, si l'ambiance est au beau fixe ou s'il y a des tensions, il faut savoir adapter le format de la rétrospective pour qu'il soit le plus pertinent possible par rapport au contexte. Pour vous guider dans ce choix, vous pouvez vous référer à la série d'articles " À chaque sprint sa rétrospective " .

Bon nombre d'animateurs se contentent de jouer avec un, voire deux formats simples de rétrospective. Bien que cela suffise au début de la vie du projet, les membres de l'équipe étant tous motivés et ayant des choses évidentes à améliorer, cela peut vite entraîner une certaine lassitude. Au delà du fait de contextualiser chaque rétrospective, il est également important de connaître plusieurs formats répondant à une même situation afin de casser la routine.

Il existe plusieurs rôles plus ou moins utilisés : facilitateur, timekeeper, observateur et pousse décision. Les attribuer en début de rétrospective est un bon moyen de garantir la concentration des personnes durant la cérémonie. Les faire tourner à chaque itération, y compris celui du facilitateur, est également intéressant pour insuffler un renouveau dans votre rétrospective. Attention toutefois avec le facilitateur, tout le monde n'est pas forcément en capacité d'assumer ce rôle.

Certaines personnes ayant régulièrement du mal à se souvenir de ce qui leur est arrivé durant l'itération, il peut être utile de leur présenter le format de rétrospective un ou deux jours avant la rétrospective afin de leur laisser plus de temps pour se remémorer les évènements. Mieux, les accompagner pour leur faire prendre des notes tout au long de l'itération afin de ne pas les oublier le jour j, via l'activité Empty the mailbox par exemple, est la garanti d'avoir du contenu de qualité.

Si la rétrospective devient rébarbative, il faut le demander. Après chaque cérémonie, la faire évaluer et demander comment l'améliorer est le meilleur moyen de répondre, à terme, aux attentes de tout le monde.

" Communiquer mieux "

La situation

Les actions qui sont prises par l'équipe à la fin de la rétrospective sont du type " Communiquer mieux ", " Être plus rigoureux " ou " Faire plus de binômage ".

Pourquoi ça sent mauvais ?

Lorsque des personnes se plaignent de manière récurrente d'une faible qualité de code ou d'une baisse constante de la couverture de code, le réflexe simple est de penser qu'il s'agit d'un soucis de rigueur. Si les gens font attention, il n'y aura plus de soucis et l'action " Être plus rigoureux " sera suffisante puisque tout le monde a hoché la tête fièrement en se disant que c'était évident. Dans la réalité, ces phrases que l'on espère magiques ne règlent absolument rien et vont rendre la rétrospective lassante sur le moyen terme car les mêmes problèmes seront continuellement remontés.

" Communiquer mieux " ou " Être plus rigoureux " ne sont pas des actions mais plutôt des lignes de conduite.

Concrètement on fait quoi ?

En premier lieu, il faut constamment avoir en tête un principe simple souvent appliqué aux actions de rétrospective : elles doivent être SMART. Hormis la partie sur la temporalité, qu'il est préférable de définir au maximum à une itération, ces grands principes sont à garder en tête et doivent servir à valider qu'une action est bel et bien une action. Bien évidemment, s'il ne fallait en garder qu'un, ce serait le fait d'être mesurable : associer des indicateurs à une action est le meilleur moyen de savoir si elle est terminée ou non.

Reprenons les exemples cités précédemment et transformons les en exemples d'actions associées :

Communiquer mieux : organiser un point de synchronisation avec un représentant de chaque équipe tous les mardi et jeudi à 11h afin de partager les informations transverses.

Être plus rigoureux : mettre en place un outil de contrôle de code afin de s'assurer que l'équipe a le même style d'écriture.

Faire plus de binômage : identifier 2 stories durant le sprint planning pour lesquelles l'équipe devra obligatoirement faire du pair programming.

Pour arriver à la génèse d'une action digne de ce nom, il ne faut donc pas s'arrêter à la surface du problème mais investiguer. Si l'on ne devait retenir que deux techniques permettant de le faire, ce pourrait être :

Les cinq pourquoi : Répéter la question " Pourquoi ? " à chaque réponse apportant une raison.

Le QQOQCCP : Définir les " Qui ? ", " Quoi ? ", " Où ? ", " Quand ? ", " Comment ? ", " Combien ? " et " Pourquoi ? ".

" Et cette action ça fait 3 itérations, on la garde ? " - " Oui c'est vraiment bloquant ! "

La situation

Voilà plusieurs itérations qu'une action de rétrospective n'est pas mise en oeuvre. À chaque début de rétrospective, l'équipe décide de garder cette action car le problème sous jacent est considéré comme trop important.

Pourquoi ça sent mauvais ?

De manière évidente, engager des actions qui ne sont pas tenues ne sert pas à grand chose et peut même nuire à l'équipe sur le long terme. Plusieurs raisons peuvent expliquer ce problème :

Action trop grosse : une action engageant un changement radical de processus, la mise en place intégrale d'un outil ou le refactor de toute une batterie de test va à coup sûr être impossible à réaliser au terme d'une seule itération.

Action diluée dans la masse : s'il y a trop d'action à mener, l'équipe risque d'avoir du mal à les mener toutes à bien.

Action non suivie : si les actions ne sont suivies par personne, elles ont vite fait de tomber dans l'oubli car l'équipe sera occupée à traiter d'autres sujets pendant l'itération. Ce n'est que lors de la rétrospective suivante qu'elle se rappellera des actions qu'elle aurait dû mener.

Concrètement on fait quoi ?

L'objectif de la rétrospective est d'aboutir à une liste d'actions qui, une fois réalisées, vont permettre à l'équipe de s'améliorer. Quelques règles simples à appliquer :

Lorsque l'équipe arrive à la conclusion qu'il lui faut créer un outil pour résoudre ses soucis, l'action ne doit pas être de créer l'outil mais plus d'alimenter le backlog avec les stories de cet outil. Créer l'outil idéal ne se fait pas en une itération, créer des stories oui. Le suivi de l'avancement des développements de l'outil ne se fera donc pas via la rétrospective mais via le backlog, comme pour les stories du produit.

Ce même principe peut être appliqué dans le cas de refactor trop important ou de processus. Pour ce dernier, si les tensions remontées se situent avec une autre équipe, changer la manière dont interagissent les deux équipes ensemble ne se fera pas en une itération. L'action pourrait être de monter une réunion avec l'autre équipe. Le suivi du résultat de cette réunion se faisant en dehors de la rétrospective.

Une action doit représenter un moyen d'arriver à un objectif et doit par conséquent être mesurable. Lorsque l'action est définie, elle doit obligatoirement être accompagnée d'une DOD (Definition of Done) qui donne des éléments mesurables permettant de savoir que l'action a été terminée.

Si votre rétrospective aboutie sur trop d'actions, sélectionner en équipe les deux ou trois plus prioritaires. Mieux vaut deux actions terminées que six en cours.

Pour suivre les actions il suffit de deux choses : désigner un responsable, pas forcément celui qui réalisera l'action mais plutôt qui fera en sorte que les gens se mobilisent pour que l'action soit réalisée, et faire en sorte que le tableau de suivi des actions soit visible en daily stand up meeting de manière à suivre leur avancement quotidiennement.

Evitons au passage de tomber dans un autre smell : il ne doit pas y avoir un unique responsable pour toutes les actions (on retrouve souvent le cas du Scrum Master qui gère tout) mais plutôt un responsable différent par action.

Si une action stagne d'itération en itération, il suffit de la supprimer. Le besoin a dû changer, disparaître ou n'est simplement plus vraiment prioritaire sinon l'action aurait été menée. Dans le pire des cas, elle émergera d'une future rétrospective.

" Si l'autre Michel se bougeait un peu, on pourrait peut être y arriver... "

La situation

Lors de la rétrospective, une personne nomme spécifiquement quelqu'un comme étant le responsable de l'échec d'une tâche, d'une itération ou d'une release.

Pourquoi ça sent mauvais ?

Ce qui peut ressortir de cette situation :

Une personne est en conflit avec une autre et l'exprime publiquement

Le conflit étant ouvert sur la place publique, en laissant une telle situation perdurer il y a un risque de contamination sur les autres membres de l'équipe. Des collègues sont forcément pris à partie et doivent se positionner, ce qui va forcément décevoir un des deux protagonistes. La résultante est un climat délétère au sein de l'équipe.

L'équipe a un coupable tout désigné pour chaque problème qu'elle rencontre. Cela cache souvent une incapacité à se remettre en question et une tendance à fuir ses responsabilités.

Certaines personnes ont l'habitude de chercher des coupables au moindre problème

Le problème avec ce genre de situation est qu'elle entraîne une défiance de la part des personnes au moment de participer à la rétrospective. La moindre erreur sera forcément mal vécue par son auteur par peur d'être pris pour cible. Il y aura forcément moins d'initiative et de prise de risque, et plus de stress au sein de l'équipe.

Concrètement on fait quoi ?

Lorsqu'un conflit entre deux personnes éclate publiquement, il est nécessaire de le traiter au plus tôt. La rétrospective n'est pas l'endroit le plus adapté pour cela, il est préférable de passer par un entretien directement avec les personnes concernées pour gérer ce conflit.

Dans tous les cas, introduire chaque rétrospective avec le principe suivant : " Indépendamment de ce que nous allons découvrir aujourd'hui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux, en fonction de ses connaissances, de ses compétences et de ses capacités, des ressources disponibles et de la situation courante. " (Norm Kerth). L'idée derrière cela est d'inciter les gens à émettre des critiques constructives plutôt qu'à blâmer.

Le rôle du facilitateur de la rétrospective devient primordial ici. Au delà d'un simple principe énoncé en début de cérémonie, il doit être réactif dès qu'une accusation est portée :

en demandant de reformuler la critique sans citer explicitement quelqu'un

en essayant de remonter aux origines du problème (via la technique des " cinq pourquoi " par exemple)

en demandant ce que l'équipe (plutôt que la personne accusée) aurait pu faire pour éviter l'erreur

Être attentif à tout signe d'accusation ou de jugement et les traiter, permet d'instaurer des habitudes dans la manière d'aborder la rétrospective pour chaque membre de l'équipe.

Conclusion

Au travers de quatre situations, nous avons découvert comment la rétrospective pouvait révéler des pratiques contre productives, mais également, comment il pouvait être une aide d'une grande efficacité pour améliorer de nombreux aspects de la vie d'une équipe. Ne jetez pas votre désodorisant tout de suite, nous revenons bientôt avec de nouveaux agile smells dédiés cette fois-ci au backlog et user stories.

# data[].attributes.attachment_link.description
Suite de la série d'articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d'horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Aujourd'hui, parlons de la

# data[].attributes.attachment_link.description
Le terme "retrospective" est emprunté directement à l'anglais, on le préfère à "debriefing" ou "post-mortem" pour ses connotations plus neutres. On parle également de "heartbeat retrospectives" pour insister sur le fait que leur régularité contribue à donner au projet une cadence (le sens littéral est "battement de coeur").

# data[].attributes.headline
SCRUML’archétype de la méthode de gestion de projet agile.

# data[].attributes.subject
SCRUML’archétype de la méthode de gestion de projet agile.

# data[].attributes.headline
Activities and ideas for making agile retrospectives more engaging

# data[].attributes.subject
Activities and ideas for making agile retrospectives more engaging

# data[].attributes.attachment_link.title
FunRetrospectives | Have fun, learn from the past and prepare for the future!

# data[].attributes.attachment_link.description
Have fun, learn from the past and prepare for the future!

# data[].attributes.attachment_link.readable_text
La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: " À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ". Ritualiser cet événement permet de mettre en place un processus d' amélioration continue. Même si parfois, l'équipe a l'impression qu'il ne s'est rien passé, il s'est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d'itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d'itérations et présentera 2 outils simples, le Keep Drop Start et la note d'itération.

Pour une rétrospective d'une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d'une semaine, 1h.

Keep Drop Start

L'outil le plus simple utilisé pour une rétrospective d'itération est le Keep Drop Start:

Couramment, chaque participant est invité à noter en gros et majuscule sur des post-it les choses qui lui viennent sans se brider pour chaque partie:

Ce qui fonctionne bien, ce qu'il faut garder (Keep)

Ce qui fonctionne moins bien, ce qu'il faut supprimer (Drop)

Ce qui reste mystérieux

Ce qui fonctionnerait bien si..., ce qu'il faudrait faire (Start)

Conseil d'animation:

Si vous sentez le groupe bloqué, vous avez toujours une personne qui a plus d'idées que les autres, demandez lui de dire à voix haute quelques-unes de ces idées et d'aller les afficher

Si personne n'a d'idées, guider les participants sur des thématiques: " réfléchissez à l'estimation, les réunions, le code, à ce qui pourrait-être améliorer ? " et tant qu'à faire sur ce que vous avez observé vous-même pendant l'itération

L'important dans l'animation de la rétrospective est que l'équipe prenne conscience par elle-même de ses points de blocages

Je vous conseille de finir par un vote collectif (vote par bâton ou gommette) sur les 5 grandes idées / actions pour l'itération car cela permet de mobiliser l'équipe et il est irréaliste de croire qu'une équipe puisse faire plus de 5 actions d'amélioration en 2 semaines, au moins au début

Au bout d'un moment (3/5 itérations), vous pouvez inviter un membre de l'équipe à l'animer à votre place pour favoriser la prise d'initiative et dans l'idéal l'animateur tourne

Pièges à éviter:

En tant qu'animateur de la réunion, vous voulez que l'équipe sorte absolument avec un plan d'actions, vous voulez alors à la place de l'équipe et donc vous la déresponsabiliser. Parfois la prise de conscience suffit à ce que les choses ne se reproduisent pas

La note d'itération

La note d'itération peut aussi être utilisée si vous avez moins de temps et pour changer. Changer d'outil peut être stratégique car il peut permettre de sortir des habitudes prises par l'équipe.

Pour la note d'itération, vous pouvez utiliser ce processus inspiré de l' approche orientée vers les solutions:

Demandez à chacun de positionner son niveau de satisfaction de l'itération sur une échelle de 1 à 7

A partir du niveau estimé (Ex: 4), posez la question: " Qu'est ce qui fait que tu as mis 4 ? "

Puis posez la question: " Qu'est ce qu'il faudrait pour avoir seulement 5 (4+1) ? "

Conseil d'animation:

Commencez par les plus discrets et silencieux car ils ont souvent une bonne perception de la situation mais ils n'ont pas souvent la parole et ne la prennent pas

Déléguez l'écriture sur le tableau blanc à un membre de l'équipe

Comme vous êtes dans une approche circulaire, au bout de la 3ème ou 4 ème personne, les idées commencent à devenir identiques, vous pouvez alors inviter les prochains à annoncer ce qui est différent de ce qui a déjà été dit

Pièges à éviter:

Discuter/Contredire ce que dit un participant, ceci aurait pour effet de brider ce que pourrait dire la personne

De rétrospectives en rétrospectives

Je constate souvent que les équipes agiles oublient ce qui s'est passé dans les rétrospectives précédentes, une sorte de perte de mémoire qui fait que rien ne se passe hormis le fait que tout reste pareil. La rétrospective est alors une sorte de bureau des plaintes où chacun exprime ses peurs, ses reproches, pour que tout fonctionne comme avant. Sommes-nous dans une approche d'amélioration continue ? pas si sûr.

En tant qu'animateur, que faire avec ça ?

Attendre. Pas d'actions, pas de réactions dans une rétrospective, ce n'est pas si grave quand cela arrive 1 ou 2 fois. Laisser l'équipe dans son jus a du bon pour la responsabiliser

Demander au groupe quelles sont les actions qui avaient été décidées la dernière fois

Se focaliser sur une action et aller chercher chaque étape en détail

Faire un atelier pour sortir l'équipe du rituel rétrospective et faire un travail de fond

Questionner le groupe sur les avantages pour lui de faire une rétrospective ou mieux avec une approche paradoxale: quels seraient les bénéfices de ne plus faire de rétrospective ?

Provoquer le groupe: " Je pense qu'il est temps d'arrêter de faire des rétrospectives " accompagné d'un silence en espérant une réaction et qu'un leader va émergé... c'est un peu du quitte ou double

Il est courant de croire que la rétrospective est le seul moment où l'on puisse faire de l'amélioration continue. Dans la réalité, il est possible d'introduire des feedbacks de 10 minutes en fin de chaque réunion pour habituer l'équipe à se responsabiliser sur son fonctionnement.

L'amélioration continue est une approche de petits pas qui visent à ancrer un niveau supérieur dans une roue dentée. Il est clair que parfois cela ne suffit pas, même pire cela renforce le non changement d'une équipe, il faut alors envisager d'autres façons de faire, en rupture, qui demandent beaucoup plus de doigté car déstabilisantes pour une équipe.

# data[].attributes.attachment_link.description
La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: " À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ".

# data[].attributes.headline
La rétrospective dont vous êtes le héros

# data[].attributes.subject
La rétrospective dont vous êtes le héros

# data[].attributes.attachment_link.readable_text
Votre équipe agile commence à se lasser des rétrospectives ? Elle les trouve répétitives et ennuyeuses ? Nous avons créé un jeu pour vous !

Il rend les rétrospectives plus ludiques, plus personnelles et plus puissantes en suivant les étapes introduites par le livre Agile retrospectives d'Esther Derby :

Tout en restant dans ce cadre efficace, nous proposons un univers décalé et ouvert, permettant de varier les plaisirs et d'évoluer au fil des rétrospectives avec la vie de l'équipe.

Set the stage
Votre équipe se retrouve projetée dans un univers post-apocalyptique peuplé de zombies. Votre but est de survivre... ensemble. Vous vous retrouvez au calme dans un bureau après avoir vaillamment survécu durant l'itération... - Quel est votre niveau d'énergie en cette fin d'itération ? Prenez votre avatar et indiquez votre niveau de vie ! Le but de l'équipe est de revenir à un niveau de vie supérieur à 5... Nous allons partir en exploration pour ça !
Gather data
Vous pénétrez alors dans...
- Dans l'infirmerie, vous trouvez une trousse de soin. Quel était le " kit medical " qui vous a aidé dans l'itération ?
- Vous voyez également une bouteille de poison. Quel était le poison qui vous a fait souffrir pendant l'itération ?
- Un téléphone est posé là. S'il fonctionne, qui appelez-vous ? Pour demander quoi ?
- Enfin, au fond de la salle, un corps... Est-ce un zombie ? Peut-être va-il se lever ! Quel risque identifiez-vous pour les prochaines itérations ?

L'équipe réfléchit... et raconte l'histoire !

Generate insights
Vous vous déplacez dans la salle suivante... La bibliothèque ! - Sélectionnez les sujets que vous souhaitez creuser et sur lesquels vous voulez agir. Dans quels rayons de la bibliothèque iriez-vous chercher de l'information ? Technique ? Processus ? Communication ? Divers ?
L'équipe positionne les tickets importants, pose des questions, précise les problèmes...Un grand bruit se fait entendre dans le couloir ! Vous sortez en courant de la bibliothèque !

Decide what to do
Des zombies cherchent à passer à travers une barricade de fortune ! Vous devez la consolider !
- Choisissez les actions d'amélioration (quoi, qui, quand) que vous souhaitez réaliser et posez-les sur la barricade !
- Les actions de l'itération précédente ont-elles fonctionné ?
- La barricade est-elle suffisamment solide pour tenir une itération ? Que manque-t-il selon vous ?
Le board d'amélioration continue de l'équipe peut alors être mis à jour.

Close the retrospective
La rétrospective se termine, comment vous sentez-vous ? Est-ce que votre niveau de vie a évolué ? Vous pouvez positionner votre avatar en fonction du changement vécu. Pour poursuivre l'aventure, votre équipe a besoin d'encouragements. Dites chacun une chose positive à propos de l'équipier de votre choix.
Nous avons déjà expérimenté ce jeu plusieurs fois et rencontré un franc succès - un grand merci à notre client Meetic pour nous avoir permis de tester ce concept avec ses équipes ! Aujourd'hui, nous travaillons à l'élaboration de nouvelles salles afin d'offrir différents scénarios selon les besoins des groupes...

Vous avez envie de jouer mais vous ne savez pas dessiner ? Faites-le nous savoir ! Nous avons l'intention de publier le kit du jeu avec ses posters en version 2.0, et vos encouragements sont pour nous une vraie source de motivation ! Stay tuned...

Edit : Le temps a fait son office et vous livre le résultat de son travail ! Voici les 3 posters principaux du jeu imprimables au format A3. Un grand merci à Renaud Castaing pour leur réalisation ! Nous laissons vos talents artistiques s'exercer pour créer votre poster de niveau de vie...

( cliquez pour télécharger les posters)

# data[].attributes.attachment_link.title
La rétrospective dont vous êtes le héros

# data[].attributes.attachment_link.description
Votre équipe agile commence à se lasser des rétrospectives ? Elle les trouve répétitives et ennuyeuses ? Nous avons créé un jeu pour vous !

# data[].attributes.body
Déscription d'un certain nombre d’exercices peu connus

# data[].attributes.attachment_link.title
Retrospective Plans - Agile Retrospective Resource Wiki

# data[].attributes.attachment_link.description
A collection of detailed retrospective plans you can run or take inspiration from. If you've been in or ran a retrospective you really liked please add it.

# data[].attributes.attachment_link.readable_text
Une note à nos lecteurs : Suite à vos retours, nous avons développé un ensemble de fonctionnalités qui vous permettent de réduire le bruit, tout en ne perdant pas de vue ce qui est important. Recevez des notifications en ligne et par e-mail en choisissant les sujets qui vous intéressent.

Les rétrospectives et les "feedback loops" sont au cœur de chaque implémentation Agile/Scrum. Conçus comme des outils pour aider les équipes à se perfectionner, ils sont pourtant oubliés la plupart des fois lors des formations d'introduction à l'agilité. La raison ? Sur deux jours, les formateurs (l'auteur de cet article inclus) n'ont pas assez de temps pour couvrir l'intégralité du sujet et se limitent à décrire une forme simple de rétrospective. Conséquence : une seule approche rend les rétrospectives ennuyeuses et avec le temps personne n'y voit plus d'intérêt.

Brian Lawrence décrit un format de rétrospective rassurant qui marche bien avec un groupe nombreux qui n'a pas encore l'habitude de travailler ensemble. Il distribue des fiches 3''x5'' ou des post-it de couleurs différentes pour chacune des catégories abordées. Il laisse au groupe 20 minutes pour indiquer les points positifs, puis 20 minutes pour dire ce qu'il faut changer. Le facilitateur colle sur le mur les fiches groupées par thème. Enfin l'équipe utilise le temps qui lui reste pour décider des actions à mener.

Jimmy Bosse affirme que les rétrospectives sont toujours importantes et quoi qu'il arrive on ne peut pas s'en passer. Il explique qu'elles donnent à l'équipe les moyens de changer et de progresser. En leur absence, les difficultés et les bugs deviennent des outils d'accusation et de critique alors qu'ils pourraient servir à réfléchir aux axes d'amélioration.

Yves Hanoulle réplique :

A mon avis dire qu'il ne faut "JAMAIS arrêter les rétrospectives" est une erreur. Jamais et toujours ne sont pas des mots agiles. Ne les utilisez jamais ;-) Par contre, si une équipe décide d'arrêter les rétrospectives il est nécessaire d'en analyser les causes. Il faut déchiffrer qu'est-ce qui se cache derrière cette décision.

On a demandé à Doug Shimp si les commentaires issus des rétrospectives devaient être affichés publiquement. Sa réponse : plutôt que de publier les notes de l'équipe, il vaut mieux publier les objectifs et les enseignements acquis. Et encore faut-il le faire avec précaution puisque certaines améliorations, sorties de leur contexte, peuvent se transformer en soucis pour les RH.

Jason Little a pensé à aménager une salle dédiée aux rétrospectives où afficher les recommandations pour aider l'équipe quand le coach est absent. Il inclut :
- Une grande salle, agréable, avec assez d'espace ;
- Un coin avec des rappels sur : " la valeur des rétrospectives, le format standard pour les réunions et une checklist à vérifier avant de commencer la rétrospective " ;
- Un panier avec le nécessaire pour un coach agile : post-it, marqueurs et documentation de techniques diverses. C'est ce qu'il appelle le "toolkit de la rétrospective".

L'agenda type de Jason:

1. Décider quel sera le sujet de la réunion.

2. Exposer l'agenda et inviter à faire des commentaires.

3. Brain-storming sur ce qui a bien fonctionné et ce qui n'a pas marché.

4. Brain-storming pour décider sur les activités à démarrer et sur celles à arrêter.

5. Créer un plan d'action.

6. Remplir l'espace dédié aux post-it bien/mal.

Le Agile Retrospective Wiki décrit un certain nombre d'exercices peu connus :

Christopher Avery a dit au sujet des bénéfices des Rétrospectives :

1. La Rétrospective est l'occasion pour un groupe de se comporter comme une équipe, en écoutant tout le monde, en intégrant les différentes perspectives et en parvenant à un consensus sur la façon de gérer la prochaine itération.

2. " Clore les sujets : c'est difficile de démarrer quelque chose si des sujets restent encore mentalement ou émotionnellement suspendus ".

Ce journaliste a écrit un guide de base pour mener des bonnes rétrospectives : "Je commence par souligner les faits positifs de l'itération précédente (valorisation de ce qui s'est bien passé) avant de réfléchir à ce qui pourrait mieux se passer. Ainsi le moral de l'équipe remonte et tout le monde est bien disposé pour discuter de problèmes difficiles. En plus je suis convaincu qu'il est essentiel de définir des objectifs simples (SMART) pour l'itération suivante et les afficher dans l'open space. Dans le cas contraire les objectifs risquent de ne pas être atteints et l'équipe perdra l'intérêt face aux rétrospectives étant donné qu'elles n'améliorent rien.

Sur le blog ScrumDesk on discute de l'utilisation du Speed Boat Innovation Game:

Pour commencer il faut dessiner un bateau avec deux ancres et deux moteurs. Le nom du bateau doit correspondre au thème qu'on veut examiner (en particulier si le nombre de points à traiter est grand). Le principe du jeu est celui de demander aux membres de l'équipe de faire une liste de ce qui le projet et de coller les post-it correspondants à l'ancre. Laissez-les donc écrire des idées qui pourraient accélérer le bateau et coller les post-it à un moteur. A ce stade vous pouvez grouper, mettre en séquence et/ou voter les différents points comme dans une rétrospective agile/scrum. Nous avons créé deux bateaux au cours de notre session. Les personnes ont pu exprimer un grand nombre d'idées et proposer librement des solutions qui ont été transformées immédiatement en points d'action pour les directeurs.

Enfin Matthew Bussa fourni les astuces suivantes:

Ne soyez pas débordés ! Au début les rétrospectives vont durer plus que prévu mais elles deviendront de plus en plus courtes avec le temps.

Faites en sorte que ce soit un moment où les membres de la team peuvent exprimer librement leurs inquiétudes et leurs propositions d'amélioration mais évitez de parler uniquement des points négatifs. Parlez également de ce qui a bien marché et de comment continuer.

Actions à mener: elles sont importantes et témoigneront de l'efficacité des rétrospectives. Proposez des points d'action mesurables, assignez-les à une personne, et, très important, faites le suivi à la prochaine rétrospective. Si les points sont sous le contrôle de la team, faites le possible pour les compléter au plus tôt.

Limitez vos points d'action à 3-5 points, prenez ceux à haute priorité. C'est plus facile de se rappeler de 3 ou 5 points que de 20. Et d'ailleurs il est plus probable qu'ils soient complétés.

Renouvelez vos rétrospectives ! Cela aidera à maintenir la fraîcheur des réunions et à éviter que les personnes s'habituent. Consultez le livre Agile Retrospectives Making Good Teams Great.

Souvenez-vous de borner les activités autant que possible à l'aide d'une boîte de temps pour respecter les agendas des membres de l'équipe.

# data[].attributes.attachment_link.title
Rétrospectives Agiles/Scrum - Trucs et astuces

# data[].attributes.attachment_link.description
Une note à nos lecteurs : Suite à vos retours, nous avons développé un ensemble de fonctionnalités qui vous permettent de réduire le bruit, tout en ne perdant pas de vue ce qui est important. Recevez des notifications en ligne et par e-mail en choisissant les sujets qui vous intéressent.

# data[].attributes.attachment_link.title
Méthode pour organiser vos rétrospectives Agile | Le Playbook des équipes Atlassian

# data[].attributes.attachment_link.description
Instructions et variantes de la rétrospective classique en équipe. Populaire parmi les développeurs Agile, mais ne se limite plus seulement aux équipes de développement.

# data[].attributes.headline
[Rétrospective] Agilex : Agilité et Expertise

# data[].attributes.subject
[Rétrospective] Agilex : Agilité et Expertise

# data[].attributes.attachment_link.readable_text
Voici les slides de ma toute dernière session présentée à Agile Grenoble 2016 ... et pour la vidéo, c'est sur la chaîne Youtube Agile Grenoble L'art de la rétrospective from Alexandre Boutin

# data[].attributes.attachment_link.title
Résultats de recherche pour : retrospective

# data[].attributes.attachment_link.description
Voici les slides de ma toute dernière session présentée à Agile Grenoble 2016 ... et pour la vidéo, c'est sur la chaîne Youtube Agile Grenoble L'art de la rétrospective from Alexandre Boutin

# data[].attributes.headline
[Book, Paper] Project Retrospectives: A Handbook for Team Reviews

# data[].attributes.subject
[Book, Paper] Project Retrospectives: A Handbook for Team Reviews

# data[].attributes.attachment_link.keywords[]
project retrospectives: a handbook for team reviews

# data[].attributes.attachment_link.keywords[]
business & economics / production & operations management

# data[].attributes.attachment_link.title
Project Retrospectives: A Handbook for Team Reviews

# data[].attributes.attachment_link.description
Project Retrospectives Kerth, a consultant to software organizations, guides facilitators and participants through the process of the project retrospective using scenarios and detailed, cartoon-illustrated instructions. The retrospective is a formal method for preserving the lessons learned from ...

# data[].attributes.attachment_link.description
La rétrospective est un éléments primordial en Agilité. Ce blog a pour objectif de donner aux rétrospectives agiles toute la place qu'elles méritent dans Scrum

# data[].attributes.headline
Rétrospective Agile: Mes exercices favoris

# data[].attributes.subject
Rétrospective Agile: Mes exercices favoris

# data[].attributes.attachment_link.readable_text
Les rétrospectives sont des moments clés dans la vie d'une Equipe et d'un projet... Voici pour vous qui êtes amenés à les animer fréquemment, les exercices de base sur lesquelles je m'appuie!

Evidemment tout commence par le Postulat de la Rétrospective (en Ouverture) et par un Plan d'action en fin de retro:

Pour le reste voici quelques petites techniques qui ont fait leur preuve!

Le Checkin

Une seule question en ouverture pour briser la glace, libérer la parole et prendre connaissance de l'état de l'autre!

Et vous, comment vous-sentez-vous aujourd'hui ?

Note: On l'oublie trop souvent. Petit tour rapide; 1 ou 2 mots par personne

La retro Chapeaux (inspirée de De Bono)

L'idée de base de la méthode est d'obtenir une réflexion plus efficace et directe en évitant de mélanger les éléments de pensée de nature différente: pensée positive, négative, émotions, logique, critique, créativité... on se focalise sur un seul canal à la fois, on ne se disperse pas !

Voici une séquence que j'aime bien:

Chapeau bleu (organisation & canalisation du groupe). Rappel des objectifs de la rétrospective de projet puis tour de table des objectifs personnels de chaque participant.

Chapeau blanc (neutralité & faits). Ils sont présentés sur 1 poster

Chapeau Jaune (critique positive): Individuellement ou en binôme, l'idée est de se focaliser 10 minutes sur les éléments positifs du projet. Ils sont présentés et listés sans critique sur poster.

Chapeau Noir (critique négative). Individuellement ou en binôme, l'idée est cette fois-ci de se focaliser 10 minutes sur ce qui n'a pas marché, les problémes, les conséquences néfastes. Les éléments sont présentés et listés sur poster.

Chapeau Vert (créativité, idées & axes d'amélioration). Sur 1 poster aussi

Chapeau Rouge (émotions & ressenti). Chacun exprime son ressenti par rapport au projet et aux mois qu'ils ont passé ensemble. On entre délibérément sur le volet émotionnel

Chapeau Bleu (bis) (Organisation): On termine la rétrospective sur un plan d'actions (Quoi / Qui / Quand) ou une liste " Next Steps " sur lesquels le Groupe s'engage et par un ROTI évidemment

Note: Mettre en oeuvre la rétro " chapeaux " c'est radicalement changer le format d'animation. Plutôt intéressant pour ne pas tomber dans la routine.

Vie mon... Manifesto

Les valeurs, on y revient toujours... L'idée de cet exercice est de connecter l' "Etre agile " du " Faire de l'agile" .

Temps 1 : Demander à l'un des membres de l'équipe de lire le Manifesto affiché

Temps 2: Pour chaque valeur, je demande à chaque membre de l'équipe de me citer 1 exemple, 1 expérience qui incarne la valeur dans son quotidien au cours du dernier sprint...

Note: J'aime bien cet exercice. Il permet de nous reconnecter en douceur aux valeurs agiles et de donner du sens à certaines de nos actions

Le RADAR de valeurs Scrum

Dans la lignée du précédent... mais cette fois sur les valeurs Scrum par exemple:
Focus - Courage - Engagement - Respect - Ouverture

Temps 1: Présenter le poster et les valeurs qui doivent nous guider (et notamment ce qu'il y a derrière)

Temps 2: Demander aux participants de donner une note (de 0 à 10; pas du tout performant; totalement performant sur les 5 valeurs) Soit au tableau; Soit tour de table

Temps 3: Discuter de l'importance de ces éléments

Temps 4: Faire la moyenne par Axe et établir le RADAR de valeurs Scrum

Note: là aussi j'affectionne cet exercice que je construisais il y a quelques années autour des valeurs XP. En outre, dans une logique " Solution Focus ", il permet d'envisager le petit pas qui permettra de faire + 1 au sprint suivant

style="display:block; text-align:center;"
data-ad-layout="in-article"
data-ad-format="fluid"
data-ad-client="ca-pub-8663000683831093"
data-ad-slot="1730535215">

Le quadrant de Retrospective

Mon essentiel... Trés facile à mettre en oeuvre, pour toute taille d'équipe.

Découper l'espace en 4 zones:

Ce qui a marché

Ce qui doit être améliorer

Les Merci!

Les bonnes idées

Note: Alterner le travail individuel, de groupe et le pitch, ainsi qu'une logique divergence/convergence.

La fleur de Lotus

Utile en cours de Retro quand il s'agit d'explorer un problème.

Temps 1: Inscrivez le Problème central au cœur du Lotus (en l'occurrence pour nous , " comment améliorer notre satisfaction de travailler ensemble ? ")

Temps 2: Ensemble générez les 8 pétales (sous-themes, composantes...) liés au thème ou problème initial (5 à 10 minutes)

Temps 3: Par groupe de 3 (ou ensemble si petit groupe), travaillez un nouveau lotus à partir des pétales (pétales prioritaires ou tous)

Temps 4: Présentez et enrichissez...

Note: Avec des cartes hexagonales, c'est plutôt pas mal!

La Retro Appréciative

L'idée est de travailler avec les équipes uniquement sur leurs expériences avec un questionnement poussé mais exclusivement " postif "

Qu'est-ce qui dans ce sprint vous a permis de croître et de vous développer?

Qu'est-ce qui vous a donné et vous donne aujourd'hui de l'énergie?

A qui souhaitez vous donner une appréciation ?

Quels sont vos 3 souhaits pour la suite?

Note : rechercher ce qui fonctionne, à s'appuyer sur les accomplissements et les éléments positifs pour avancer, transformer ou accompagner le changement. Se dire Merci... là aussi ça fait du bien parfois!

La Timeline

Revisitez- le temps, période par période en revenant sur les dates clés, faits neutres et événements, ce qui s'est bien passé et devrait être amélioré... (plutôt adapté pour des rétro projet ou sprints longs).

Note: Il vous faut un long mur et " timeboxer " précisément l'enchaînement des activités

Le + / Delta

Collecter dans la colonne de gauche ce qui s'est bien passé et dans la colonne de droite ce qui devrait être changé!

Note: Orienté amélioration continue, simple et efficace si vous ne disposez que de très peu de temps !

La meilleure Equipe de la planète

Activité qui permet de mesurer la satisfaction de l'équipe sur sa façon de travailler ensemble. Cela donne un indicateur trés simple qu'on peut suivre sur quelques sprints dans un souci d'amélioration

Note: Intéressant sur quelques sprints; prise de connaissance ensemble de l'echelle puis vote sur post it

Tourne les Cartes...

L'idée ici est de favoriser les échanges entre les participants , et de les amener à se mettre dans les baskets de l'autre. Il offre aussi un regard croisé sur les situations vécues...

Temps 1: Demander à chaque participant de réfléchir à deux éléments positifs et deux éléments négatifs vécus sur le sprint

Temps 2: Demander à chaque participant de donner ses 2 cartes Positives à son voisin de gauche, et ses 2 cartes négatives à son voisin de droite

Temps 3: Chaque participant lit les cartes qu'il a en main

Temps 4: Chaque participant est invité à trouver une action pouvant amener à résoudre les deux points à améliorer

Note: Là encore on sort de la routine. J'aime bien la lecture des cartes par le camarade d'à coté. Le regard croisé en terme d'actions est également intéressant.

Le " Start / Stop / Continue "

3 colonnes pour noter les activités que l'équipe souhaite engager, ce qu'elle souhaite arrêter et ce qu'elle souhaite continuer.

Note: Simple, efficace, orienté action, apprentissage et amélioration continue. Un MUST !

Le Starfish... un Start / Stop / Continue " étendu "

L'idée est d'enrichir le tableau précédent avec deux zones supplémentaires:

Les activités qu'on devrait faire moins

Les activités qu'on devrait faire davantage

Pour le reste c'est la même chose: Arrêter les activités non sources de valeur pour l'Equipe ou le Client, garder ce qui marche bien, démarrer de nouvelles initiatives !

Note: Un exercice de base.... que je vous invite à utiliser de temps en temps!

Le Speed Boat

L'idée est d'utiliser la métaphore du bateau pour le travail de rétrospective : le bateau représentant notre système, notre produit, notre projet ou notre équipe. Les ancres constituent les freins qui empêchent notre bateau d'avancer, qui le ralentissent ou les choses que nos clients ou utilisateurs n'aiment pas dans notre produit et nuisent à son fonctionnement optimal. Plus elles sont positionnées en bas, plus elles sont fortes. Les flèches vertes représentent les éléments qui le poussent et le font avancer.

Temps 1: Travailler en binôme ou groupes de 3 ce qui pousse le bateau, les +

Temps 2: Caractériser et de travailler les ancres (freins, contraintes, choses qui plaisent pas) individuellement ou en groupe puis tous ensemble d'aller les poser sur le poster

Temps 3: Consolider collectivement les ancres puis à les prioriser.

Temps 4: Établir pour chaque ancre majeure un plan d'action pour la faire sauter!

En quoi puis-je vous aider?

Je m'appelle Jean Claude GROSJEAN. J'accompagne les personnes, les équipes, les organisations dans leur projet de transformation. Si l'art de la facilitation vous questionne, si vous souhaitez être accompagné pour l'animation d'une ou plusieurs introspectives n'hésitez pas à me contacter, je peux vous accompagner...

Follow Me:

# data[].attributes.attachment_link.title
Rétrospective Agile: Mes exercices favoris - QualityStreet - Blog Agile depuis 2007

# data[].attributes.attachment_link.description
Les rétrospectives sont des moments clés dans la vie d'une Equipe et d'un projet... Voici pour vous qui êtes amenés à les animer fréquemment, les exercices de base sur lesquelles je m'appuie! Evidemment tout commence par le Postulat de la Rétrospective (en Ouverture) et par un Plan d'action en fin de retro: Pour...

# data[].attributes.headline
Améliorer la motivation – Une idée de rétrospective

# data[].attributes.subject
Améliorer la motivation – Une idée de rétrospective

# data[].attributes.attachment_link.readable_text
Il y a 7 années · 6 minutes · Agile

Comme l'explique Daniel Pink dans son excellent livre La vérité sur ce qui nous motive, ce qui fait que nous sommes impliqués dans notre entreprise, dans notre travail, ne dépend pas principalement de récompenses financières.

D'après lui, les trois véritables facteurs qui ont un réel impact sur la motivation sont :

L'autonomie

Notre " paramétrage par défaut ", c'est l'autonomie et l'indépendance. Malheureusement, les circonstances -entre autres des notions périmées de management- concourent souvent à changer ce paramétrage et à faire baisser notre motivation intrinsèque. Pour favoriser la motivation intrinsèque et les bonnes performances qu'elle permet de réaliser, la première condition est l'autonomie. Les entreprises qui permettent à leurs salariés d'être autonomes, parfois de façon radicale, sont plus performantes que leurs concurrents.

La maîtrise

La maîtrise obéit à trois règles particulières :

C'est un état d'esprit : elle requiert la capacité d'envisager ses propres possibilités comme étant non pas finies mais infiniment améliorables.

La maîtrise suppose des efforts, des difficultés et une pratique délibérée.

La maîtrise est impossible à atteindre entièrement, si bien qu'elle comporte à la fois un coté frustrant et un côté attirant.

La finalité

Il est dans la nature humaine de rechercher la finalité, c'est-à-dire de trouver un sens à ce que l'on fait, un but qui dépasse notre propre condition. Or les entreprises ont longtemps considéré la finalité comme accessoire, comme un élément souhaitable tant qu'il n'interfère pas avec les choses importantes. Cette situation est en train de changer, en partie grâce au vieillissement des baby-boomers qui se retrouvent confrontés à leur condition de mortel. Dans les organisations, ce nouveau " motif de finalité " s'exprime de trois manières : sous forme d'objectifs de finalité dans lesquels le profit est un moyen, sous forme d'un discours qui met l'accent sur autre chose que l'intérêt personnel, et sous forme de mesures pour permettre aux salariés de trouver par eux-mêmes du sens à ce qu'ils font.

Inspiré par la lecture de ce livre, je vous propose d'adapter l'activité classique de rétrospective, XP Radar, au thème de la motivation.

Déroulement de l'activité

L'activité va permettre à chaque membre de l'équipe de déterminer son positionnement sur chacun des trois points, vus ci-dessus, et ainsi de trouver des axes d'actions pour améliorer la motivation de l'équipe.
Autonomie
Chaque membre de l'équipe répond à chacune de ces questions en attribuant de 0 à 10 points par question (10 étant une réponse optimale) :
Maîtrise

Êtes-vous autonome dans vos tâches, dans vos principales attributions et dans la façon dont vous occupez votre journée de travail ?

Êtes-vous autonome dans votre emploi du temps, concernant vos heures d'arrivée et de départ et de la façon dont vous occupez vos heures de travail ?

Êtes-vous autonome par rapport à la composition de votre équipe au travail, c'est-à-dire dans le choix de vos collaborateurs ?

Êtes-vous autonome dans votre technique, c'est-à-dire dans la façon dont vous assumez réellement vos principales responsabilités au travail ?

Finalité

Avez-vous la maîtrise de votre langage de programmation et des frameworks que vous utilisez ?

Avez-vous la maîtrise des techniques de développement : tests, refactor, design, ... ?

Avez-vous la maîtrise des différents outils liés au développement : IDE, gestionnaire de sources, build, serveur d'application, serveur d'intégration continu, release, déploiement, ... ?

Avez-vous la maîtrise du domaine fonctionnel du projet, c'est-à-dire parlez-vous la même langue que votre Product Owner, vos utilisateurs ?

Cette liste n'est en aucun cas exhaustive et devra être adaptée au contexte.

Comprenez-vous très bien le but des user-story du sprint précédent, c'est-à-dire le pourquoi et non pas le comment ?

Comprenez-vous le but du projet ?

Comprenez-vous le but de votre entreprise ?

Résultat

A partir des moyennes de chaque membre, on peut ainsi tracer un radar pour chaque personne, puis un radar global pour l'équipe. Voilà ce que l'on peut obtenir :

Ce radar permet ainsi de facilement identifier les axes sur lesquels l'équipe va essayer d'intervenir pour accroitre la motivation et par conséquence sa productivité. Il est aussi intéressant de regarder individuellement les résultats afin de trouver des raisons de blocages plus individuelles.
Le plus important, comme dans toute rétrospective, est de déterminer un ensemble d'actions suite à l'analyse des résultats. En fonction des axes faibles identifiés, l'équipe sera amenée à définir une ou plusieurs idées d'amélioration. On pourrait ainsi définir :

Organiser des formations interne à l'équipe autour d'un sujet.

Passer une journée avec les utilisateurs pour mieux comprendre leur métier.

Travailler le sens des user-story avec le Product Owner.

Laisser plus de liberté à chaque membre dans le choix de ses tâches.

Ne plus cloisonner les tâches en fonction des compétences spécifiques à chacun.

Faire remonter au management les besoins d'autonomie de l'équipe.

etc.

A noter, cette exercice sera plus efficace s'il est réalisé en compagnie de personnes du management afin de partager les différents points de vue, de discuter et de les sensibiliser directement.

Aller plus loin

Que l'on ne se méprenne pas, l'argent est, bien entendu, une condition nécessaire à la réalisation de notre travail. Nous ne travaillons pas par pure générosité, et insuffisamment rémunéré (en comparaison des salaires à l'intérieur et à l'extérieur de l'entreprise), nous sommes en général très vite démotivés.

Cependant, d'après les études, pour tous les travaux nécessitant de la réflexion, de la créativité, la carotte financière peut être négative plus que stimulante. En effet, elle aura tendance à tuer la créativité car elle pollue l'esprit de celui auquel elle est destinée. De plus, elle aura aussi pour effet de limiter cette créativité car elle arrive généralement avec un cadre correspondant aux critères de satisfaction du généreux donateur de la carotte.

Afin de creuser le sujet de la motivation, je vous conseille la lecture du livre de Daniel Pink, ou sinon le visionnage de la très bonne conférence donnée à TED.

André Comte-Sponville a également donné une conférence passionnante à l'université du SI intitulé : Sens du Travail, bonheur et motivation. Je vous encourage vivement à la regarder.

# data[].attributes.attachment_link.title
Améliorer la motivation - Une idée de rétrospective

# data[].attributes.attachment_link.description
Comme l'explique Daniel Pink dans son excellent livre La vérité sur ce qui nous motive, ce qui fait que nous sommes impliqués dans notre entreprise, dans notre travail, ne dépend pas principalement de récompenses financières.

# data[].attributes.headline
La rétrospective : le format Speed Boat 

# data[].attributes.subject
La rétrospective : le format Speed Boat 

# data[].attributes.attachment_link.readable_text
La rétrospective, un petit rappel

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

La rétrospective est l'un des moments clefs pour une équipe Scrum, c'est un moment dédié à l'amélioration continue, c'est une des boucles de feedback essentielles pour pouvoir être agile.

Cette cérémonie a lieu à la fin de l'itération, juste après la revue de sprint. Elle dure généralement entre 1 et 2 heures et elle est facilitée par le Scrum Master.

Toute l'équipe Scrum participe à la réunion, c'est-à-dire l'équipe de développement, le Scrum Master et le Product Owner.

Il se peut que d'autres observateurs participent à la rétrospective et il faut bien faire attention à ce que la présence de certaines personnes n'empêche pas de créer le climat de confiance nécessaire à la bonne réussite de la rétrospective.

La rétrospective consiste classiquement à regarder ce qui s'est passé durant l'itération ("inspect"), d'en faire émerger des points d'amélioration puis d'en dériver une liste d'actions à prendre ("adapt").

Ces actions doivent impérativement être "actionnables" par l'équipe elle-même, c'est-à-dire que l'équipe doit être à même de les réaliser, et ce dès le prochain sprint.

Tout ce qui serait remonté d'important, mais hors du périmètre d'action de l'équipe, peut être pris en charge par le Scrum Master comme un "impediment", un point de blocage à traiter pour aider l'équipe à mieux fonctionner.

Agenda classique d'une rétrospective:

Revue des actions prises à la rétrospective précédente

Collecte des données: atelier, innovation game

Consolidation et priorisation des sujets

Établir le plan d'actions

Clôture / ROTI

Il existe beaucoup de formats de rétrospective, ces formats peuvent s'appliquer sur l'itération qui vient de finir ou sur une thématique ou un sujet particulier (ex: sur les cérémonies agiles, sur les valeurs, sur l'intégration continue, les tests, etc)

Souvent, une équipe fonctionne avec seulement une ou deux variantes appliquées à l'itération qui vient de finir. Dans ce cas, la cérémonie peut très vite devenir routinière et par conséquent moins créative et efficace pour traiter les problèmes auxquels l'équipe est actuellement confrontée.

Afin d'aider les équipes et les Scrum Masters, nous souhaitons partager avec vous, dans une série d'articles, différents formats de rétrospectives en fournissant un support graphique pour la faciliter.

En effet, selon le format de rétrospective, le facilitateur peut se retrouver à déployer en plus de ses talents d'animateur des talents de dessinateur, c'est le cas pour le format "Speed Boat".

Le Speed Boat

Cet innovation game peut s'avérer utile dans différents contextes, il va permettre à l'équipe de réfléchir à sa vision et ses objectifs, à ce qui les ralentis dans l'atteinte de ces derniers, les risques qu'ils peuvent rencontrer sur le chemin et les bonnes pratiques et les forces qui vont les aider à atteindre leur but.

Voici ce que symbolise chacun des éléments :

Le bateau : l'équipe

L'île : les objectifs à atteindre

Les vents : nos forces, ce qui nous fait avancer

Les ancres : ce qui nous ralentit, les freins

Le soleil : qui je remercie, ce que j'ai aimé

Le rocher : les risques futurs (obstacles à venir)

Déroulement :

1. Chaque personne dispose de 5 minutes pour préparer individuellement ses post-its pour les différents éléments du dessin.

2. Chacun des membres de l'équipe vient coller ses post-its sur le dessin en expliquant rapidement chaque point. À cette étape, il vaut mieux déjà commencer à regrouper les post-its qui parlent du même sujet.

3. L'équipe vote pour le ou les sujets qui lui semble(nt) les plus prioritaires à traiter (dot voting). Limitez votre nombre de sujets, il vaut mieux s'engager sur un seul sujet sur lequel on arrivera à mettre en place les actions rapidement plutôt qu'une multitude de sujets partiellement réalisés. L'amélioration continue doit s'effectuer par petits pas mesurables.

4. Sur chacun des sujets l'équipe élabore un plan d'action qui seront mises en place dès le sprint suivant.

Nous vous proposons de télécharger un support de Speed Boat afin que vous puissiez l'imprimer ou le projeter.

Vous pouvez le faire imprimer dans un magasin spécialisé (au format A1 par exemple) ou convertir l'image en PDF afin les imprimer sur plusieurs feuilles A4 grâce au logiciel Acrobat Reader.

Téléchargez le !

# data[].attributes.attachment_link.description
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." La rétrospective est l'un des moments clefs pour une équipe Scrum, c'est un moment dédié à l'amélioration continue, c'est une des boucles de feedback essentielles pour pouvoir être agile.

# data[].attributes.headline
À chaque sprint sa rétrospective : les funs

# data[].attributes.subject
À chaque sprint sa rétrospective : les funs

# data[].attributes.attachment_link.readable_text
Il y a 5 mois · 10 minutes · Agile

Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, les formats classiques ont été présentés comme une valeur sûre permettant d'obtenir un résultat satisfaisant avec un minimum d'effort. Mais que se passe-t-il lorsque la trop grande répétition de ces formats conduit à une saturation de la part de l'équipe ? Pour maintenir un niveau constant de motivation ou simplement changer de la routine, adapter la rétrospective pour y apporter une touche de fun devrait pouvoir vous sauver.

Pourquoi s'amuser en rétrospective ?

Dérouler un format de rétrospective fun n'a pas seulement pour but de s'amuser. Il serait effectivement difficile d'aller expliquer à vos responsables que vous venez de passer une heure et demi à dessiner des moutons pour la simple raison que c'était décontractant. Prendre l'angle de l'amusement pendant cette cérémonie a en réalité plusieurs vertus :

Une participation en hausse : sous l'effet du jeu, les participants se débrident. L'amusement augmente l'intérêt et par conséquent l'envie de participer. Les langues se délient plus facilement et un nombre conséquent de sujets peuvent être abordés.

Des rapports d'équipe améliorés : le jeu pose un cadre idéal à la création de liens entre les équipiers. Deux personnes qui s'amusent ensemble seront plus enclines à s'apprécier.

Une assertivité développée : il est toujours délicat de faire passer des messages difficiles sans avoir un comportement à effet négatif. La pratique d'un format fun permet de créer une ambiance propice à une communication non agressive et par conséquent à faciliter la résolution des problèmes.

Quand utiliser un format fun ?

Les formats fun vous seront utiles dans les situations suivantes :

La répétition des sprints peut apporter une lassitude aux membres de l'équipe. Cette routine touche particulièrement les cérémonies qui sont, de part leur définition, très ritualisées. Le risque est alors de voir s'installer des habitudes qui aboutiront dans la plupart des cas à un état général d'apathie. Dans le cas de la rétrospective, les conséquences d'un tel état peuvent alors être nombreuses : retard récurrent, remise en question de la cérémonie, nombre de post-it générés en baisse, nombreux post-it à faible valeur ajoutée (allant de " Merci Jean-Michel pour les croissants " à " Demain c'est les vacances ! "), etc. Avant d'arriver à une remise en question totale de la cérémonie, qui impliquerait un format plus adapté dont nous parlerons dans un prochain article de cette série, il est indispensable de briser cette routine en apportant une touche de fun.

Quand un sprint s'est déroulé sans encombre ou évènement majeur, il peut être difficile de contextualiser la rétrospective. Dans le précédent article, cette situation convenait à l'application d'un format classique, mais elle peut également être l'occasion de préparer un format plus amusant et nécessitant un peu plus de travail en amont.

Un ou plusieurs nouveaux équipiers

Lorsque l'équipe se renouvelle au cours d'un sprint, adopter un format de rétrospective fun permettra d'aider les nouveaux arrivants à s'intégrer plus facilement. En effet, forcer des échanges directs entre personnes à travers des activités amusantes est une façon efficace de créer des liens au sein de l'équipe.

Exemples de formats

Jeopardy

À l'origine, Jeopardy est un jeu télévisé américain disposant d'un système de questions/réponses inversées. À partir de réponses également appelées des indices, les candidats doivent trouver la question correspondante. Par exemple, si l'indice donné est " La rétrospective ", il faut bien entendu répondre " Qu'est-ce qui garantit l'amélioration continue au sein d'un projet Scrum ? ".

Préparation

Enfilez la chemise et retroussez vous les manches, il va falloir confectionner un plateau de jeu digne de TF1.

Pour ce faire, dessinez trois colonnes sur un tableau. Dans la première, inscrivez différentes sommes d'argent (100€, 200€, 300€ et 500€). Pour les deux autres colonnes, prévoyez de la place car elles seront destinées aux questions/réponses des deux équipes qui vont s'affronter.

Déroulé

Commencez par expliquer le principe du jeu télévisé Jeopardy et faites le parallèle avec la rétrospective. Il va falloir deviner la bonne question en rapport avec la réponse donnée, toujours dans un esprit d'amélioration continue.

Séparez l'équipe en deux groupes, laissez leur une minute pour trouver un nom d'équipe. Ils vont s'affronter pour essayer de remporter les sommes inscrites sur le plateau de jeu.

Donnez un unique post-it à chaque participant. Ils doivent inscrire une question au stylo bic au dos du post-it (en dessous de la partie collante) et la réponse en gros, au feutre, sur le devant.

Récupérez les post-it et placez les arbitrairement à coté des sommes sur le plateau de jeu. La mise en place est terminée, le jeu peut commencer.

Commencez par les questions à 100€, la première équipe fait des propositions pour tenter de deviner la question de l'autre équipe. Notez toutes ces propositions, ce sont autant d'idées dont on pourra débattre par la suite. Quand il n'y a plus de proposition, retourner le post-it pour voir ce qu'il fallait trouver. Si l'une des propositions correspond, soulignez la et créditez l'équipe de son montant.

Tenez à jour les scores des deux équipes, une fois tous les post-it retournés, annoncez l'équipe gagnante. Vous devriez avoir assez de matière pour passer à la suite de la rétrospective et identifier des actions.

Notre avis

Format idéal pour faire ressortir le Philippe Risoli qui est en vous, animer une rétrospective prend tout son sens ici. Les propositions farfelues ne sont pas à exclure mais à encourager, en plus d'avoir le mérite de faire sourire, elles sont les témoins de l'ambiance qui règne sur le projet.

Le truc en plus

Incarnez réellement le personnage de l'animateur pour détendre vos convives avec une mise en scène digne des plus grands show américains :

Ornez votre plus belle chemise des années 90.

Pour démarrer la cérémonie, faites une entrée tonitruante dans la salle sous les applaudissements d'une foule en délire enregistrée sur youtube.

Prenez un gros feutre qui fera office de micro le reste de la séance.

Prévoyez des sons spéciaux à chaque bonne ou mauvaise réponse.

Préparez les sommes d'argent avec de vrais faux billets de Monopoly que vous remettrez symboliquement à l'équipe gagnante à la fin.

Pictionary

La célèbre phrase de Saint-Exupéry " Dessine-moi un mouton " se transforme ici en " Dessine-moi un sprint ". Retour en maternelle pour tous les participants, c'est l'heure de la séance d'art plastique à la sauce Pictionary.

Matériel

Des feuilles blanches ou un tableau

Des feutres de toutes les couleurs

Déroulé

Distribuez des feuilles blanches et feutres de couleurs à chaque participant. Ils vont devoir représenter trois choses, positives et améliorables, vécues ou ressenties durant le sprint. Si l'équipe est trop grande, réduire à deux dessins par personne ou créer des binômes.

Après dix minutes de liberté artistique, présentez de manière aléatoire les dessins un par un aux participants. Ils vont devoir deviner le message subliminal qui se cache derrière. L'auteur du dessin ne pourra répondre que par l'affirmative ou la négative. Notez toutes les propositions, elles serviront comme base de réflexion quand aux actions à prendre.

Notre avis

Format idéal pour faire ressortir le Picasso qui est en vous, même si cela fait mal de l'admettre, on se rend vite compte que nos talents artistiques n'ont que peu évolué depuis notre chère et tendre enfance. Attention tout de même, en se prenant au jeu les participants commentent de manière libre (ce qui rend l'activité amusante) mais s'éloignent rapidement de l'objectif initial, à savoir deviner le message lié au sprint. Trouver le bon équilibre entre l'amusement et cet objectif n'est pas toujours évident.

Le truc en plus

N'hésitez pas à forcer la nature des dessins en vous basant sur un format classique. Par exemple en demandant de dessiner un content et un pas content, ou un start, un stop et un continue. Cela pourra vous éviter la déconvenue de n'avoir que des dessins représentant des choses positives.

Twitter

L'oiseau bleu revisité le temps de la rétrospective. On se lâche sur les hastag et les RT dans la limite des 140 caractères disponibles.

Préparation

Dessinez un flux d'actualité Twitter sur lequel les participants viendront positionner leur Tweets.

Déroulé

Expliquez le principe de Twitter à l'assemblée. Ils vont devoir Tweeter sur le sprint, les #, @ et emoticon sont vivement encouragés.

Une fois les Tweets écrits, chaque participant vient les coller sur le flux d'actualité en les lisant à voix haute.

Pour définir les " trending topics ", il suffit de mettre un RT ou un like sur ce qui vous intéresse.

Notre avis

#fun #rétrospective #tweets @Agilité

Le truc en plus

Si l'un des membres de l'équipe est un aficionado des Tweets, demandez lui d'expliquer le principe aux autres participants en guise d'introduction.

Dixit

Dixit est un jeu de société comprenant quatre-vingt-quatre cartes illustrées. Les joueurs doivent retrouver la carte correspondant à l'histoire narrée par le conteur.

Matériel

Une boite de jeu Dixit

Un tableau ou paperboard

Un feutre

Préparation

Préparez une table afin d'y disposer les cartes de manière à ce que chacune soit bien visible.

Déroulé

Demandez à chaque participant de venir, à tour de rôle, choisir une carte. Celle qui l'inspire le plus vis à vis du sprint. Recommencez jusqu'à ce que tout le monde ait trois cartes en main.

Une fois la collecte terminée, faites un premier tour de table. Une personne présente aux autres l'une de ses trois cartes. Ils doivent deviner pourquoi cette carte a été choisie par cette personne. Notez toutes les propositions, elles serviront comme base de réflexion quand aux actions à prendre.

Lorsque tout le monde a présenté une carte, demandez si quelqu'un tient à en présenter une deuxième. Il est rare qu'une personne veuille présenter ses trois cartes, certaines étant trop abstraites dans leur interprétation ou le sujet ayant déjà été abordé par quelqu'un d'autre.

Notre avis

Format fun et développant l'empathie. Pour deviner le sens de l'image choisie, il faut se mettre à la place de ses collègues. Le niveau de communication est également mis à rude épreuve, vous verrez tout de suite si l'équipe devine du premier coup ou si au contraire personne n'est conscient des problèmes que peut avoir le reste de l'équipe.

L'originalité de ce format réside dans le fait qu'il n'utilise pas de post-it. Il faut en revanche faire l'acquisition du jeu.

Le truc en plus

Pré-sélectionnez les cartes à présenter en excluant celles qui ne correspondent pas au sprint passé. Cela vous fera gagner du temps en séance.

Conclusion

Vous êtes désormais l'ennemi numéro un de la routine ! La maîtrise des formats fun vous permettra de vous adapter à des situations mettant en péril l'amélioration continue. Cependant, il existe de nombreuses situations pour lesquelles les formats classiques ou fun ne sont pas les plus efficients. Lorsqu'il y a des tensions dans l'équipe ou encore que vous avez de nombreuses stories non terminées, il vous faudra dérouler un format s'adaptant parfaitement à ce contexte. Ne manquez donc pas le prochain article de cette série qui vous présentera plusieurs situations concrètes et les formats de rétrospective qui s'y adaptent le mieux.

Pierre-Philippe est Studio Team Leader à Xebia. Après 3 ans de développement mobile et JEE dans un contexte Agile, il agit maintenant à mi chemin entre le Scrum Master et le Product Owner en garantissant le cadre Agile des projets.

# data[].attributes.attachment_link.title
À chaque sprint sa rétrospective : les funs

# data[].attributes.attachment_link.description
Il y a 5 mois · 10 minutes · Agile Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, les formats classiques ont été présentés comme une valeur sûre permettant d'obtenir un résultat satisfaisant avec un minimum d'effort.

# data[].attributes.headline
À chaque sprint sa rétrospective : les situations courantes 

# data[].attributes.subject
À chaque sprint sa rétrospective : les situations courantes 

# data[].attributes.attachment_link.readable_text
Il y a 5 mois · 14 minutes · Agile

Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, les formats fun ont été présentés comme un parfait complément des formats classiques pour redynamiser vos cérémonies. Cependant, certains contextes de sprint nécessitent l'utilisation de format de rétrospective spécifique, afin d'être le plus efficient possible. Premier passage en revue avec cet article qui se focalisera sur les situations courantes de la vie d'un projet.

Les situations qui seront abordées sont les suivantes :

Début d'une version

Nouvelle équipe

Suivi des progrès

Anticipation des besoins

Fin de version majeure

Début d'une version

En début de projet, que ce soit du point de vue professionnel ou personnel, tout le monde n'a pas les mêmes attentes. Le Product Owner, garant de la vision produit, connait la dimension et les enjeux stratégiques de son produit. Les développeurs, artisans du code, voient surtout les challenges techniques à accomplir. Ces objectifs, parfois aux antipodes, méritent d'être partagés et alignés. Cela améliore l'empathie de l'équipe et permet de démarrer le projet sur des bases saines, grâce aux valeurs de communication et de transparence qui sont chères à la communauté agile.

La culture de l'entreprise est un autre facteur à ne pas omettre. Avoir une personne connaissant le fonctionnement en interne permet d'identifier en amont les blocages que l'équipe risque de rencontrer. Cela peut être une forte dépendance à une équipe tierce, un fournisseur externe capricieux ou une direction peu sensibilisée à l'agilité. Sans obligatoirement résoudre ces problèmes, la rétrospective permet de prendre des actions visant à en atténuer les conséquences.

Sail Boat

Format star de la rétrospective, le sail boat est un incontournable. Grâce à la métaphore du " tous dans le même bateau ", l'équipe analyse ses forces et faiblesses et garde en vue ses objectifs.

Préparation

Dessinez sur un grand tableau, ou deux feuilles de paperboard, un bateau qui navigue sur les flots. Le vent souffle dans la voilure de ce bateau et un magnifique soleil brille au dessus de lui. L'ancre du bateau s'est prise dans les rochers et de dangereux récifs se dressent devant l'île à atteindre.

Déroulé

Expliquez la signification des éléments composant le dessin :

Le bateau : L'équipe, les courageux moussaillons.

Le vent : Nos forces, ce qui pousse le bateau.

L'ancre : Nos faiblesses, ce qui ralenti le bateau.

Le soleil : Qui remercier, les personnes amenant la bonne humeur sur le bateau.

Les récifs : Les risques, les obstacles à éviter pour ne pas jouer le remake du Titanic.

L'île : Nos objectifs, la destination du voyage.

Chaque membre de l'équipe réfléchit individuellement sur ces six éléments. Un post-it par idée. Puis, à tour de rôle, ils vont venir les coller au bon endroit sur le dessin.

Notre avis

Format qui aurait presque pu entrer dans les classiques. Aligner les objectifs de tous est la plus-value de ce format, c'est pourquoi il est vraiment pertinent au début d'un projet ou d'une nouvelle version.

Le truc en plus

Ne pas imprimer le sail boat tel que présenté dans cet article mais le dessiner à la main, cela permet de briser la glace lors de l'introduction du format. Une fois que tout le monde a copieusement critiqué vos talents artistiques, les explications des différents éléments peuvent commencer.

Variantes

Speed car - La version voiture de course, perte de la notion d'objectifs mais gain sur la réflexion des actions à mener grâce au pont.

Hot-air Balloon - La version illustrée grâce à une montgolfière du classique forces / faiblesses avec une projection sur le futur.

On refait le match - Discours du coach dans les vestiaires à la mi-temps d'un OM / PSG d'anthologie.

Star Wars - Très apprécié si certains fans de la saga y participent.

Walking Dead - Un peu long à préparer, mieux vaut la garder pour une grande occasion mais vraiment très fun.

Nouvelle équipe

Ah, les premières fois, c'est toujours un peu stressant comme moment. On ne connait pas vraiment la ou les personnes, on a peur de faire un faux pas, de ne pas être à la hauteur des attentes... Afin de mieux connaître les personnes avec qui vous allez prendre du plaisir durant le projet ; il faut être capable d'empathie, comprendre et respecter les besoins de chacun.

Avoir une nouvelle équipe arrive plus souvent qu'on ne le pense. Chaque équipe a son propre rythme, sa propre échelle, ses conventions. Lorsqu'une nouvelle personne arrive sur le projet, ce n'est pas toujours évident de s'intégrer. L'équipe doit muer, ses habitudes évoluent et s'adaptent à cette nouvelle situation. Une fois la stabilité retrouvée, c'est une toute nouvelle équipe qui en ressort grandie.

Turn the table

Pour faire plus ample connaissance avec ses collègues, rien de tel que de se mettre à leur place. La rétrospective Turn the table permet d'aborder un sujet en prenant le point de vue de quelqu'un d'autre. La communication et l'esprit d'équipe sont grandement renforcés et le nombre de malentendus diminue.

Préparation

Préparez une table et assez de chaises de manière à ce que tout le monde ait un voisin de droite et un voisin de gauche.

Déroulé

Faites assoir tout le monde et distribuez deux post-it verts et deux post-it roses par personne :

Les post-it verts représentent les choses positives

Les post-it roses représentent les choses améliorables

Attention à bien spécifier la longueur du message à inscrire, il ne doit pas dépasser un ou deux mots.

Une fois que tout le monde a ses quatre idées, chacun fait passer ses post-it verts à son voisin de droite et ses post-it roses à son voisin de gauche.

C'est l'heure de rentrer dans les baskets de son collègue : essayez de deviner à tour de rôle la signification des mots inscrits sur les post-it verts.

Une fois terminé, laissez les post-it verts de coté et recommencez l'exercice avec les roses. Mais ici, au delà de l'interprétation, il faut proposer une idée d'amélioration. Les autres personnes peuvent bien sûr rebondir sur l'idée. Notez tout ce qui est dit, après un rapide exercice de priorisation, vous avez vos actions.

Notre avis

Devoir se mettre à la place de quelqu'un n'est jamais un exercice trivial. Il y a pourtant de nombreux bénéfices à en tirer : moins d'incompréhensions, plus de communication et un esprit d'équipe renforcé. Pour encore plus de pertinence, n'hésitez pas à faire un plan de table pour vous assurez que les bonnes personnes interagissent ensemble.

Format à jouer en petit groupe de 3 à 6 personnes. Au delà, la rétrospective risque d'être un peu longue.

Le truc en plus

Insistez bien sur le nombre très réduit de mots par post-it, il faut rester un peu mystérieux dans l'écriture pour que la petite partie de devinettes soit vraiment intéressante.

Variantes

Guess Who - Gamification du format ci-dessus, en plus de se mettre à la place de quelqu'un, il faut trouver de qui il s'agit.

Suivi des progrès

Lorsque votre équipe a appris à se connaître, comprenez ici un minimum de quatre ou cinq sprints, il est indispensable d'avoir les outils pour mesurer les progrès qu'elle réalise, que ce soit d'un point de vue méthodologique, technique ou humain.

Radar

Personne n'aime se faire flasher. Pourtant le format de rétrospective Radar vous rapportera énormément ! Donnant la possibilité à l'équipe de s'évaluer sur différents critères, elle aboutira à une photo riche d'enseignements.

Préparation

Ce format demandera plus ou moins de préparation en fonction de vos préférences sur la définition des critères sur lesquels l'équipe s'évaluera. Trois scénarios possibles :

L'équipe les définit tous : le travail se faisant durant la cérémonie, il faudra simplement préparer un ou deux exemples histoire de ne pas être pris au dépourvu lors de l'explication du format ou en cas de manque d'imagination de la part des participants.

Vous les choisissez arbitrairement : si vous avez une idée précise des critères sur lesquels vous souhaitez faire réfléchir votre équipe, vous pouvez d'ores et déjà préparer le radar sur un paperboard (cf. déroulé).

Un mélange des deux approches précédentes : pas de préparation hormis la réflexion sur les critères pré-définis.

Déroulé optionnel (dans le cas où l'équipe les définit tous)

Demandez aux participants d'écrire sur post-it les critères sur lesquels ils aimeraient que l'équipe s'évalue. Ceux-ci doivent avoir un lien avec les trois catégories suivantes :

les personnes : collaboration, communication, bonheur, etc.

le travail : qualité du code, intérêt, qualité des stories, vision, etc.

les processus : que ce soit organisationnel (Scrum, cérémonie, rythme soutenable, etc.) ou technique (déploiement, suivi de bug, etc.).

Imposez un maximum de quatre post-it par catégorie. Une fois les post-it écrits et présentés, faites un " dot vote " de manière à en sélectionner entre six et huit qui seront affichés sur le radar.

Déroulé

Dessinez une étoile avec autant de branches que de critères. Pour chacun d'entre eux, dessiner une graduation allant de zéro au centre de l'étoile, à dix à l'extrémité. Zéro signifiant un avis très négatif, dix un avis très positif. Indiquez également le nom du critère sur la branche (un ou deux mots maximum).

Il est temps de passer aux votes : notez individuellement chaque critère sur un post-it. Lorsque tout le monde a terminé, venez directement sur le paperboard partager les notes à l'aide de pastilles de couleur ou de points dessinés au marqueur sans les relier (essayez de donner une couleur par participant). Il ne reste plus qu'à tracer le radar en reliant la note moyenne de chaque critère.

Notre avis

Très bon format pour faire se confronter la vision de chaque participant sur l'équipe. Les écarts de notes entre participants et les notes peu élevées sont un terrain de jeux idéal pour discuter et trouver des pistes d'améliorations afin de faire progresser les notes !

Cependant il ne faut pas jouer ce format trop tôt, notamment lorsque l'équipe est en train de se former, car les notes pourraient être faussées par des problèmes inhérents à la création d'une équipe.

Le truc en plus

Répéter ce format avec les mêmes critères de manière régulière (tous les quatre ou cinq sprints) permet de suivre l'évolution des notes et de vous assurez que les actions ont bien porté leur fruit, ou au contraire de chercher à comprendre pourquoi une note a baissé. Au bout d'un certain nombre de répétitions, il peut être utile de changer quelques critères qui peuvent devenir moins pertinents avec le temps ou de les espacer davantage. En revanche cette répétition n'a en principe jamais de fin.

De plus, reproduire le résultat des radars (uniquement avec les notes moyennes) sur des feuilles A4 pour les rendre visible sur un de vos murs vous permettra d'afficher en toute transparence l'évolution de l'équipe. Pensez à écrire en dehors du radar la description du critère sur laquelle l'équipe s'est entendu. En effet, un critère en un ou deux mots perd parfois de son sens plusieurs semaines après la cérémonie. Une description sera alors un bon moyen de s'en souvenir.

Variantes

Happiness Radar - Radar simple qui juge uniquement les catégories de critère (personnes, travail et processus) sur trois niveaux (content, pas content et neutre).

Squad Health Check - La version Spotify pour avoir une vision de toutes les équipes.

Agility Health Radar - Sans aller jusqu'à l'utilisation de l'outil, ce radar a le mérite d'être complet. En effet, le nombre très élevé de critères n'en fait pas un format recommandé pour la rétrospective mais plutôt une source d'inspiration.

Anticipation des besoins

Quand un sprint se déroule sans encombres, on peut difficilement capitaliser sur les échecs afin de tirer des axes d'amélioration. Il faut alors tenter une nouvelle approche, plus orientée sur l'avenir et les souhaits de chacun.

Genie in a Bottle

Qui n'a jamais rêvé de trouver une vielle lampe magique dans la caverne aux merveilles ? Frottez-la et le génie de la lampe viendra exaucer trois souhaits.

Préparation

Dessinez le génie d'Aladin sortant de sa lampe magique.

Déroulé

Présentez la situation à l'équipe : ils ont libéré le génie de la lampe et pour les remercier, celui-ci leur accorde à tous trois vœux :

Un vœu pour vous

Un vœu pour votre équipe

Un vœu pour votre produit et vos utilisateurs

Chaque membre de l'équipe note ses trois vœux puis les partage avec tout le monde. Pas de triche sur les vœux, on ne peut pas en demander plus de trois.

Notre avis

Format de type liste au père noël pouvant créer de la frustration lorsque le génie ne peut pas exaucer tous les vœux. Cette frustration disparait toute seule si les vœux sont priorisés et que des actions efficaces sont prises.

Le truc en plus

Encouragez les vœux qui semblent irréalisables. Même si c'est vraiment le cas, des actions bien concrètes pourront tout de même être prises.

Variantes

Fin de version majeure

Lorsqu'une version, ou release, se termine, que ce soit par le fruit d'une succession de mises en production ou bien d'une seule, il est important de prendre du recul sur cette période passée (généralement de plusieurs sprints), afin d'améliorer les processus pour la prochaine version.

Timeline

Lorsque l'équipe a besoin de regarder sur une période plus longue qu'un simple sprint, la rétrospective Timeline est le format idéal. Mélangeant faits et émotions, elle fait partie des incontournables.

Préparation

Sur un grand tableau, dessinez une ligne sur laquelle sont indiqués les précédents sprints. Gardez un espace suffisant au-dessus pour laisser de la place à tous les post-it. En dessous, séparez de nouveau en deux lignes en les annotant des légendes en smiley content et pas content.

Déroulé

Cette rétrospective se passe en deux temps :

Dans la partie haute de la Timeline, demandez à chaque participant d'écrire sur post-it les évènements majeurs qui se sont passés durant la période de temps indiquée au tableau. Pour améliorer le visuel, proposez trois catégories de post-it : rose pour les évènements négatifs, vert pour les évènements positifs et jaune pour les autres évènements majeurs.

Lorsque tous les évènements ont été posés, demandez ensuite à chaque participant de dessiner, dans la partie basse de la Timeline, une courbe exprimant la manière dont il a vécu ces évènements. Pensez à prendre une couleur différente par participant.

Notre avis

Format particulièrement adapté pour revenir sur une version mais qui peut parfaitement être utilisée sur le périmètre d'un sprint à condition que de nombreux évènements se soient produits. L'analyse en séance de la Timeline est riche d'enseignement : les écarts entre participants dans la courbe des ressentis, et les contradictions entre les courbes de ressentis et la nature des évènements, sont autant d'éléments favorisant la discussion et la prise d'action.

Le truc en plus

Préparez à l'avance une liste d'évènements pour palier les problèmes de mémoire des participants. Dans le même esprit, n'hésitez pas à relancer l'étape de recueil de données sur la base des post-it déjà en place. Le simple fait de lire des évènements passés peut aider à retrouver la mémoire.

Conclusion

Vous êtes désormais en mesure de proposer des formats de rétrospective qui s'adaptent parfaitement à des situations vécues systématiquement par une équipe. Pour autant, il existe des situations survenant dans des contextes particuliers pour lesquelles un Scrum Master ne sera pas forcément préparé. Ne manquez donc pas le dernier article de cette série qui vous présentera des situations normalement exceptionnelles et les formats de rétrospective qui s'y adaptent le mieux.

# data[].attributes.attachment_link.title
À chaque sprint sa rétrospective : les situations courantes

# data[].attributes.attachment_link.description
Il y a 5 mois · 14 minutes · Agile Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, les formats fun ont été présentés comme un parfait complément des formats classiques pour redynamiser vos cérémonies.

# data[].attributes.headline
À chaque sprint sa rétrospective : les situations exceptionnelles 

# data[].attributes.subject
À chaque sprint sa rétrospective : les situations exceptionnelles 

# data[].attributes.attachment_link.readable_text
Il y a 5 mois · 18 minutes · Agile

Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, des formats bien ciblés ont été présentés pour s'adapter aux différentes étapes de la vie d'un projet. Plus occasionnellement, la rétrospective peut être utilisée à bon escient pour répondre à un besoin précis. Deuxième passage en revue avec cet article qui se focalisera sur les situations exceptionnelles de la vie d'un projet.

Les situations qui seront abordées sont les suivantes :

Trou de mémoire

Tension dans l'équipe

Pas d'intérêt pour les cérémonies

La majorité des user stories n'a pas été terminée

Un sujet à creuser

Trou de mémoire

Les pertes de mémoire peuvent être d'origines diverses : maladie d'Alzheimer, manque de sommeil, stress, carences alimentaires, consommation excessive de drogues, effet secondaire d'un médicament ou simple flemme cérébrale. Lorsqu'un de ces symptômes touche une ou plusieurs personnes dans votre équipe, la rétrospective se résume alors à deux situations : peu de post-it et/ou des post-its pas des plus pertinents. Pour éviter une épidémie, il existe un remède simple et sans effet secondaire...

Boîte aux lettres

Pour permettre à toute l'équipe de se souvenir des évènements qui se sont déroulés durant le sprint, il ne faut pas toujours attendre la retrospective. Ce format, qui testera également vos qualités artistiques, se déroulera tout au long du sprint jusqu'à une rétrospective pleine de surprises.

Matériel

Une boîte en carton (de type boite à chaussures ou à mouchoirs)

Préparation

Prenez la boîte en carton et découpez-y un trou de manière à créer une boîte aux lettres. N'hésitez pas à orner la boîte de décorations sorties tout droit de votre imaginaire.

Préparez également le lieu qui accueillera cette boîte : elle doit être visible et facilement accessible de tous, c'est le meilleur moyen de la faire adopter rapidement par l'équipe. Par exemple, juste à côté de votre scrumboard.

Déroulé

Ce format se déroule en deux temps :

Dès la fin du sprint planning, prenez quelques instants pour présenter votre nouvelle boîte et expliquer à l'équipe son utilité : lorsqu'un évènement survient ou qu'une personne pense à une idée, elle devra l'écrire sur un papier annoté de son nom et le poster directement dans la boîte.

En ouverture, faites une mise en scène digne de Koh-Lanta pour ouvrir la boîte et révélez son contenu. Pour chaque papier, invitez la personne concernée à expliquer son sujet. Lorsque tous les sujets ont été découverts, il est temps de choisir ceux qui seront débattus et susceptibles d'être améliorés.

Notre avis

Contrairement à ce qui est indiqué sur la notice, ce remède contre les pertes de mémoire n'est pas magique et le principal risque est de trouver une boîte aux lettres vide lors de la rétrospective. Pour que le remède fonctionne, il faut entretenir la vie de la boîte tout au long de l'itération en relançant les personnes jusqu'à ce que cela devienne une habitude pour eux. Par conséquent, ce format est à éviter pour les Scrum Master qui ne sont pas présents à temps plein avec leur équipe.

Lorsque toute l'équipe joue le jeu, le contenu de la boîte est généralement très riche et permet d'obtenir une rétrospective de qualité.

Le truc en plus

Après avoir découvert tout le contenu de la boîte, donnez quelques instants aux participants pour écrire de nouveaux post-its. Il arrive souvent que le rappel des différents évènements leur donne de nouvelles idées.

Tension dans l'équipe

Quoi de pire comme situation que deux membres d'une même équipe refusant de collaborer ? Les conséquences sont désastreuses : perte de motivation, peur de parler, conflit, agressivité, sabotage, etc. Comment les amener à crever l'abcès sans déclencher la troisième guerre mondiale ? Si les premiers symptômes se font sentir, et même si la rétrospective n'est pas l'endroit le plus approprié pour résoudre un différend, elle peut être adaptée pour laisser la parole aux différents partis pris. Bien souvent, recourir à l'écoute empathique suffit à dissiper tout malentendu. Si ce n'est pas le cas, c'est au Scum Master de prendre les choses en main et de résoudre le conflit avec l'aide des personnes appropriées.

Empathy Map

Emprunté à nos collègues UX Designer qui l'utilisent dans la définition des personas, l'atelier Empathy Map peut être détourné en format de rétrospective. Au lieu de chercher à comprendre les utilisateurs, les membres de l'équipe cherchent à se comprendre mutuellement pour améliorer leur communication.

Préparation

Dessinez un visage de profil sur un tableau de manière à ce que l'on distingue une oreille, un œil, le nez et la bouche. Découpez ensuite la zone en quatre sections en laissant de la place en dessous de la tête pour deux sections supplémentaires.

Déroulé

Avant de se lancer dans les post-its, n'hésitez pas à prendre la température des participants. Nul besoin d'un thermomètre, un atelier ice breaker fera parfaitement l'affaire. Si nécessaire, répétez la safe phrase : " Indépendamment de ce que nous allons découvrir aujourd'hui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux, en fonction de ses connaissances, de ses compétences et de ses capacités, des ressources disponibles et de la situation courante. " (Norm Kerth).

Une fois l'échauffement terminé, passez aux choses sérieuses. Rappelez à tout le monde le sujet qui pose problème sans prendre partie. Conservez une position d'arbitre impartial et présentez les six sections du dessin à l'équipe :

L'oreille : Ce que j'entends sur le conflit.

La tête : Ce que je pense, ce que je ressens à propos du conflit.

L'œil : Ce que je vois du conflit.

La bouche : Ce que je dis, ce que je fais à propos du conflit.

Les gains : Ce que l'on va obtenir en résolvant le conflit.

Les douleurs : Ce qui va se passer si le conflit perdure.

Chaque participant peut maintenant réfléchir individuellement aux différents éléments. Restez très vigilant lors de la phase de restitution, il faut vite recadrer le débat si celui-ci dérive en accusations.

Une fois que tout le monde s'est exprimé, regroupez les sujets similaires, votez pour les plus importants et démarrez la recherche d'actions.

Notre avis

Ce format aide à partager ses émotions, ce qui peut parfois suffire à ôter les œillères de certains collègues et leur offrir de nouvelles perspectives sur la situation. Faites bien attention aux potentiels dérapages, encore une fois la rétrospective n'est pas l'endroit le plus approprié pour résoudre un conflit. Cela peut en revanche faire du bien à l'équipe d'en prendre conscience et d'en constater les impacts.

Le truc en plus

Encouragez l'utilisation du " je " plutôt que du " tu " de manière à mettre en avant l'expression des sentiments plutôt que des accusations. Par exemple, au lieu de dire " Michel, tu as encore cassé les tests d'intégration, fait attention bordel ", il est préférable de dire " Je me suis senti énervé lorsque les tests d'intégration sont tombés une nouvelle fois, je pense qu'ils ne sont pas assez robustes ".

Variantes

Pas d'intérêt pour les cérémonies

Il existe de nombreuses raisons de ne pas aimer les cérémonies Scrum : trop longues, répétitives, sentiment d'inutilité, etc. La rétrospective ne déroge pas à cette règle et les symptômes ressemblent souvent à ceux décrits dans la situation de perte de mémoire : peu de post-it et/ou des post-its sans intérêt. Lorsque vous sentez que des personnes subissent certaines cérémonies et les prennent comme des contraintes plutôt que comme des opportunités, il est grand temps d'adapter votre rétrospective pour gérer ce problème.

ROTI meetings

Si vous sentez que votre équipe n'est pas motivé par plus d'une cérémonie, ce format vous permettra d'en avoir le coeur net à travers le détournement assumé du fameux ROTI (Return On Time Invested) servant habituellement en clôture.

Préparation

Dessinez un axe avec :

en abscisse, les différentes cérémonies effectuées par l'équipe chaque sprint (daily, sprint planning, sprint review, rétrospective, backlog refinement, etc.).

en ordonnée, les notes de 1 à 5.

Déroulé

Demandez aux participants de venir noter chaque cérémonie avec une pastille de couleur (une couleur par participant si possible). Rappelez au passage la signification des notes :

1 - Inutile, ça ne m'a strictement rien apporté.

2 - Bof, j'ai tout de même perdu mon temps.

3 - Moyen, je n'ai pas vraiment perdu mon temps, mais ça ne m'a pas apporté grand chose non plus.

4 - Intéressant, mon temps a servi à quelque chose.

5 - Excellente, impossible de faire mieux en temps passé par rapport à la valeur que cela m'a apporté.

Lorsque les notes sont révélées, prenez la cérémonie qui présentent le plus de notes négatives et/ou moyennes et enchainez avec un format de type start / stop / continue pour recueillir davantage de données spécifiques sur cette cérémonie.

Notre avis

Résultat 100% garanti. Ce format est une valeur sûre mais n'oubliez pas qu'il est la résultante de nombreux manquements. Jouer régulièrement un ROTI à la fin de chaque cérémonie pour comprendre les axes d'améliorations possible est le meilleur moyen de ne pas avoir besoin d'en arriver là en retrospective.

Le truc en plus

Si vous êtes nombreux, séparez l'équipe en deux groupes et donnez à chacun l'objectif d'améliorer une cérémonie.

ESVP

Particulièrement axé sur la rétrospective comparé au format précédent, l'ESVP sera utile si vous avez des doutes sur les motivations de l'équipe vis à vis de cette cérémonie.

Préparation

Dessinez un quadrant représentant les quatres attitudes suivantes :

Explorer : impatient d'en découdre avec les problèmes de l'itération, là pour réfléchir à de nouvelles idées.

Shopper : souhaite prendre les informations qui se présentent sans forcément être un acteur.

Vacacioner : ne s'intéresse pas au contenu mais content d'être en réunion pour parler et changer de son quotidien.

Prisoner : n'éprouve aucun intérêt pour la rétrospective et se sent forcé d'être présent.

Pour chaque case du quadrant, illustrez-la d'un dessin de votre cru le plus représentatif possible.

La particularité de ce format est qu'il faut préparer un autre format dans le cas où celui-ci ne nécessiterait pas davantage d'investigation. Préparez donc également un format de rétrospective adapté au contenu de l'itération.

Déroulé

Présentez le quadrant et demandez à chaque participant d'inscrire anonymement sur post-it l'attitude qu'ils vont avoir durant la rétrospective. Après avoir relevé les post-its, reportez les résultats sur le tableau.

Si vous obtenez des " Vacacioners " et/ou des " Prisoners ", le sujet de la rétrospective doit changer pour tenter de trouver quelles sont les raisons qui amènent les participants à venir avec cette attitude. De la même manière que le format précédent, dérouler un start / stop / continue ou un simple content / pas content, sur la thématique de la rétrospective vous permettra de lever les non dits.

Si vous n'avez que des " Shoppers " ou " Explorers ", vous pouvez enchaîner sur le format de rétrospective initialement prévu.

Notre avis

Remplacer des doutes ou ressentis par des faits, c'est tout l'objectif de ce format. Et il y répond parfaitement.

La difficulté de cet exercice est de préparer tous les scénarios possibles, afin de ne pas être pris au dépourvu lors de la découverte des réponses et donner davantage de grain à moudre à ceux qui étaient venus comme " prisoners ". Par exemple, si vous n'avez que des " Explorers " sauf un qui est " Prisoner ", il n'est peut être pas utile de détourner totalement le contenu de la rétrospective. Vous pouvez demander si cette personne souhaite s'exprimer en levant l'anonymat et introduire un débât d'équipe vis à vis des arguments proposés. L'important est de garder la maîtrise du temps pour pouvoir enchaîner sur le format suivant.

La majorité des user stories n'a pas été terminée

Lorsque des user stories durent plus longtemps que prévu, que des personnes se sont souvent plaintes durant l'itération à propos de leurs stories ou qu'il en reste beaucoup en cours de développement mais non terminées à la fin de l'itération, il est peut être temps de se poser et de prendre un peu de recul sur le contenu de vos stories.

Analyse de stories

Pour comprendre les stories, il faut déjà faire l'exercice de les passer en revue. Et c'est ce que propose ce format via un exercice grandement inspiré du content / pas content.

Préparation

Divisez le haut de votre tableau en deux colonnes :

Un post-it vert sur lequel un smiley content est dessiné dans la colonne de gauche.

Un post-it rose sur lequel un smiley pas content est dessiné dans la colonne de droite.

Récupérez ensuite l'ensemble des post-its de user stories qui ont été commencées et/ou terminées. Elle vous serviront lors du déroulé.

Déroulé

Présentez d'abord une par une les user stories que vous avez récupérées, et demandez à l'équipe dans un vote à main levée si ces stories se sont bien déroulées ou non. En fonction du résultat, placez le post-it dans la colonne de gauche ou de droite.

Faites ensuite sélectionner, via un dot voting, les stories que les participants aimeraient analyser plus en profondeur. Pour l'heureuse élue qui a recueilli le plus de votes, demandez à l'équipe de noter sur post-it leurs idées dans les trois colonnes suivantes :

Une colonne pour les éléments qui ont permis de faire avancer la story.

Une colonne pour les éléments qui ont ralenti la story.

Une colonne pour les éléments qui ont bloqué la story.

Après un nouveau dot voting sur les éléments jugés les plus importants, vous avez désormais la matière pour réfléchir sur les actions d'amélioration.

Notre avis

Ce format peut servir d'approche détournée pour faire prendre conscience à votre équipe de la nécessité de définir ou redéfinir la signification d'une story terminée (DoD) et prête à être implémentée (DoR). En effet, l'analyse amène souvent les participants à créer une liste de critères à vérifier en amont et en aval des stories pour ne plus retomber dans les mêmes travers.

Point d'attention : si des personnes n'ont pas participé à la story qui a été sélectionnée, elles risquent de trouver le temps long. N'hésitez pas à sélectionner deux voire trois stories qui seront sujettes en même temps à une analyse plus profonde et qui permettront à tout le monde de s'exprimer.

Le truc en plus

Pour les équipes relativement peu nombreuses, plutôt que d'effectuer un dot voting sur les éléments ralentissants ou bloquants des stories, proposez à chaque participant de choisir un post-it et laissez leur quelques minutes pour trouver individuellement une action d'amélioration.

Chaque personne sera alors responsable de son action si celle-ci a été acceptée par le reste des participants. Responsable signifiant celui qui suit le sujet et pas forcément celui qui le traite.

Variante

Identify boring stories - Exercice similaire via la mise en place cette fois d'un quadrant pour cibler prioritairement les stories pénibles et qui ont pris du temps.

Un sujet à creuser

Si certains sujets reviennent de manière régulière lors des rétrospectives, c'est peut être que seules des actions de surface ont été menées. Pour éliminer complétement un problème, il faut creuser profondément pour le résoudre à la source.

Le Scrum Master peut également avoir envie d'aborder un sujet en particulier suite à une intuition ou à des remontées lors du sprint. Il peut utiliser la rétrospective et donc l'intelligence collective pour résoudre le problème détecté.

Fleur de Lotus

Inspiré de la littérature japonaise, le cœur de cette fleur représente le problème à résoudre et ses pétales de possibles causes.

Préparation

Dessinez deux fleurs de huit pétales chacune.

Déroulé

Commencez par inscrire une question ouverte au centre de la fleur. Cela peut être assez vague comme " Qu'est ce qui nous a empêché d'avancer pendant le sprint ? " ou répondre à un besoin précis du Scrum Master comme " Pourquoi de nombreux bugs ne sont détectés qu'en production ? ".

Dès que quelqu'un identifie un problème pouvant répondre à cette question, il vient ajouter un pétale à la fleur. L'exercice s'arrête lorsque la fleur a ses huit pétales au complet.

Faites prioriser les problèmes par l'équipe afin d'attaquer le plus pénalisant en premier. Ce pétale devient alors le centre d'une nouvelle fleur de lotus.

Relancez la collecte des pétales sur cette nouvelle fleur, cette fois ce sont huit causes potentielles qu'il faut trouver.

Une fois la fleur complète, prioriser les causes de la même manière que précédemment. Il ne reste plus qu'a prendre des actions sur les pétales les plus votés.

Notre avis

Activité hautement créatrice car demandant d'explorer huit possibilités à chaque fois. La réflexion commune à haute voix permet aux idées de rebondir dans tous les sens et d'arriver facilement à trouver tous les pétales.

Le truc en plus

Si plusieurs pétales arrivent en haut des priorités et que la taille de votre équipe le permet, faites deux groupes de réflexion sur les deux pétales les plus votés.

Variante

5 Whys - Se poser cinq fois la question " Pourquoi ? " afin de trouver la cause réelle d'un problème.

6 Thinking Hats - Les chapeaux canalisent les idées pour que celles-ci ailles toutes dans le même sens, sans en oublier aucune.

Pour aller plus loin

Si cette série d'articles n'a pas arrété votre soif de nouveau format, sachez qu'il existe différents sites qui devraient faire votre bonheur. Bien que ceux-ci ne soient pas orientés situations mais simplement dédiés à lister des formats, vous devriez, après une plus ou moins longue phase d'exploration, trouver le format qui répond à vos attentes.

Voici une liste non exhaustive :

Retromat - Une liste assez impressionnante de formats dont un peu plus d'un tiers traduite en français.

Fun Retrospectives - Tout est dans le titre. Site spécialisé dans les formats privilégiant une approche ludique.

Retrospective Techniques for Coaches Scrum Masters and Other Facilitators on Trello - L'idée est louable : rassembler de manière simplifiée les formats définis sur internet (une majorité venant de Retromat et Fun Retrospectives). Le format Trello est plutôt pratique.

Agile Retrospective Resource Wiki - Il y a un wiki pour tout, la rétrospective n'y échappe pas. Au delà des formats, ce site propose quelques astuces toujours bonnes à prendre et une section dédiée aux références (articles et livres) bien plus complète que celle-ci.

TastyCupcakes.org - L'OVNI de cette liste. Pas uniquement centré sur la rétrospective, ce site répertorie toute sorte de jeu et technique d'animation qui pourront être une source d'inspiration importante. Le format blog n'est par contre pas le plus efficace dans la recherche exploratoire de format.

N'oublions pas de citer le livre de référence sur le sujet, qui bien qu'aillant plus d'une dizaine d'années, reste toujours aussi pertinent :

Conclusion

La rétrospective n'a maintenant plus aucun secret pour vous. Tout ce qu'il reste à faire c'est pratiquer, essayer de nouvelles choses et faire de l'amélioration continue sur la manière de conduire cette cérémonie. D'autres évènements peuvent vous amener à réfléchir à un nouveau format, quitte à devoir l'inventer vous même. Reprenez un concept vu dans cette série d'article et modifiez quelques paramètres pour arriver à vos fins. Ne tentez pas le diable si votre expérience ou votre contexte de projet ne vous le permet pas, les formats présentés ici couvrent 99% de vos besoins. Bonnes rétrospectives !

# data[].attributes.attachment_link.title
À chaque sprint sa rétrospective : les situations exceptionnelles

# data[].attributes.attachment_link.description
Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, des formats bien ciblés ont été présentés pour s'adapter aux différentes étapes de la vie d'un projet.

# data[].attributes.attachment_link.readable_text
Il y a 5 mois · 10 minutes · Agile

Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, les formats classiques ont été présentés comme une valeur sûre permettant d'obtenir un résultat satisfaisant avec un minimum d'effort. Mais que se passe-t-il lorsque la trop grande répétition de ces formats conduit à une saturation de la part de l'équipe ? Pour maintenir un niveau constant de motivation ou simplement changer de la routine, adapter la rétrospective pour y apporter une touche de fun devrait pouvoir vous sauver.

Pourquoi s'amuser en rétrospective ?

Dérouler un format de rétrospective fun n'a pas seulement pour but de s'amuser. Il serait effectivement difficile d'aller expliquer à vos responsables que vous venez de passer une heure et demi à dessiner des moutons pour la simple raison que c'était décontractant. Prendre l'angle de l'amusement pendant cette cérémonie a en réalité plusieurs vertus :

Une participation en hausse : sous l'effet du jeu, les participants se débrident. L'amusement augmente l'intérêt et par conséquent l'envie de participer. Les langues se délient plus facilement et un nombre conséquent de sujets peuvent être abordés.

Des rapports d'équipe améliorés : le jeu pose un cadre idéal à la création de liens entre les équipiers. Deux personnes qui s'amusent ensemble seront plus enclines à s'apprécier.

Une assertivité développée : il est toujours délicat de faire passer des messages difficiles sans avoir un comportement à effet négatif. La pratique d'un format fun permet de créer une ambiance propice à une communication non agressive et par conséquent à faciliter la résolution des problèmes.

Quand utiliser un format fun ?

Les formats fun vous seront utiles dans les situations suivantes :

La répétition des sprints peut apporter une lassitude aux membres de l'équipe. Cette routine touche particulièrement les cérémonies qui sont, de part leur définition, très ritualisées. Le risque est alors de voir s'installer des habitudes qui aboutiront dans la plupart des cas à un état général d'apathie. Dans le cas de la rétrospective, les conséquences d'un tel état peuvent alors être nombreuses : retard récurrent, remise en question de la cérémonie, nombre de post-it générés en baisse, nombreux post-it à faible valeur ajoutée (allant de " Merci Jean-Michel pour les croissants " à " Demain c'est les vacances ! "), etc. Avant d'arriver à une remise en question totale de la cérémonie, qui impliquerait un format plus adapté dont nous parlerons dans un prochain article de cette série, il est indispensable de briser cette routine en apportant une touche de fun.

Quand un sprint s'est déroulé sans encombre ou évènement majeur, il peut être difficile de contextualiser la rétrospective. Dans le précédent article, cette situation convenait à l'application d'un format classique, mais elle peut également être l'occasion de préparer un format plus amusant et nécessitant un peu plus de travail en amont.

Un ou plusieurs nouveaux équipiers

Lorsque l'équipe se renouvelle au cours d'un sprint, adopter un format de rétrospective fun permettra d'aider les nouveaux arrivants à s'intégrer plus facilement. En effet, forcer des échanges directs entre personnes à travers des activités amusantes est une façon efficace de créer des liens au sein de l'équipe.

Exemples de formats

Jeopardy

À l'origine, Jeopardy est un jeu télévisé américain disposant d'un système de questions/réponses inversées. À partir de réponses également appelées des indices, les candidats doivent trouver la question correspondante. Par exemple, si l'indice donné est " La rétrospective ", il faut bien entendu répondre " Qu'est-ce qui garantit l'amélioration continue au sein d'un projet Scrum ? ".

Préparation

Enfilez la chemise et retroussez vous les manches, il va falloir confectionner un plateau de jeu digne de TF1.

Pour ce faire, dessinez trois colonnes sur un tableau. Dans la première, inscrivez différentes sommes d'argent (100€, 200€, 300€ et 500€). Pour les deux autres colonnes, prévoyez de la place car elles seront destinées aux questions/réponses des deux équipes qui vont s'affronter.

Déroulé

Commencez par expliquer le principe du jeu télévisé Jeopardy et faites le parallèle avec la rétrospective. Il va falloir deviner la bonne question en rapport avec la réponse donnée, toujours dans un esprit d'amélioration continue.

Séparez l'équipe en deux groupes, laissez leur une minute pour trouver un nom d'équipe. Ils vont s'affronter pour essayer de remporter les sommes inscrites sur le plateau de jeu.

Donnez un unique post-it à chaque participant. Ils doivent inscrire une question au stylo bic au dos du post-it (en dessous de la partie collante) et la réponse en gros, au feutre, sur le devant.

Récupérez les post-it et placez les arbitrairement à coté des sommes sur le plateau de jeu. La mise en place est terminée, le jeu peut commencer.

Commencez par les questions à 100€, la première équipe fait des propositions pour tenter de deviner la question de l'autre équipe. Notez toutes ces propositions, ce sont autant d'idées dont on pourra débattre par la suite. Quand il n'y a plus de proposition, retourner le post-it pour voir ce qu'il fallait trouver. Si l'une des propositions correspond, soulignez la et créditez l'équipe de son montant.

Tenez à jour les scores des deux équipes, une fois tous les post-it retournés, annoncez l'équipe gagnante. Vous devriez avoir assez de matière pour passer à la suite de la rétrospective et identifier des actions.

Notre avis

Format idéal pour faire ressortir le Philippe Risoli qui est en vous, animer une rétrospective prend tout son sens ici. Les propositions farfelues ne sont pas à exclure mais à encourager, en plus d'avoir le mérite de faire sourire, elles sont les témoins de l'ambiance qui règne sur le projet.

Le truc en plus

Incarnez réellement le personnage de l'animateur pour détendre vos convives avec une mise en scène digne des plus grands show américains :

Ornez votre plus belle chemise des années 90.

Pour démarrer la cérémonie, faites une entrée tonitruante dans la salle sous les applaudissements d'une foule en délire enregistrée sur youtube.

Prenez un gros feutre qui fera office de micro le reste de la séance.

Prévoyez des sons spéciaux à chaque bonne ou mauvaise réponse.

Préparez les sommes d'argent avec de vrais faux billets de Monopoly que vous remettrez symboliquement à l'équipe gagnante à la fin.

Pictionary

La célèbre phrase de Saint-Exupéry " Dessine-moi un mouton " se transforme ici en " Dessine-moi un sprint ". Retour en maternelle pour tous les participants, c'est l'heure de la séance d'art plastique à la sauce Pictionary.

Matériel

Des feuilles blanches ou un tableau

Des feutres de toutes les couleurs

Déroulé

Distribuez des feuilles blanches et feutres de couleurs à chaque participant. Ils vont devoir représenter trois choses, positives et améliorables, vécues ou ressenties durant le sprint. Si l'équipe est trop grande, réduire à deux dessins par personne ou créer des binômes.

Après dix minutes de liberté artistique, présentez de manière aléatoire les dessins un par un aux participants. Ils vont devoir deviner le message subliminal qui se cache derrière. L'auteur du dessin ne pourra répondre que par l'affirmative ou la négative. Notez toutes les propositions, elles serviront comme base de réflexion quand aux actions à prendre.

Notre avis

Format idéal pour faire ressortir le Picasso qui est en vous, même si cela fait mal de l'admettre, on se rend vite compte que nos talents artistiques n'ont que peu évolué depuis notre chère et tendre enfance. Attention tout de même, en se prenant au jeu les participants commentent de manière libre (ce qui rend l'activité amusante) mais s'éloignent rapidement de l'objectif initial, à savoir deviner le message lié au sprint. Trouver le bon équilibre entre l'amusement et cet objectif n'est pas toujours évident.

Le truc en plus

N'hésitez pas à forcer la nature des dessins en vous basant sur un format classique. Par exemple en demandant de dessiner un content et un pas content, ou un start, un stop et un continue. Cela pourra vous éviter la déconvenue de n'avoir que des dessins représentant des choses positives.

Twitter

L'oiseau bleu revisité le temps de la rétrospective. On se lâche sur les hastag et les RT dans la limite des 140 caractères disponibles.

Préparation

Dessinez un flux d'actualité Twitter sur lequel les participants viendront positionner leur Tweets.

Déroulé

Expliquez le principe de Twitter à l'assemblée. Ils vont devoir Tweeter sur le sprint, les #, @ et emoticon sont vivement encouragés.

Une fois les Tweets écrits, chaque participant vient les coller sur le flux d'actualité en les lisant à voix haute.

Pour définir les " trending topics ", il suffit de mettre un RT ou un like sur ce qui vous intéresse.

Notre avis

#fun #rétrospective #tweets @Agilité

Le truc en plus

Si l'un des membres de l'équipe est un aficionado des Tweets, demandez lui d'expliquer le principe aux autres participants en guise d'introduction.

Dixit

Dixit est un jeu de société comprenant quatre-vingt-quatre cartes illustrées. Les joueurs doivent retrouver la carte correspondant à l'histoire narrée par le conteur.

Matériel

Une boite de jeu Dixit

Un tableau ou paperboard

Un feutre

Préparation

Préparez une table afin d'y disposer les cartes de manière à ce que chacune soit bien visible.

Déroulé

Demandez à chaque participant de venir, à tour de rôle, choisir une carte. Celle qui l'inspire le plus vis à vis du sprint. Recommencez jusqu'à ce que tout le monde ait trois cartes en main.

Une fois la collecte terminée, faites un premier tour de table. Une personne présente aux autres l'une de ses trois cartes. Ils doivent deviner pourquoi cette carte a été choisie par cette personne. Notez toutes les propositions, elles serviront comme base de réflexion quand aux actions à prendre.

Lorsque tout le monde a présenté une carte, demandez si quelqu'un tient à en présenter une deuxième. Il est rare qu'une personne veuille présenter ses trois cartes, certaines étant trop abstraites dans leur interprétation ou le sujet ayant déjà été abordé par quelqu'un d'autre.

Notre avis

Format fun et développant l'empathie. Pour deviner le sens de l'image choisie, il faut se mettre à la place de ses collègues. Le niveau de communication est également mis à rude épreuve, vous verrez tout de suite si l'équipe devine du premier coup ou si au contraire personne n'est conscient des problèmes que peut avoir le reste de l'équipe.

L'originalité de ce format réside dans le fait qu'il n'utilise pas de post-it. Il faut en revanche faire l'acquisition du jeu.

Le truc en plus

Pré-sélectionnez les cartes à présenter en excluant celles qui ne correspondent pas au sprint passé. Cela vous fera gagner du temps en séance.

Conclusion

Vous êtes désormais l'ennemi numéro un de la routine ! La maîtrise des formats fun vous permettra de vous adapter à des situations mettant en péril l'amélioration continue. Cependant, il existe de nombreuses situations pour lesquelles les formats classiques ou fun ne sont pas les plus efficients. Lorsqu'il y a des tensions dans l'équipe ou encore que vous avez de nombreuses stories non terminées, il vous faudra dérouler un format s'adaptant parfaitement à ce contexte. Ne manquez donc pas le prochain article de cette série qui vous présentera plusieurs situations concrètes et les formats de rétrospective qui s'y adaptent le mieux.

Pierre-Philippe est Studio Team Leader à Xebia. Après 3 ans de développement mobile et JEE dans un contexte Agile, il agit maintenant à mi chemin entre le Scrum Master et le Product Owner en garantissant le cadre Agile des projets.

# data[].attributes.attachment_link.title
À chaque sprint sa rétrospective : les funs

# data[].attributes.attachment_link.description
Il y a 5 mois · 10 minutes · Agile Lorsque l'heure de la rétrospective approche, le Scrum Master se questionne inexorablement sur le format qu'il va devoir choisir. Dans le précédent article de cette série, les formats classiques ont été présentés comme une valeur sûre permettant d'obtenir un résultat satisfaisant avec un minimum d'effort.

# data[].attributes.attachment_link.readable_text
Pourquoi la rétrospective ?

En théorie, la rétrospective est l'occasion pour toute équipe agile d'analyser, pendant un court instant, ce qui s'est passé lors de l'itération. Elle permet aux participants d'améliorer leur collaboration et leurs méthodes de travail.

Elle a pour but l'adaptation aux changements qui surviennent au cours du projet et l'amélioration continue du processus de développement pour s'assurer que le produit livré correspond toujours aux attentes du client. L'objectif de cette inspection étant d'identifier les éléments du processus de développement qui ont bien fonctionné et ceux qui sont à améliorer. S'en suit un plan d'actions d'amélioration que l'équipe mettra en place à l'itération suivante.

Elle est pour moi l'une des composantes essentielles d'un projet agile. Sans rétrospectives, point d'apprentissage constant et d'amélioration continue et donc point d'agilité.

Mais tout cela reste, malheureusement, bien théorique.

A quoi ressemblent réellement vos rétrospectives ?

Vous vous retrouvez avec l'équipe de développement et toute autre personne conviée à la rétrospective dans une salle autour d'une petite table. Le facilitateur, que ce soit vous ou quelqu'un d'autre, jette quelques feutres et quelques post-it sur la table. L'équipe commence à gribouiller ce qui a bien fonctionné sur les post-it verts et ce qui a moins bien marché sur les post-it roses. Ensemble, vous faites des listes et regroupez les post-it traitant des mêmes sujets. Rétro après rétro, les mêmes problèmes se dégagent et les actions ne sont pas suivies. Tout le monde perd foi, certains regardent leurs téléphones, d'autres ne viennent même plus et la plupart vous diront qu'ils préfèreraient être derrière leurs écrans.

Les rétrospectives tournent parfois au vinaigre, car n'oublions pas que l'on demande à l'équipe de parler de ce qui n'a pas marché. À chaque fois que la deadline n'est pas respectée ou que l'équipe livre plus de bugs que de fonctionnalités, elle le vit comme un véritable échec. Ce qui rend les rétrospectives encore moins plaisantes.

Si ceci sent le vécu, c'est qu'il est grand temps pour vous d'apporter un peu de fraîcheur à vos rétrospectives et d'en faire un vrai outil productif.

Qu'est-ce qui fait donc une bonne rétrospective ?

J'ai la chance de travailler dans une équipe où les rétrospectives sont animées à tour de rôle par tous les membres de l'équipe, ce qui implique tout le monde dans la démarche. Elles sont appréciées et souvent attendues avec impatience.

Mais avant de vous donner quelques exemples de rétrospectives réussies et de conseils pour que votre équipe profite pleinement de cet exercice, voici selon moi (et aussi d'après mes quelques lectures sur le sujet), les règles d'or pour établir un climat de confiance et créer un environnement où l'équipe peut échanger ouvertement.

Maintenant que l'on est d'accord sur le socle de la rétrospective, faisons en sorte qu'elle soit entrainante et efficace.

La référence en la matière est le livre de Diana Larsen et Esther Derby " Agile Retrospectives - Making Good Teams Great ", un savant mélange de théorie et d'exercices pratiques. Je vous le recommande vivement si vous voulez devenir " la reine (ou le roi) de la rétro ".

Toute rétrospective qui se respecte se compose de 5 étapes qui vous assurent un déroulé structuré, énergique et efficace :

Étape 1 : Ouvrir la rétrospective (Set the stage) Le but ici est de créer un bon environnement serein et motivant afin d'obtenir la participation de chacun.

Étape 2 : Recueillir des données (Gather data) Une fois la bonne humeur installée, il est temps de rentrer dans le vif du sujet. Essayez d'obtenir le plus d'informations possibles. Rassemblez les idées de tout le monde afin de comprendre réellement l'état d'esprit de l'équipe.

Étape 3: Générer des idées (Generate insights) Une fois les détails recueillis, il est temps de comprendre et d'analyser l'information. A ce stade de la rétrospective, vous devez établir des modèles et faire ressortir des tendances. Creusez et faites ressortir les problèmes. C'est uniquement en reconnaissant l'existence de problèmes que vous pouvez commencer à les résoudre.

Étape 4 : Décider des actions (Decide what to do) Maintenant que vous avez mis le doigt sur ce qui fait mal, vous devez vous y attaquer. Au lieu de faire votre liste d'actions au père noël, attaquez vous aux 2 ou 3 actions urgentes. Le plus important est qu'elles puissent être menées à bien pendant l'itération à venir.

Étape 5 : Clore la rétrospective (Close) Après avoir pris des mesures pour résoudre les problèmes soulevés, vous avez besoin de conclure. Il est important que votre conclusion soit impactante pour à la fois motiver l'équipe qui attaque une nouvelle itération et donner envie aux participants de venir à la prochaine rétrospective.

Vous avez maintenant entre vos mains le déroulé d'une rétrospective quasi-parfaite.

Où puis-je trouver des idées ?

Il y a beaucoup d'endroits pour vous aider à trouver des idées d'exercices et de jeux à faire pendant vos rétrospectives :

Le livre " Agile Retrospectives - Making Good Teams Great " mentionné auparavant peut-être un bon début.

Le site Plans for retrospectives qui vous génère des déroulés de rétrospectives de façon aléatoire pour les jours où vous devez aller vite et trouver un déroulé tout fait.

La rétrospective a aussi son wiki dédié.

Il faut néanmoins garder à l'esprit qu'il est important d'adapter la rétrospective aux besoins de l'équipe. Il faut être un peu psychologue, essayer d'entrevoir les problèmes et d'apercevoir les blocages rencontrés. Les déroulés tout-faits sont certes pratiques mais peuvent s'avérer moyennement efficaces s'ils ne collent pas avec l'esprit de l'équipe par exemple.
Et en bonus, un déroulé utilisé et approuvé

ÉCRIT PAR

Maria Frih

Product Owner - Food Lover - Startup enthusiast

# data[].attributes.attachment_link.description
Pourquoi la rétrospective ? En théorie, la rétrospective est l'occasion pour toute équipe agile d'analyser, pendant un court instant, ce qui s'est passé lors de l'itération. Elle permet aux participants d'améliorer leur collaboration et leurs méthodes de travail. Elle a pour but l'adaptation aux changements qui surviennent au cours du projet et l'amélioration continue du...

# data[].attributes.attachment_link.title
Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, Foreword by Ken Schwaber | The Pragmatic Bookshelf

# data[].attributes.attachment_link.description
Two of the software industry's leading facilitators have taken their many years of retrospective experience and distilled them into an approachable reference for agile team leaders. For all of the self-made facilitators out there who have been winging it, this book will provide a solid foundation to improve the effectiveness of your iteration, release, and project retrospectives.

# data[].attributes.attachment_link.readable_text
Pour le lancement du meetup Apéros Agiles à Nancy, je présentais les fondamentaux de la rétrospective agile.

La rétrospective dans le contexte d'un projet Scrum

Bien que l'outil "Rétrospective" ne soit pas réservé à Scrum, c'est bien dans ce contexte qu'il s'est démocratisé.

Alors que la démo est un exercice d'amélioration continue du produit que l'on est en train de réaliser, la rétrospective permet l'amélioration continue du processus de travail en commun.

En conséquence, les discussions sur le produit auront plutôt lieu lors de la démo, ou encore durant le sprint planning.

Avec la rétrospective, on se concentre sur ce qui a bien fonctionné et sur ce qui nécessiterait d'être amélioré au sein de l'équipe, dans la relation entre les membres de l'équipe et le product owner, dans la relation entre l'équipe du projet et le reste de l'organisation.

Un déroulé standard

Dans leur livre intitulé "Agile Retrospectives - Making Good Teams Great", Esther Derby et Diana Larsen proposent un déroulé standard d'une rétrospective.

Ce déroulé comporte cinq étapes :

Ouvrir la rétrospective

Rassembler des informations

Générer des solutions

Décider quoi faire

Fermer la rétrospective

Personnellement, je m'efforce de respecter cet agenda dans les rétrospectives que j'anime. Il a en effet l'avantage de "guider" les participants vers des contributions riches et constructives.

Je sais bien que cet agenda a l'air rigide quand on le lit comme ça, mais pour chacune des étapes il y a un nombre quasi infini de possibilités.

Découvrons les cinq étapes en détail.

Ouvrir la rétrospective

Durant cette première phase, le facilitateur (le scrummaster dans le cadre d'un projet scrum) annonce l'agenda, la période du projet sur laquelle porte la rétrospective, et s'efforce que chacun autour de la table prenne la parole.

Ce tour de table, je le fais de la manière suivante : je demande à tous les participants présents de me donner un mot, un mot qui, selon eux, est représentatif de la période observée (le sprint dans un contexte scrum). Les contributions peuvent déborder du cadre du mot seul, mais surtout, cela ne doit en aucun cas devenir un discours, ou partir en discussion. Les grandes discussions auront leur place plus tard dans la rétrospective.

Si l'un des participants ne prend pas la parole dans cette phase, inutile d'aller plus loin : il faut comprendre pourquoi il ne prend pas la parole, et résoudre ce blocage avant tout.

Rassembler des informations

C'est le moment où, quel que soit le format (ou presque), il est demandé aux participants de remonter des faits ou des ressentis relatifs à la période scrutée. Ici encore, point de discussion, mais ne vous inquiétez pas, ça arrive !

C'est peut-être dans cette phase de la rétrospective que l'on peut trouver le plus de variantes.

En voici quelques unes, mais Internet regorge d'autres exemples :

Les plus et les moins

"Mad Sad Glad"

"Keep-Drop-Start"

"Starfish retrospective"

Timeline

"Speedboat"

"Dixit retrospective"

...

Perso, j'ai une grosse préférence pour la rétrospective Starfish, que je trouve plus nuancée que d'autres formats plus binaires.

Générer des solutions

Enfin, on va pouvoir discuter ! Mais cette discussion, on le voit, est orientée solutions.

Le facilitateur aura comme tâche de prendre des notes au tableau de toutes les idées de solutions exposées par les participants.

Cette phase de la rétrospective s'apparente vraiment à un brainstorming "ouvert", en ce sens qu'il n'y a pas de bonnes ou de mauvaises solutions, le caractère réaliste de ce qui est proposé sera discuté dans la phase suivante.

Décider quoi faire

Dans cette phase, on "referme" le brainstorming, c'est à dire que les participants doivent constituer un plan d'action.

Ce plan d'action est bien entendu alimenté par les solutions listées plus tôt. Celles-ci sont potentiellement remaniées pour les rendre plausibles et réalisables, mais elles ont vu le jour lors du processus créatif proposé par le déroulé de pensée que l'on suit en s'astreignant aux étapes décrites par les auteurs.

Idéalement, le plan d'action ne doit contenir que 3-4 points pour que celui-ci puisse être mis en oeuvre durant le prochain sprint. Il peut être nécessaire de faire entrer certaines de ces tâches dans le suivi de Sprint pour faciliter leur prise en compte.

Fermer la rétrospective

Même les rétrospectives peuvent être améliorées. On leur applique donc les mêmes outils d'amélioration continue.

Personnellement, j'utilise le R.O.T.I. (ou Return On Time Invested) pour collecter les feedbacks des participants.

A main levée, chacun donne une note de 1 à 5 (1 = j'ai perdu mon temps, 3 = le résultat est à la hauteur de mon investissement temps, 5 = le résultat est bien supérieur à mon investissement temps), note que l'on discute ensuite en demandant notamment ce qu'il aurait dû se passer pour que la personne donne une note supérieure.

Avec ce dernier exercice, on "rattrape" potentiellement les dernières frustrations, les sujets non traités qui tiennent à coeur à l'un ou à l'autre. La parole est ainsi libérée, et chacun aura eu le temps nécessaire pour s'exprimer et être entendu par l'ensemble de l'équipe.

Conclusion

Après cet exposé, les participants ont pu poser des questions relatives à leurs propres pratiques de la rétrospective et exposer les problématiques qu'ils rencontrent dans leur contexte.

Nous avons ensuite fait une rétrospective de ce premier Apéro Agile et fixé un plan d'action pour les prochains événements (changement de lieu, suggestions de thèmes à aborder).

La rétrospective est l'outil par excellence de l'amélioration continue. C'est un investissement conséquent (selon la taille du groupe, une rétrospective efficace peut durer 1 à 2 heures), mais c'est un investissement pour l'avenir : d'une part, l'amélioration du système permet de créer des processus soutenables et durables, et d'autre part le cercle de parole permet de désamorcer les conflits potentiels et de réduire les tensions entre les personnes.

# data[].attributes.attachment_link.description
Pour le lancement du meetup Apéros Agiles à Nancy, je présentais les fondamentaux de la rétrospective agile. Bien que l'outil "Rétrospective" ne soit pas réservé à Scrum, c'est bien dans ce contexte qu'il s'est démocratisé. Alors que la démo est un exercice d'amélioration continue du produit que l'on est en train de réaliser, la rétrospective permet l'amélioration continue du processus de travail en commun.

# data[].attributes.headline
Lego4Scrum + Birdie Birdie = Birdie4Scrum

# data[].attributes.subject
Lego4Scrum + Birdie Birdie = Birdie4Scrum

# data[].attributes.attachment_link.readable_text
J'ai récemment animé une formation de 2 jours Agile-Scrum pour une des équipes que j'accompagne.

Je suis joueur, j'essaie au maximum d'agrémenter chaque apprentissage par un atelier type jeu d'entreprise.

Durant cette formation, pour illustrer l'organisation Scrum, je voulais faire un atelier avant la partie de présentation et surtout jouer le classique des classiques Lego4Scrum dont le but est de construire une ville avec des Playmobils (petit malin...) en passant à travers tous les concepts du framework.
Des personnes de l'équipe avaient déjà joué cette version. Il fallait donc ruser.

En discutant avec Christophe Keromen, j'ai appris qu'il jouait beaucoup le jeu Birdie Birdie ou un Lego4Scrum avec le backlog Birdie Birdie.
J'eu donc l'idée de fusionner les deux jeux afin de créer (je ne suis peut être pas le seul) le :
Birdie4Scrum

Birdie Birdie créé par Alan Cyment. Je me suis basé sur une traduction d'Alexandre Boutin (@agilex) que je remercie donc pour ce travail.

Lego4Scrum créé par Alexey Krivitsky et traduit dans la langue de Molière par Fabrice Aimetti (@Agilarium) and Sylvain Fraïssé (@sfui) que je remercie aussi

L'objectif de l'atelier

Construire un oiseau en Lego tout en intégrant les concepts Scrum.

Le background

Je suis le chef de produit (selon Birdie Birdie, l'animateur joue le Président) de la société TopToys dont le projet est de lancer un nouveau produit avec pour nom de code : MegaZozio.

Le jouet appartient à la ligne de produits " 153 " qui est un des fleurons de la société. Ce sont des jouets construits avec exactement 153 pièces assemblées (ce détail sera utile au moment du debrief et instruit la notion de gâchis du lean).

Organisation

Le Lego4Scrum se joue en 2h quand le Birdie Birdie peut être fait en un peu moins d'1h30, j'ai préféré garder le timing à 2h pour plonger l'équipe dans l'organisation Scrum malgré la densité de l'atelier, donner un peu d'air aux participants.

Comme le recommande Lego4Scrum, j'ai laissé les équipes se former, ils étaient 12 et leur ai donc demandé de créer 2 équipes de 6 en mélangeant leurs postes.

J'ai estimé le timing de la session comme suit :

Préparation : 15mn

Présentation du backlog : 15mn

Estimation : 5mn (x3 itérations)

Planification : 3mn (x3 itérations)

Réalisation : 8mn (x3 itérations)

Revue : 5mn (x3 itérations)

Rétrospective : 3mn (x3 itérations)

Débrief : 15mn

Total : environ 120mn (plus ou moins 2h en fonction de l'état des participants que vous êtes censé guider).

Démarrage du projet

J'ai d'abord présenté le background tel que décrit plus haut puis leur ai fait part du fait que j'allais leur fournir une liste de fonctionnalités. J'avais imprimé auparavant 2 fois le backlog du jeu Birdie Birdie pour que chaque équipe s'approprie les cartes

En tant que chef de produit, je suis le principal décideur sur le produit, il s'agit de mon produit (j'ai déjà dis produit ?) et je serai impliqué dans le processus de développement en étant disponible pour répondre aux questions et fournir mes feedbacks.

L'équipe a 4 itérations pour faire un bel oiseau. Sauf que, tel qu'énoncé dans le Birdie Birdie, l'équipe n'aura que 3 itérations (parce que le concurrent sort son produit plus tôt que prévu).

C'est un apprentissage du Birdie Birdie qui n'existe pas dans Lego4Scrum et que je trouvais vital pour tester la puissance de la gestion par la valeur métier de l'agilité vis à vis de la notion de time to market.

Construction du backlog

Là j'effectue un mélange des règles du Lego4Scrum et du Birdie Birdie, j'affiche sur un mur (j'ai bien sûr utilisé le kit du facilitateur pour ma formation) la liste des histoires de la première itération selon les recommandation du Birdie Birdie :

Iteration 1 : User Story 01 à 08 : Nom d'oiseau, Roues, Bec, Ailes, Initiale, Jambes, Hauteur, Tête

Iteration 2 : User Story 09 à 12 : Rangement, Couleur, Symétrie, Barrière

Iteration 3 : User Story 13 à 19 : Bébé, Remorque, Jambes Noires, Bicéphale, Queue, Yeux, Résistance

A la différence de Lego4Scrum, on n'affiche pas la totalité du backlog. La liste des demandes pour l'itération 1 n'est (à priori) pas faisable en 1 itération et va générer un décalage entre le demandé et le créé.

On représente bien le travail du gardien de produit qui présente les histoires prêtes à être présentée. On distingue dans les itérations suivantes ce qui a été identifié et ce qui a émergé des revues et des retours marketing (les nouvelles histoires entrées dans le backlog).

Chiffrage

J'ai repris le fonctionnement Lego4Scrum et ai opté pour la méthode Extreme Quotation pour ne pas perdre trop de temps. J'ai dessiné un tableau avec, en colonne : 1,2,3,5,8 et ai laissé l'équipe se débrouiller.

De manière instinctive, sans connaître le fonctionnement d'une phase de chiffrage, ils ont designé une petite histoire qu'ils ont positionné à 2 et une grosse à 8 et ont pratiqué le chiffrage par comparaison et HOP !

Pour aider l'équipe, demandez pour chaque histoire : ça vous semble gros ? Pas gros ?

Le but de la phase de chiffrage est aussi de challenger le product owner et lui poser des questions pour faire émerger des critères d'acceptance cachés (ceux de la liste du Birdie Birdie) donc incitez l'équipe à vous poser des questions pour mieux cerner la demande et valorisez ceux qui posent des questions.

Attention ! : Dans cette phase, assurez vous que l'équipe vous définit en tant que gardien de produit et non d'animateur (je n'ai malheureusement pas été assez clair et ai eu du mal à jongler entre les casquettes). En tant que chef de produit, vous êtes naturellement celui qui peut répondre aux questions fonctionnelles. En tant qu'animateur, l'équipe n'aura pas le réflexe de vous challenger. Soyez clairs dans votre posture.

Planification de l'itération

Toutes les histoires présentées sont chiffrées, il est temps de demander à l'équipe ce qu'elle pense être en mesure de faire dans l'itération.

J'avais dessiné le tableau Lego4Scrum pour les 4 itérations :

Lorsque l'itération est terminée, après la revue, remplissez la ligne "actuel" avec les points réellement fait (la vélocité de l'équipe) et n'oubliez pas aussi de noter la valeur métier générée dans un coin.

Après quelques itérations, votre tableau devrait ressembler à ça :

Bien sur la 4ème ligne ne sera jamais remplie MOUAHA MOUAHA MOUAHAHAHA

Itérations

Le temps de l'itération est fixée à 8mn, si vous le pouvez, affichez un grand chronomètre.

Normalement, la règle du Birdie Birdie demande à ce que l'équipe produise un visuel permettant au chef de produit de voir l'avancement. J'avais moi-même décidé de produire un kanban board "A faire", "En cours", "Terminé" et de placer les histoires dessus mais logistiquement, l'équipe n'arrivait pas à visualiser les critères et ont demandé s'il était plutôt possible de garder les histoires près de la zone de construction. Le tableau a vite été abandonné, j'ai juste demandé à ce qu'elles soient mises dans la colonne "Terminé" pour savoir lesquelles je devais passer en revue.

Revue

La règle du Birdie Birdie nous dit :

Les User Story disposent d'Acceptance Criteria incomplets dont certains ne sont pas forcément intuitifs (par exemple : le bec doit être ouvert). Et seul le facilitateur (le président) dispose de ces informations complémentaires. Le gardien de produit a des besoins définis mais ne sais pas exactement ce qu'il veut.

Une fois la réalisation terminée, le facilitateur passera voir le résultat de chaque équipe et acceptera ou refusera les User Story (sur la base de la totalité des Critères d'Acceptation).

Il répondra uniquement si un équipier lui demande explicitement " Pourquoi la Story est rejetée ? ". Il acceptera plus facilement de discuter régulièrement avec un représentant de l'équipe (type : Scrum Master).

Les critères d'acceptance manquants émanent du tableau Birdie Birdie :

Je n'avais pas designé de Scrum Master puisque je jouais le jeu avant de traiter la partie Scrum de la formation.

J'ai donc joué le rôle du chef de produit pour la revue et ai retoqué un paquet d'histoire. Le but est normalement de faire réagir afin que l'équipe pose plus de questions à la phase de chiffrage de l'itération suivante.

Point intéressant : j'étais assez mal à l'aise avec le fait de dire à des personnes dont l'habitude est d'avoir les spécifications les plus précises possible : " non je n'accepte pas l'histoire pour un critère que je ne vous avais pas donné ". Étonnamment, cet aléa a été totalement accepté par les participants et j'ai entendu des : " Tiens, on connait ça, typique du marketing ! ".

Retrospective

Laissez l'équipe gérer sa rétrospective et lui demandant comment elle pense pouvoir s'améliorer.

3ème itération

J'ai repris les règles de Birdie Birdie à la lettre :

3 minutes après le démarrage de la 3ème réalisation, le chef de produit interrompt toutes les équipes pour dire qu'un concurrent va lancer sur le marché un jouet concurrent de façon imminente et qu'il faut absolument commercialiser le projet " Mega Zozio " à la fin de cette itération.

Et là c'est la révélation pour les participants. Cet aspect que je n'avais pas retrouvé dans le Lego4Scrum donne tout le sens de la démarche de priorisation par la valeur.

Debrief

Bien sur, n'oubliez pas le debrief en vous appuyant sur les propositions de questionnement du Lego4Scrum et du Birdie Birdie, ça foisonne c'est parfait

Petits exemples :

Qu'avez-vous ressenti pendant ce jeu ?

Avez vous utilisé moins de 153 pièces ?

Qu'aurions-nous pu faire différemment ? (j'aime beaucoup cette question)

De quelle façon votre stratégie va-t-elle changer si vous savez que le Product Owner ne sera pas disponible pendant les sprints ?

Qu'avez vous appris ?

...

Mon feedback sur l'atelier

Bien séparer le rôle animateur/PO

Le gros point noir de l'animation a été de mal différencier mon rôle d'animateur et de PO donc soyez vigilants et clairs sinon l'équipe n'arrivera pas à appréhender le rôle du PO.

Essayez tant que possible de poussez les participants à vous questionner. Observation très intéressante : je suis allé voir une des équipes, qui ne me questionnait pas beaucoup, pendant la phase de réalisation, en leur précisant que j'étais disponible s'ils avaient besoin d'informations complémentaires. La réponse a été " non c'est bon, on se débrouille, on fait à notre façon "... mmmh intéressant.
Moralité, sur la dernière itération, j'ai refusé les ¾ de leurs histoires (soit 6 ou 7 histoires quand même).

Ce qui peut être très intéressant et formateur est de proposer en amont de la session de formation à un participant (la personne identifiée comme étant le PO de l'équipe ?) de tenir le rôle de Product Owner pendant l'atelier, vous lui fournissez la liste des histoires, le timing et les critères d'acceptance cachés et laissez faire la maaagiiiie.

Frustrer oui, punir non !

Il est important dans ce type d'atelier de générer de la frustration, c'est un élément moteur de l'apprentissage mais aussi du plaisir de jouer. Auriez vous autant de plaisir si les questions du trivial pursuit n'étaient pas difficiles ou piégées ? Mario Bros serait-il aussi amusant si certains sauts n'étaient pas millimétrés ?

Cependant, pour la première itération, j'ai demandé à ce que les constructions liées à des histoires refusées soient démontées. Grossière erreur de ma part, à mon avis.

D'une ça ne représente pas la réalité, de deux ça génère une sacré dose de frustration inutile. Je préfère que l'équipe soit frustrée parce qu'elle n'a respecté la demande et doit démonter la totalité ou partie de sa construction plutôt que parce que je leur demande directement de détruire leur travail.

Ne soyez pas avares en Lego

Prévoyez la dose de Lego, attention à la limitation technique en terme de couleurs et de nombre de brique, ça peut devenir un piège pour l'animation où vous allez devoir jongler entre les spécifications des histoires et la réalité du terrain (ça peut être intéressant comme ça peut compliquer l'apprentissage).

Rappelez vous aussi, le projet doit s'inscrire dans la chaîne de production 153, vous devez jouer avec cette notion à la fin du jeu pour savoir si les participants ont bien pris en compte cette notion de gâchis. Si vous n'avez pas assez de briques différentes en quantité, vous ne pourrez pas jouer avec cet apprentissage.

De la liberté

Ce que j'ai vu aussi, c'est qu'il faut parfois savoir flouer les règles pour avoir le produit le plus agréable. J'ai donc parfois fait fi des règles pour que les équipes produise un résultat qui me plaisait. Finalement c'était ma vision du produit.

" ICare " de l'équipe B

Je conseille aussi le billet d'Alexandre Boutin et son adaptation du Lego4Scrum

# data[].attributes.attachment_link.title
Lego4Scrum + Birdie Birdie = Birdie4Scrum

# data[].attributes.attachment_link.description
J'ai récemment animé une formation de 2 jours Agile-Scrum pour une des équipes que j'accompagne. Je suis joueur, j'essaie au maximum d'agrémenter chaque apprentissage par un atelier type jeu d'entreprise. Durant cette formation, pour illustrer l'organisation Scrum, je voulais faire un atelier avant la partie de présentation et surtout jouer le classique des classiques Lego4Scrum...