Retrospective with top management

Bonjour à tous,

Dans le cadre de ma vie professionnelle, je suis amené à être animateur de réunion Agile. Pour les équipes travaillant avec les éléments de la méthodologie SCRUM, ces réunions sont connues et évidentes. Je ne vais pas présenter dans cet article, l’intégralité de la méthodologie SCRUM…
(Cependant, si vous êtes intéressé par des formations SCRUM à vous ou à vos collègues : n’hésitez pas à me le faire savoir via la page de contact.)

Voici un article qui pourrait intéresser certaines personnes qui cherchent à avoir des pistes et un retour de rétrospectives avec des top-manageurs dans le cadre de « gros » projets (Programme / Projet stratégique / …)
Car oui, les manageurs sont curieux et veulent comprendre l’intérêt de l’agilité.
Et pour cela, rien ne vaut une rétrospective SCRUM pour faire :

• un constat permettant l’inspection,
• un plan d’action pour la suite pour l’adaptabilité,
• et le partage avec tous les acteurs du projet des deux précédents points, pour la transparence.

Pour mieux comprendre les piliers de la méthodologie SCRUM : « Les piliers et les rôles de SCRUM. » – https://www.unow.fr/blog/le-coin-des-experts/piliers-roles-scrum/

Voici donc mon retour d’expérience sur le sujet. En espérant que cela aidera certaines personnes.

Contexte de la réunion

Pendant une de mes missions, on m’a demandé de coacher une réunion ayant pour sujet de faire la rétrospective de la première vague d’un programme.
Cette première vague a duré 4 mois avec plus d’une cinquantaine d’interlocuteurs différents.

Plusieurs composants du SI ont été impactés, de nouveaux composants ont été également ajouté au SI de l’entreprise.
Plusieurs équipes de développeurs internes ou externes, de business analystes et de testeurs ont participé à la réalisation de cette première vague.
Des démonstrations de ces développements ont été réalisées auprès des utilisateurs finaux de l’entreprise.

Cette rétrospective concernait uniquement le top management du programme à savoir :

• Le directeur du programme et ces collaborateurs,
• La direction de l’architecture du groupe,
• La direction de la DSI via les responsables internes des différentes parties prenantes IT du programme.
• Les responsables des composants (impactés et ajoutés)

Cet évènement regroupait une vingtaine de personne et du à des contraintes de temps, il a été décidé que le temps de cette rétrospective serait de 2 heures.
Les personnes qui allaient participer à cette rétrospective n’avaient pas ou peu le « mindset » complet de l’agilité et de SCRUM.
Cependant, certaines personnes avaient déjà « vues » et « acceptés » les concepts de l’agilité sans pour autant le pratiquer.

Ayant déjà effectué en présence de certaines personnes du groupe précédemment cité des rétrospectives agiles, il m’a été demandé de refaire « le même format » pour le top management afin d’échanger sur les différents points de vues des interlocuteurs sur le programme et sur cette première vague.

Or, avec le top management d’un programme, une contrainte supplémentaire s’ajoute à la réunion.
Cette contrainte est très forte et elle est à prendre en considération : l’aspect politique et hiérarchique de chacun.

“La politique est une guerre sans effusion de sang et la guerre une politique sanglante.”

Si nous prenons les concepts prônés par SCRUM :

« Dans une rétrospective agile, l’aspect hiérarchique est a abandonner : chacun est égal et peut s’exprimer sur ses retours & analyses des dernières semaines / mois ».

Cependant, dans notre contexte, il est difficile de garder la neutralité nécessaire vis-à-vis de la hiérarchie de chaque participant.

Définition d’un programme et l’impact que ce dernier a sur la rétrospective

Avant de commencer à parler de l’organisation même de la rétrospective, je vais faire un retour rapide sur mon analyse d’un « programme ».

« Un « programme » est un projet informatique de haute importance dans une entreprise et qui impacte l’intégralité des couches d’un système d’information d’une entreprise : Front, Middle et Back. Il s’appuie sur un besoin complexe du business ». – Les définitions approximative de Paul FLYE SAINTE MARIE

