Premier PO DOJO, pour Nord Agile

Nous avons organisé avec Nord Agile le premier PO Dojo, une quinzaine de personnes ce sont essayées à l’expérience, je vous propose un petit résumé de la session.

Mais un PO Dojo c’est quoi ?

D’inspiration lointaine avec le coding dojo[EN] [voir les dernières activités], le PO Dojo à pour vocation de pratiquer les outils du quotidien du Product Owner. On peut y aborder le cadrage, le story mapping, l’écriture de user story, cette liste n’est biensûr pas exhaustive !

La force du PO Dojo est de réunir des PO d’horizons différents, c’est ce qui crée la qualité et la richesse des échanges.

Un google group existe, vous y retrouverez les différents retour d’expériences et pourrez également au contenu qui sont partagés à cette communauté. La soirée nord agile s’est concentrée sur l’écriture de User Story ou histoire utilisateur en français.

Pour les non initiés, une histoire utilisateur est une description courte d’une fonction d’un point de vue de l’utilisateur.

PO Dojo User Stories

J’ai suivi ce format :

  • Brise glace, avec le jeu des noms, que m’a fait découvrir @ojuncu, merci !
  • Constitution des groupes en binôme ou trinôme, mais pas plus.
  • Présentation (2 minutes) et sujet.
  • Première itération (15 minutes) : De l’idée à la user story
  • Deuxième itération (10 minutes) : Les critères d’acceptance
  • Troisième Itération (10 minutes) : Les tests d’acceptance
  • Cercle de clôture

Le timing est différent entre la première session et les autres pour prendre en compte le défrichage du sujet.

Chacune des itérations est clôturée par un feedback de chacun des groupes, la production de leur exercice et les techniques utilisées.  Les retours d’expériences de PODojo indique d’utiliser un temps restreint par groupe, dans notre contexte, cela n’a pas été nécessaire. J’ai ajouté un échange libre pour le groupe entier sur les surprises ou découvertes de l’itération. 

De l’idée à la User Story

“Le marketing descend de son bureau : j’ai une idée de tueur : j’aimerai envoyer un mail en différé pour faire croire à mon patron que je bosse alors que je suis parti boire l’apéro avec des amis”. A partir de ce sujet, les participants doivent en déduire les Users Stories. Je précise qu’en le faisant, ils peuvent prendre un peu de recul et analyser leur façon de faire. L’idée est d’orienter le débat sur les pratiques.

Les participants s’affairent, et voici les échos de chacun des groupes de cette première itération :

  • Certains utilisent le format En tant que <acteur>, je peux <action> afin de <objectif>
  • Certains reposent la question du besoin derrière cette fonction pour produire quelques alternatives à l’aide des “5 pourquois“. Je me dis que la session d’impact mapping y est certainement pour quelque chose !
  • Certains utilisent des techniques de brainstorming simple, ou en utilisant les mind maps.
  • D’autre des cartes Acteurs/Rôles
  • D’autres ont utilisé des cartes de thématiques.
  • D’autre ont déjà sauté un cap en creusant la user story avec des tests d’acceptance.
  • D’autres font valoir les incréments fonctionnels, en ayant les perspectives techniques de réalisation en tête.

Concernant les US, elles reflètent la notion de template de mail, d’historique, d’annulation, de validation de l’envoie ou encore un accusé de réception…

Voici les retours du deuxième cercle de feedback :

  • Les participants sont stupéfaits par l’imagination et le nombre idées qui ont émergées.
  • Certains saluent l’idée de prendre un pas de recul par rapport à la fonction demandée pour en recreuser le fond.
  • Certains repose quelques questions de compréhension de pratiques exposées.

Les CRITERES d’acceptance

Les participants doivent prendre une US et en écrire les critères d’acceptance, je les définis comme suit : “D’un point de vu client, comment peut-on accepter une US ?”