En prenant cette définition, on en déduit que le déroulement d’un programme est toujours très complexe.

• Il y’a des équipes plus rapide ou plus mature que d’autre sur leur composant,
• Il y a des équipes qui sont plus souvent sollicitées que d’autres,
• Il y a des équipes plus matures que d’autres dans leur définition du backlog et dans le suivi des tâches.
• Il y a des personnes avec une vision de l’architecture plus complète que d’autred.
• Il y’a de meilleurs communiquants et des personnes plus rapides pour avoir une vision de ce qui bloque ou non.
• Etc …

La nature humaine fait que nous avons des capacités différentes sur des domaines différents et c’est tant mieux.

Si l’on prend ce constat, on comprend rapidement qu’il y aura donc des personnes plus ou moins satisfaites de la façon dont s’est déroulée ce programme. Il est cependant normal de partager ce retour d’expérience à tous pour trouver des solutions éventuelles pour « corriger le tir » pour la suite du programme ou pour les programmes suivants.

Dans le cadre d’intervenants issues du top management, l’avis de ces derniers vont analyser l’intégralité du programme. Le management par définition sert à gérer des équipes et des processus. Leurs compétences se trouvent justement sur le fait qu’ils savent gérer des processus et des équipes pour arriver à un objectif. Dans le cadre de ces réunions, il est naturel qu’il y ai des échanges sur cet aspect primordial d’un projet. Cependant, cette critique peut être contre productive dans le cadre d’une rétrospective.

En France (car je n’ai pas eu l’occasion de le faire ailleurs), la critique des méthodes, des processus, de la technique est normale et encouragée dans le cadre d’une rétrospective. Cependant, la critique du management et des personnes est à proscrire car elle peut amener rapidement à un « concours de baffes ».

L’objectif pour moi en tant que coach agile, est d’éviter cette confrontation entre chefs et de garder l’objectif de la rétrospective : déterminer les choses à améliorer, changer, garder.
Passons maintenant à la partie organisation de l’évènement.

Rétrospective avec le top management : Mode d’emploi.

Contexte et plan

20 personnes. Deux heures. Top management du programme, en Anglais.

Pour cela, je commence par préparer un slide de préparation afin d’expliquer le plan et le déroulement de la réunion. Je prépare le matériel nécessaire à la réunion.

Bien qu’il soit souvent dit que la rétrospective ne se fait pas avec un PowerPoint, quand il s’agit d’un groupe qui n’est pas formé à l’agile, quand il s’agit du top management et quand il s’agit d’un grand nombre de participants, il est important d’échanger sur les règles avant de lancer la véritable rétrospective.

Voici donc le plan que j’ai préconisé et suivi pour cette rétrospective :

Welcoming and presentation of the retrospective – 10 minutes

• Goals and rules – 5’
• Setup of the retrospective – 5’

Team time to exchange about the retrospective – 20 minutes

Writing post it about your exchange – 10 minutes.

Exchange time – 1h / 1h30

Vote – 10 minutes

Ce plan devait être simple, rapide et efficace.
Quelques règles en début de réunion : Les participants arrivent dans la salle, mais restent debout pendant l’explication.
Le rappel des règles est une chose primordiale et permet à tous ceux qui ne sont pas habitués aux rétrospectives agiles d’avoir une vision claire de ce qui va se passer pendant ces deux heures.
Il faut la faire rapide et précise.

Ensuite, on propose aux participants de former des équipes de 4 à 5 personnes mais en précisant qu’il est nécessaire de mixer les équipes.

Un coach agile se doit d’expliquer l’objectif de la démarche :
L’objectif est de ne pas former des blocs qui pourraient déjà avoir tous la même opinion. Elle permet également de mélanger des personnes ayant des positions hiérarchiques différentes dans le programme. Une fois les groupes formés et assis, l’objectif est que ces groupes fassent leur rétrospective ensemble avant de reporter leurs points à l’ensemble des participants.

On leur propose 20 minutes d’échange oral dans chaque groupe.