Voici la production de chacun des groupes :

  • Certains ont posé les points de vérification pour identifier les faiblesses potentielles.
  • D’autres ont cité des scénarios d’utilisation.
  • D’autre on fournit des scripts de vérification
  • Certains ont utilisé le “Behaviour Driven Development” avec le Given When Then

Voici la deuxième boucle de feedback

  • On observe des niveaux de granularité différents entre les groupes : d’une description synthétique de quelques mots à des scénarios très détaillés.
  • On identifie un écart de perception entre critères d’acceptance et tests
  • Une proposition d’un participant : “Ce sont les éléments menant au succès pour une US”

Les TESTS d’acceptance

Les participants doivent dans cette itération écrire les tests d’acceptance de leur US.

Voici les retours des groupes :

  • Certains utilisent des arbres conditionnels pour les différents cas de figure
  • D’autres utilisent le AAA (arrange/act/assert)
  • L’écriture des tests à induit l’écriture d’autres user stories.
  • Les tests mettent en avant les différentes responsabilités fonctionnelles, pour un cas il est nécessaire d’avoir des fonctions en prérequis.

Deuxième boucle de feedback

  • On se rend compte qu’un critère d’acceptance peut être dérivé en de nombreux tests.
  • La notion de “test après est évoquée”, j’en profite pour parler très brièvement du “test avant”, en évitant de changer ma posture dans cet atelier.
  • “Les tests sont l’implémentation de critères d’acceptance”
  • Un sentiment de facilité par rapport à l’élaboration de critères.
  • Quelques citations :
    • “Les tests d’acceptance sont l’implémentation des critères d’acceptance”
    • “Les critères d’acceptance sont le QUOI et les tests le COMMENT”

Sur ce dernier point, un débat s’est improvisé rapidement : “Qui chez vous écrit les tests d’acceptance ?”

La clôture

Pour terminer les échanges, nous avons formé un cercle, et fait passer un bâton de parole (merci @nelson_dufosse ;). Voici la question posée : “Qu’avez-vous apprécié ? Qu’avez-vous appris ce soir? Y-a-t’il des éléments que vous allez reprendre ou appliquer prochainement ?”

Et voici les réponses :

  • “L’exercice m’a permis de découvrir concrètement les user stories, c’est concret, facile et très accessible.”
  • “J’ai découvert le BDD.”
  • “J’ai apprécié avoir des retours concrets et les questions de fond sur le sujet”
  • “J’ai vu des techniques concrètes, que je réutiliserai”
  • “J’ai mis en pratique les user stories, je me rend compte que c’est un peu comme cela que je fonctionne au quotidien.”

La vision du facilitateur

J’aime ce genre d’atelier car c’est toujours très riche de retours, et je suis ravi d’avoir vu toutes ces techniques agiles exposées : les participants créent et partage la connaissance. Le rôle du facilitateur est d’assurer la conduite de l’atelier, de ces différentes étapes.

Cet atelier à un très bon ROI du point de vue préparation !  Je pense même qu’en reproduisant l’exercice, le rôle de facilitateur peut s’effacer pour atteindre l’auto-organisation comme pour les coding dojos. Il reste à introduire une récurrence pour cela… affaire à suivre.

D’un point de vue contenu, je note les définitions propre à chacun quand l’on parle du test, et la frontière entre critère d’acceptance et tests la frontière peut être mince… Il s’agit pour ma part d’un simple problème de langage, au delà des termes il faut repartager le pourquoi des tests et se mettre d’accord avec les différents intervenants du projet.

Ne soyons pas dogmatique et faisons en sorte d’assurer le flux des US dans les projets, en ayant levé les ambiguïtés au plus tôt.

Je remercie énormément la communauté du PODOJO pour leur retours d’expériences, et les éléments de synthèse qui ont grandement facilité la prise en main de l’exercice : M.E.R.C.I !

 

 

 

 

Le jeu de l’amélioration : du concret !

Le jeu de l’amélioration ou  perfection game permet de donner du feedback de manière positive. Je l’ai utilisé avec succès à de nombreuses reprises : pour une rétro de sprint, pour une réunion, pour un document de spec ou de lancement pour n’en citer que quelques-uns ! Même pour du feedback “à chaud”… mais c’est un autre sujet.

Ce billet met le focus sur un exemple très TRES parlant, prenant pour source un billet de ce blog. Il vous donnera les clefs pour prendre en main le jeu de l’amélioration !

Le perfection game ?

Voici très succinctement le déroulement :  “je te donne X/10 car j’ai apprécié cela et cela… Pour avoir 10, il faudrait faire X ou Y”. Vous pouvez utiliser le visuel suivant, il est la traduction de l’original de Yves Hanoulle complété par des exemples cités ici :

Image

D’un apriori simple, il crée un contexte constructif pour les participants, cela évite le phénomène de “bureau des plaintes”, que l’on peu rencontrer avec le speed-boat par exemple. Notez que ce n’est pas un défaut, cela peut être important dans certaines situations (non dits, fatigue générale, blocage hiérarchique…), le coté ludique permet de “vider son sac” et passer à autre chose rapidement.

L’exemple

J’ai eu l’occasion d’échanger sur le sujet avec Guillaume Duquesnay, dont je vous conseille le blog. Il m’a gentiment donné le feedback, sur la mise en oeuvre du Lego4Scrum. A sa lecture, je me suis dis “c’est l’exemple parfait du perfection game !” : positif et très motivant, qui montre également l’évolution de cette pratique, c’est pourquoi je vous le partage :

J’ai apprécié

– découverte nouveau jeu
– retour totalement concret, basé sur retour d’expérience, 0 théorie, 0 bullshit
– conseils pratico-pratiques pour les petits moments délicats (debrief, etc), ça met en confiance pour animer l’atelier = j’ai envie de l’animer, je me sens totalement de le faire
– style bien équilibré, convivial mais pas familier, ça reste pro
– l’exemple des managers à la fin ancre de manière narrative un des intérêts de l’exercice. Moi aussi j’ai fait “tilt !” sur l’intérêt de l’exercice
– l’adage “20 personnes ont plus d’idées…”, etc

Pour aller plus loin

Plus de contexte, plus autoportant
– lors de l’intro, donner des exemples des cas d’application que tu as expérimenté au cours des 2 ans. Ainsi je comprendrais mieux le cadre de ton retour d’expérience
– ajouter un résumé de l’exercice en 2-3 phrases / 10 lignes (but, principe, etc). je ne connaissais pas l’exercice, et je n’irai pas lire les slides de référence (pas envie / pas prévu d’en prendre le temps / c’est toi que je veux lire, pas l’autre gars). Sans cela, j’ai eu du mal à raccrocher les morceaux, ça m’a demandé pas mal de cerveau disponible (je me suis dit, c’est comme un XP game). 

Plus de lisibilité

Je pense que ton article est un article pratique et sera parcouru ou reparcouru en diagonale, donc 
– ajouter des photos des éléments que tu cites, pour faciliter le parcours visuel, aérer le texte, et ancrer l’image de l’exercice. Par exemple les post-its, les legos, etc. Même un dessin à la rache ça le fait toujours
– ajouter des sous-titres ou des bullets point pour distinguer la nature des éléments que tu donnes. Exemple : liste des besoins, liste des astuces sur un sprint, liste des pièges, etc

Encore plus de concret

– encore plus de narration comme avec les managers, même en quelques mots. Encore plus de citations comme “20 personnes ont plus d’idées…”, etc

Et pour finir

– tu précises que le planning poker c’est pas bien ! (cette touche est tout à fait personnelle :D)”

Suite à ce retour, j’ai changé ma façon de faire !

Maintenant, je pose les questions suivantes :
  • “Qu’avez-vous apprécié ?”
  • “Que faudrait-il pour que ce soit parfait ?”
  • “Que doit-on faire pour que ça DECHIRE ?”