Il est possible que pendant cette phase, certains groupes ne savent pas par quoi commencer. Je leur mets à disposition une fiche permettant aux groupes de se poser des questions sur la précédente vague. Ce sont des questions qui doivent rester généralistes  et qui ne doivent pas avoir de rapport direct avec le programme en lui-même

Exemple de questions :

http://blog.lucidmeetings.com/blog/how-to-lead-a-successful-project-retrospective-meeting

Ensuite, chaque groupe peut écrire jusqu’à 15 post-it en sachant que j’impose un temps de parole de 2 minutes par post-it maximum.
Il est nécessaire de « timeboxer » l’ensemble du processus afin que la réunion se déroule dans les temps et que tout le monde puisse participer.

Pendant leur 20 minutes de réflexion, il est important de préciser quelques règles évidentes :

• Embrace a positive spirit of continuous improvement and share whatever you think will help the team improve.
• Don’t make it personal, don’t take it personally.
• Listen with an open mind, and remember that everyone’s experience is valid (even those you don’t share).

Axes de réflexion et d’échange

Les post-it doivent suivre l’un des 4 axes proposés.
Dans le cadre d’une rétrospective avec le top management, il est préférable d’éviter les colonnes classiques :

• Well
• Wrong
• Start / Improve
• Stop

Ces colonnes dans le cadre d’une équipe de développement peuvent aider les développeurs à s’améliorer en continu. Dans le cadre d’une rétrospective avec du top management, il est nécessaire de capitaliser sur les bonnes actions et les réalisations des différentes équipes et non pas s’attarder pendant des heures et des heures sur les problèmes rencontrés.

Si le top management remercie et aborde une approche bienveillante envers les équipes et félicite les initiatives, cela rassurera les équipes de développeurs sur leur travail et ça les investira pour la suite.
Si au contraire, le top management ne fait que remonter les problèmes rencontrés pendant l’itération et ne capitalise pas sur les réalisations, les équipes ne se sentiront pas ou trop peu soutenues et le moral des équipes s’en ressentira pour la suite du programme.
Également, la rétrospective a pour but de faire sortir les manageurs et les dirigeants de ce programme, de leur périmètre d’intervention.

Pendant les 20 minutes de discussions, chaque intervenant à l’opportunité d’aborder le travail de son équipe, de la vision qu’il a du programme et du management qu’il applique.
C’est un moment d’échange et de synchronisation des actions réalisées par équipes. Une fois ces 20 minutes passées, les 10 minutes suivantes permettent de remonter uniquement les faits les plus importants à partager à tous.

Pour cela, je propose les 4 colonnes/axes suivantes :

• « What worked well ? » : Identique à la version classique.
  L’objectif est de capitaliser sur l’ensemble des actions, processus qui ont bien fonctionné pendant cette première phase du programme. Cela permet aux participants de voir ce qu’il faut continue à faire pour la suite.
• « What are we going to try to do differently, to improve ? »
  Cette colonne regroupe les 3 colonnes habituelles d’une rétrospective (Wrong / Start & Improve / Stop). Cependant l’approche reste dans l’aspect positif et force les participants à réfléchir à des plans d’actions pour corriger les problèmes ou les points de blocage pour la suite du programme.
• « Thank you »
  Cette colonne est très importante ! Bien qu’elle semble très infantilisante, elle permet aux manageurs et aux responsables du programme de remercier certains aspects du programme. Elle permet également de détecter d’éventuels futurs points de blocage. Si le programme remercie particulièrement une personne d’une équipe / un processus ou un outil, cela signifie qu’un dysfonctionnement de ce processus ou de cet outil ou l’absence de la personne remerciée peuvent être un risque au bon fonctionnement de la suite du programme. Mais cette colonne permet aussi de remonter le moral des équipes et de les inclure dans la réussite du programme.
• « Good ideas »
  Cette colonne permet de remonter les idées émises par les équipes du programme pendant la période passée et qui pourraient les aider à la suite du programme. Elle peut révéler des idées simples à mettre en œuvre et qui peuvent aider très rapidement les équipes sur le terrain.