J’ai le sentiment que cela donne ce petit truc fun, qui incite d’autant plus les gens à répondre quand le feedback est effectué par mail !

Et vous, comment utilisez-vous le jeu de l’amélioration ?

[Encore merci Guillaume, promis la v2 de l’article est pour bientôt !]

“pre-mortem”, le contrepied du drame pour éviter la catastrophe !

Les livres “Gamestorming” et “Innovation Game” sont de vraies mines d’or. Je n’ai cesse d’utiliser et de revendiquer les “jeux” qui y sont présentés. Le graal étant d’enchainer ces jeux pour répondre à un besoin particulier comme lors d’un lancement d’équipe par exemple. On utilise alors des jeux pour l’ouverture, d’autres pour l’exploration, et des jeux pour converger vers quelques actions.

Ce qui m’intéresse dans ce post, c’est d’aborder deux jeux qui s’appuient sur une même particularité cognitive, pour desservir des but différents !

Imaginer le futur, c’est compliqué !

De nombreuses études en psychologie cognitive ont examiné la façon dont nous pensons à l’avenir. […] Il est plus facile de comprendre et de décrire un événement futur rétrospectivement que d’aborder un futur possible. (en anglais dans le texte ).

 

Exercice 1 : Envisager le panorama de la mobilité dans 10 ans… Dites-moi à quoi ce dernier va-t-il ressembler ?

[… le temps d’une réflexion …]

Différents futurs sont imaginables, il nous est difficile de nous projeter. Imaginez cette question posée à un groupe, vous aurez autant de réponses que de participants.

Changement de contexte, avec l’exercice 2 :  Nous sommes le 20 mai 2024, le journal télévisé annonce le succès de la société Appoïd, qui détient maintenant le monopole mondial des périphériques mobiles ! Comment y-sont-ils parvenus ?

[… le temps d’une réflexion …]

Les scénarios ne s’enchaînent-t-ils pas dans votre tête ? Incroyable non ? Nous donnons le choix d’un seul futur possible, sur lequel les différents arguments vont pouvoir se construire.

C’est LE truc. Cela permet d’aligner les idées d’un groupe sur un objectif commun, la productivité s’en trouvera boostée !

Jouons !

Les ouvrages référencent deux  jeux qui exploitent cette “faille”.

Le premier peut-être vu comme un rétro-planning ludique :”remember the futur” de “Innovation games”. On positionne le succès du projet, en prenant soin de décrire les critères de cette réussite. Ensuite, on remonte le temps pour identifier quelles ont été les actions et leur date de mise en oeuvre.

Le deuxième, vise à identifier les difficultés potentielles et d’en prendre le contrepied : “Pre Mortem” de “Gamestorming”. On positionne l’échec du projet, et on cherche à se rappeler des événements et des causes qui nous ont amener à cette catastrophe ! Cela peut refroidir de prime abord en lancement de projet, mais cela remet bien les choses à plat ! Il ne faut pas oublier, qu’au delà de l’énergie positive que peut générer un tel moment, la route n’est pas toujours un long fleuve tranquille !

Les conseils

La magie de l’exercice se joue dans l’introduction, il faut pousser les gens à faire le “décalage mental”, user des détails pour faciliter l’appropriation de ce futur.

Ce futur peut être dans quelques semaines, quelques mois ou quelques années en fonction du problème traité.

Si vous êtes dans un contexte IT, sortez-en ! Identifier les points liés à l’organisation, au changement, à la formation, à la transition, au démarrage…

Vous avez pratiqué cet exercice ? Parlez-en dans les commentaires !

 

Lego4scrum, deux ans après…

Je vous propose dans ce billet, de détailler le Lego4scrum créé par Alexey Krivitsky. Il s’agit d’une simulation de 3 itérations d’un projet pour une durée de 1h30 à 2h. Le développement logiciel est matérialisé par la construction avec des légos qui le rend extrêmement ludique ! Cela rend le jeu accessible à tous les publics (DSI, CP, Dev…).

L’idée n’est pas de décrire l’atelier, les supports remplissent parfaitement ce rôle. Je vous propose un retour sur plus de 2 ans de pratique.

Attention, ne lisez pas ce billet si vous n’avez jamais fait l’exercice😉

Quand utiliser cet atelier ?

  • En découverte : l’idée est de supprimer tous les termes agiles de l’atelier, cela provoque le vécu, et vous pouvez y faire référence lors d’une formation par exemple, cela crée le “Tilt”. Cet atelier permet aussi la prise de conscience !
  • En fin d’apprentissage : inversement, vous pouvez laisser plus de marge de manœuvre aux participants, pour qu’ils réappliquent les compétences acquises.
  • En feedback sur une équipe : en coaching, même si l’Equipe est déjà coutumière de tous les artéfacts, cela permet de prendre du recule par rapport à leur pratique.

L’atelier se déroule comme suit

  • Une phase de construction de la liste “des choses à faire”
  • Une phase d’estimation
  • 3 sprint de 6 minutes (planification, réalisation, revue), suivis d’une revue des éléments réalisés.

le matériel suivant sera nécessaire :

  • Post-it et petits post-it.
  • 1 feuille de paperboard pour le backlog
  • 1 feuille de paperboard pour l’estimation en couloir
  • 1 feuille de paperboard pour le reporting
  • Des feuilles de paperboard pour les participants et pour la “prod”.

Pour la phase préparatoire, je m’arme de post-it sur lesquels j’adjoins un petit post-it. Vous comprendrez pour la suite. J’y dessine 2 cases, une pour la valeur métier, l’autre pour l’effort.

Le lancement

Je fais en sorte de “sortir du cadre” habituel, pour cela, j’utilise deux slides d’introduction.

  • Le premier présente un titre très “pompeux” du style “Réflexion autour de nos méthodes et outils dans le cadre….” Le genre de titre, qui, présenté à 13h30, digestion oblige, vous appelle au sommeil😉
  • Le deuxième slide est un gros panneau STOP ! “Nous allons prendre un peu de recul, avec un atelier ludique”

Pas besoin d’aborder le coté réflexion, cela vient naturellement avec le jeu.

J’attaque le speech, et j’insiste fortement sur :
“Un projet commun, une Equipe constituée de plusieurs groupes”
“Je suis le Maire, je décide, posez moi les questions”

La phase préparatoire

Je retire j’essaie de retirer tous termes agiles, ainsi, on évite les aprioris sur le sujet.

J’explique ma vision du projet Vision globale, en mettant un petit point sur l’importance du pourquoi... Ainsi, chacun des participants peut-être force de proposition dans l’objectif. On co-construit donc les éléments. C’est un mini workshop d’écriture de user story. Attention à ne pas trop laisser de temps sur cette phase, la gestion d’un nombre important de propositions est un frein pour la suite de l’atelier.

Pour la mise en commun, je fais une sorte de story mapping simplifier (des références ici et ). Ce faisant, j’introduis l’utilité d’une telle pratique sur un projet, pour un démarrage ou une reprise. Le but est d’avoir une ville cohérente, avec des priorités claires. J’explique l’importance du juste détail pour permettre la visualisation globale et les ajustements.

Par exemple : Construire une ville en oubliant l’infrastructure, créer le lotissement avant d’y mettre les maisons…

L’illustration de la co-construcion est sans équivoque : il y a toujours des items auxquels je n’aurais pas pensé. On connaît l’adage “Il y a plus de choses dans la tête de 20 personnes que dans une seule”, mais imaginez concrètement ce que cela peut donner sur vos projets.

J’attribue des valeurs, de 1000 à 50 en fonction de l’importance.

Je fais faire la somme des valeurs d’estimation par les participants, je note cela sur le paperboard du reporting. Toutes les tâches qui peuvent être déléguées sont bonnes à prendre, cela fluidifie votre intervention.