Avec ces 4 colonnes, il est très difficile d’effectuer des reproches personnelles et de s’attarder longtemps sur des dysfonctionnements : mais elle permet d’organiser la réunion sur l’idée simple de : « Bravo, maintenant que doit-on faire pour être encore meilleur ? ».

Dernière partie : le vote global sur la première « vague » du programme.

Ensuite, une fois que l’échange a été effectué, proposez un vote à l’assemblée sur cette première itération du programme. (0 => Programme horrible 🙁 ; 5 => Programme parfait 🙂 )

Le vote doit englober tout les aspects du programme :

• Le management,
• Les outils,
• La communication,
• Le développement
• Les processus de suivi
• Les reportings
• Les réunions
• Les personnes participants aux programmes
• Etc …

Cela permet au personne de donner leur ressenti globale sur le programme et ainsi, pour la prochaine rétrospective, permettre de savoir si la suite a été mieux ressenti que la première itération ou non. Une fois que l’ensemble des personnes ont voté, communiquez à tous la moyenne de ce vote afin que chaque participants puisse voir le degré de satisfaction sur le programme des participants à la rétrospective.

Constat et conseil

La réunion s’est très bien déroulée. Les manageurs et responsable du programme ont été satisfaits du format. Les échanges ont permis de remonter les points fort de cette première partie. Plus de 70 post-it ont été faits et les équipes ont été grandement remerciées pour leurs efforts dans la réussite du programme jusqu’à présent.
Cependant, j’ai pu constater certains dysfonctionnements à cette rétrospective

• Bien que la réunion ait eu pour but d’être le plus bienveillant envers les équipes et entre les participants, j’ai pu constater que certains sujets n’ont pas été abordées et ça a généré de la frustration chez certains participants de la réunion.
• La colonne « Thank you » a permis de remercier certaines personnes / équipes / outils / etc … , mais elle peut être utilisée aussi pour ironiser sur certains aspects du programme.
  Attention à ne pas généraliser cette approche !
• La hiérarchie du projet font que dans certains groupes certains participants ont plus de poids dans l’écriture des post-it que d’autres. Certains membres du groupe peuvent être amené à rester totalement en retrait à cause de cela
• Aucune action ne peut être réellement décidée pendant cette réunion.

En effet, il est impossible de prendre des décisions pendant cette réunion.
Il est nécessaire de laisser les responsables du programme réfléchir après la réunion pour voir comment faire pour résoudre les points remontés pendant cette réunion.
Le coach agile peut cependant accompagner les responsables à prendre des décisions sur le programme dans le cas où ces décisions vont dans le sens de l’agilité.

Quelques conseils pour vos prochaines retrospective avec le top management : 

• Si vous avez plus de temps pour votre rétrospective : n’effectuez pas cette forme de rétrospective. Il existe de meilleurs exercice qui correspondront mieux aux personnes issues du top management.
• Si vous n’avez pas plus de temps pour votre rétrospective : N’hésitez pas à expliquer la démarche de votre rétrospective avec les personnes clés du programme.
  Parlez leur de vos choix et également des pratiques à éviter (anti-patern) pendant la discussion afin que la réunion se déroule le mieux possible.
• Pendant les discussions des groupes : n’hésitez pas à proposer votre aide pour les aider à leur réflexion.
• Soyez agile et attentif à votre groupe :
  • Plus de 15 post-it pour un groupe ? Pas très grave si on atteint pas les 30 post-it !
• Rappelez que le compte-rendu qui sera diffusé après la réunion reprendra la vision d’ensemble et non pas l’avis individuel.
• Évitez de commencer votre réunion à 11h !
• Expliquez bien l’intérêt du vote aux top-manageur : ce n’est pas une note sur eux mais sur la globalité du programme !
• Communiquez à toutes les équipes qui ont participé au programme : le compte rendu de cette rétrospective.

En tout cas, pour moi, ce fut une excellente expérience !
Si vous avez des questions, des remarques, des idées à partager, n’hésitez pas à commenter l’article !