La phase d’estimation

J’introduis la notion d’estimation relative, en expliquant les avantages. Je fais une démonstration avec un jeu de planning poker, et explique ensuite comment optimiser le process avec les “couloirs” (bien présenté dans le support). Retrouvez sur ce billet des pratiques d’estimation pour en reprendre le sens.

Je prends une ou deux personnes de l’assemblée pour faire l’estimation relative de tous les éléments. Pour faire cela, nous détachons les petits post-it des grands, pour garder le story mapping priorisé en place.

A la fin, pour les éléments que les participants ont du mal à estimer, je donne de brèves indications “deux maisons de large…” et clos le débat en positionnant les éléments.
Cela porte parfois à Caricature et c’est l’ambiguïté entre l’animateur du jeu et le rôle de product owner…
Mais sur le ton de l’humour cela passe généralement bien.

Une fois de plus, je fais appel aux participants pour l’addition des points d’effort, je note cela sur le board de reporting.

Dans la plupart des cas, presque aucune question n’est posée sur le comment développer les choses. En d’autres termes, les gens se lancent dans l’estimation sans avoir les infos😉

C’est à ce moment, que j’aime prononcé la phrase suivante : “Il est temps de passer aux choses sérieuses” et je sors les boîtes de Légos ! A ce moment du jeu les participants sont engagés, même s’ils sont surpris par les Légos, vous évitez les réactions épidermiques.

Les sprints

Pour la planification, il faut dédramatiser, les pousser à se jeter à l’eau. Pour faciliter je demande un responsable d’équipe et le pousse à me donner leur engagement… “Allez, 30 secondes pour me donner un chiffre”. [ça vous rappelle quelque chose ? des soirées de propositions commerciale ou il faut jeter les dés ?]

Je choisis les éléments à réaliser et demande si les équipes veulent bien s’engager.

On théâtralise un peu le choix cornélien des priorités par le product owner et la réalité en terme de ROI/Coûts/Risque/apprentissage.

Au top ils se lancent tous comme des fous, retour à l’enfance, l’ambiance est à la rigolade et les participants apprivoisent les Légos.
Je pars sur 6 minutes au lieu de 7, ça mets plus la pression, et je la mets continuellement “plus que x minutes”.

10, 9, 8, 7, 6, 5, 4, 3, 2, 1…. Mais où est ma ville !!!

Il est temps d’effectuer la revue, et dans 9 cas sur 10 la prod a été oubliée ! L’espace de production est indiqué lors de la distribution des espaces et des Légos.

Je fais la revue des éléments produits. Je prends un air caricatural en en forçant un peu le trait pour ajouter du fun à la scène.

C’est généralement la déconfiture !
Il ont tous essayé quelque chose qui n’est absolument pas ce que j’avais en tête ( et même si c’était le cas je changerai ce que j’ai en tête🙂

Un réflexe courant :

Participant : Mais tu ne nous a pas dit ce que tu voulais !
Animateur : Mais tu ne m’as pas posé la question !

Les éléments acceptés sont généralement proches de 0.
Je propose 2 minutes de rétrospective LIBRE, en leur demandant de choisir une action sur laquelle s’animer.

Deuxième sprint

Dans la plupart des cas, le PO est pris d’assaut ! Préparez-vous !
Les choses s’arrangent, certains patterns apparaissent…

A l’inverse du premier sprint, on passe en déploiement continu naturellement et cela dans plus de 80% des cas… Mais sans forcément l’aval du PO !

La revue est plus clémente, il reste des éléments à revoir.
La confiance commence à se ressentir, on voit par exemple des éléments faits qui n’étaient pas demandés.
C’est à dire qui faisait parti des éléments du backlog, mais qui n’était pas dans les priorités du PO.
Le score décolle, je reporte les éléments effectués (point d’effort en burndown et valeur en burnup, sur un même schéma avec deux couleurs)

Pour la rétrospective, je prends les choses en main (j’ai observé que les gens n’ont pas l’habitude de cet exercice et on donc du mal à sortir quelque chose, un ouvrage à creuser : getting feedback ?) :

Voici des exemples de questions :

  • Avez-vous respecté les actions sur lesquelles vous souhaitiez vous animer ?
  • Où avez-vous perdu du temps ?
  • Quelles étaient les difficultés ?

Voici quelques exemples d’actions concrètes

  • Organiser les Légos par couleur
  • Validation au fils de l’eau
  • Les gens se mettent en commun pour mutualiser l’ensemble des Légos
  • Le travail “a faire ensuite” est ajouté par le PO (pour éviter que certaines personnes ne tournent en rond).

Troisième sprint

Les équipes trouvent leur vitesse de croisière, les actions de rétrospective fonctionnent,
le score explose au grand bonheur de chacun mais surtout à leur grande surprise.

Je reporte les éléments sur le board de reporting, et explique comment la capacité de
réalisation peut nous servir pour effectuer des projections (date de fin,
importance de travailler sur ce qui a de l’importance, négociation des points de fonction…

Le débrief

C’est la partie à ne pas négliger, peaufiner vos questions au fur et à mesure que vous pratiquez.

Voici quelques unes des questions marquantes :

  • Que ce serait-il passé si nous avions utilisé 18 minutes au lieu de 3×6 minutes ? [Marquez un blanc et observez la tête de chacun des participants]
  • Quels sont les comportements qu’ils ont observés ?
  • Que pensent-ils de le rétrospective ?
  • Comment établir les critères d’acceptance avant de développer ?
  • Qu’apporte le management visuel ?

L’anecdote

Le contexte : une horde de chef de projet manageant principalement des centres de service.
Les échos/réflexions étaient assez négatifs, les phrases comme “il comprennent jamais rien”, “ils sont toujours à coté de la plaque” j’en passe et des meilleures (en d’autre termes, qui ne passent pas sur un blog😉.

L’efficacité de l’atelier faisant rage, nombreux sont ceux à tombé dans le panneau !

A ce moment précis, je vois le visage d’un des chefs de projet se transformer. Il y a des moments où, l’on reconnais le “tilt” de la compréhension par l’illumination d’un visage. A ce moment précis, son visage est devenu sombre, ce qui m’a scotché…

Je l’ai vu comprendre que le problème n’était pas les équipe de sous-traitance mais bien leur mode de fonctionnement !

Un moment rare, qui me restera gravé !

N’hésitez pas à communiquer vos retours sur info@lego4scrum.com et dans les commentaires de ce billet !

 

Une rétro sur les chapeaux de roue !

Du simple “à ne plus faire, à garder, à améliorer”, jusqu’aux serious games, il existe de nombreux formats pour animer des rétrospectives.

Mais à chaque fois, j’ai constaté des débuts timides : les participants rencontrent des difficultés à générer/identifier les points de “contention”.

Pour palier ce syndrome de la feuille blanche, j’ai “testé pour vous” le lancement d’une rétro avec un brainstorm.

Etape 1 : indiquez à chacun des participants de nommer un mot quant à l’organisation du projet, et de tous les artefacts qui le composent.

Dans l’exemple :

Sprint
Estimation
Planning
Test
Daily
Périmètre
Démo
Définition de terminé
Dashboard
Spécification

Inscrivez ces mots, de manière à ce qu’ils soient visibles de tous.

Etape 2 : Lancez la phase de réflexion individuelle  (option sur post-it avec 2 couleurs : une pour le positif et une pour le négatif, c’est encore mieux !).

Etape 3 : Passez à la mise en commun. Dans le déroulement, nous avons opté pour Xmind, avec un écran partagé, afin d’éviter la partie fastidieuse du compte rendu😉

Un moyen très simple et très rapide pour dynamiser vos rétros !