La matrice des compromis : en cas de problèmes, qu’ajusterons-nous ?

En formation Scrum, nous discutons également de la gestion de projet. Et notamment des coûts, délais et scope. Dernièrement, alors que nous abordions ces sujets, un participant m’a parlé d’un outil que je ne connaissais pas et que j’ai adoré: « La matrice des compromis« . J’ai proposé à ce participant d’en faire un billet et il a, à ma grande joie, accepté. Ce billet est donc l’œuvre d’un blogueur invité, Jacques LABATTE.

Le monde de l’IT n’échappe pas à la règle : nos clients sont exigeants ! Ils veulent des applications capables de tout faire, et cela au meilleur prix, et dans les meilleurs délais.

Dans ce cadre, un grand nombre de projets démarrent avec un triptyque (coût, délai, périmètre) difficile voire impossible à tenir. Et lorsqu’il est tenu, c’est parfois au détriment de la qualité.

Triangle des contraintes
Triangle des contraintes
Project resolution from 2012 CHAOS research
Project resolution from 2012 CHAOS research

Le « CHAOS Report » du Standish Group, publié en 2012, montre que seuls 39% des projets informatiques sont réalisés à temps, au coût prévu, et avec le périmètre fonctionnel attendu. A l’inverse, 43% des projets informatiques sont livrés hors délai, avec un surcoût ou un périmètre inférieur à celui attendu.

16 années d’expérience dans le monde de l’IT m’ont appris que le « tout-figé » (date de livraison, budget et contenu fonctionnel) au démarrage d’un projet informatique est clairement utopique.

Dès lors, il est préférable de connaître nos variables d’ajustement dès le démarrage d’un projet et surtout de les partager avec tous les acteurs du projet, plutôt que de se poser ces questions lorsque le projet sera en crise !

La matrice des compromis est un outil qui offre une représentation simple des variables d’ajustement d’un projet. Compréhensible par tous, elle fait partie intégrante de la charte du projet.

Elle identifie la contrainte forte d’un projet et quelles seront les variables d’ajustement en cas de dérive. Elle peut être éventuellement revue en cours de projet en fonction de certains évènements : rallonge ou coupe budgétaire, nouvelle urgence de livraison, …

Exemple de matrice des compromis
Exemple de matrice des compromis

Clefs de lecture :

  • La règle de remplissage est simple : une seule croix par ligne et par colonne !
  • La qualité est systématiquement fixe, car elle ne doit jamais être une variable d’ajustement.
  • La contrainte forte du projet est par définition ferme. Elle permet de savoir si le projet est piloté par le coût, le délai, ou le périmètre.
  • A l’inverse, la contrainte du projet la plus flexible est celle qui changera sûrement. Elle identifie le type d’arbitrage qui sera effectué prioritairement en cas de dérive sur le projet.
  • Si les premiers arbitrages ne sont pas suffisants pour redresser le projet, il est alors possible d’arbitrer ce qui pourrait changer.

Remarque : Les contraintes d’un projet sont forcément liées. Par exemple, un projet qui décale une date de livraison pour terminer le périmètre attendu est un projet qui va coûter plus cher puisque l’équipe continue à travailler sur une période de temps supérieure à celle qui était initialement prévue.

Panorama des différentes configurations possibles :

1) les projets pilotés par le coût (coût ferme) :

Matrice 1.A
Matrice 1.A
Matrice 1.B
Matrice 1.B

Ces projets sont réalisés avec une enveloppe budgétaire non négociable. C’est le cas lorsqu’une entreprise alloue chaque année une enveloppe budgétaire permettant de traiter les demandes d’améliorations les plus prioritaires d’un produit. Pour ces projets, qualifiés de « budget-box », c’est en général le périmètre qui sera arbitré en premier (matrice 1.A). Le périmètre non embarqué sera éventuellement priorisé au sein d’une version ultérieure.

2) les projets pilotés par le délai (délai ferme) :

Matrice 2.A
Matrice 2.A
Matrice 2.B
Matrice 2.B

Ces projets sont à livrer à une date donnée, qui ne peut pas être décalée (livraison indispensable avant Noël, fonctionnalités attendues par d’autres projets, eux-mêmes en délai contraint, etc). En cas de dérive, une première solution est la diminution du périmètre fonctionnel (matrice 2.A), à condition que ce périmètre diminué reste viable (il peut partir en production). Une autre solution peut consister à renforcer l’équipe (matrice 2.B) pour tenir à tous prix le délai (attention, renforcer une équipe n’apporte jamais la garantie de sauver un projet)

3) les projets pilotés par le périmètre (périmètre ferme) :

Matrice 3.A
Matrice 3.A
Matrice 3.B
Matrice 3.B

Ces projets sont fréquents dans les entreprises du monde bancaire qui doivent produire de nouvelles fonctionnalités pour répondre à des directives européennes (projets réglementaires). En cas de dérive, l’équipe va devoir malgré tout implémenter le périmètre en entier, quitte à décaler dans le temps sa mise en production (matrice 3.A). Ce décalage aura aussi un impact sur le coût. Une autre solution consiste à renforcer l’équipe, et donc à augmenter le coût du projet pour limiter au mieux le retard de livraison (matrice 3.B).

Exemple de matrice des compromis générée lors d’une réunion de lancement projet
Exemple de matrice des compromis générée lors d’une réunion de lancement projet

A propos de l’auteur : Jacques LABATTE

Photo_Identite

Ingénieur INSA en informatique, j’ai passé une dizaine d’années en tant qu’architecte Java EE, avec une appétence forte pour l’industrialisation des développements.

Par la suite, j’ai pris un rôle de Scrum Master sur divers projets. Dans ce cadre, j’ai pris goût très rapidement aux valeurs et aux pratiques agiles !

Depuis 2010, je suis coach agile chez Orange Applications for Business. J’accompagne aujourd’hui des équipes et des organisations qui souhaitent devenir agiles, dans des secteurs d’activités très variés.


Construisez votre Roadmap à l’aide du Gamestorming

Le jeu de l’oignon
Le jeu de l’oignon

Ce billet est l’œuvre d’un blogueur invité, Frédéric Vandaele.

Bonjour à tous et ravi d’avoir l’opportunité d’échanger avec vous via ce blog.

En tant que consultant dans les institutions internationales, mon métier de coach agile m’a amené récemment à faciliter une session de planification sur un important projet pluriannuel. Ce projet a démarré avec un objectif apriori clair. Depuis, quelques mois se sont passés et la gestion de priorités devient de plus en plus difficile, que ce soit pour le responsable produit comme pour l’équipe.

Avec les nombreux éléments  à mettre en place en début de projet, l’équipe s’est naturellement focalisée sur les problématiques à court terme en perdant de vue la vision globale. Il était à ce moment important de remettre la partie métier au cœur des préoccupations.

Le chef de projet m’a donc contacté pour animer un atelier spécifique avec les ‘décideurs’. Cette session avait pour objectif d’identifier, construire et visualiser la feuille de route du projet pour les prochains mois et prochaines années.

Pour cet atelier, j’ai privilégié une approche basée sur les interactions entre les personnes, la transparence, la créativité et la communication au sein du groupe: le gamestorming.

Customer-Centric

Le premier exercice (http://www.gogamestorm.com/?s=onion – Customer-Centric) nous a permis de guider le développement de notre produit par l’identification de l’ensemble des personnes concernées. Non seulement celles qui vont utiliser le produit mais également toutes les personnes qui pouvaient être impactées – même de façon indirecte – dans leur travail.

Pour cela, on a représenté sur une grande feuille une série de 4 cercles

Le jeu de l’oignon
Le jeu de l’oignon: Les participants ont identifiés beaucoup d’intervenants en zones périphériques

Les participants ont identifiés beaucoup d’intervenants en zones périphériques

Les participants ont identifiés beaucoup d’intervenants en zones périphériques

concentriques libellés comme suit:

  • Le produit
  • le système – intervenants direct
  • le système environnant – intervenants du système, même si ils n’interagissent pas directement avec lui et
  • l’environnement large – les intervenants en dehors du système.

On a distribué des marqueurs et des post-its aux participants et on leur a demandé d’identifier les acteurs ainsi que de les situer dans chaque zones.

La « Timeline »

Le second exercice s’inspire d’un jeu qu’on utilise lors des rétrospectives: la Timeline (tiré du livre Agile retrospective de Esther Derby). La différence ici étant qu’on ne souhaite pas revenir sur l’itération passée mais qu’on veut se projeter dans le futur.

L’intérêt de la précision s’amenuisant au fur et à mesure que l’on se projette dans le futur, on a représenté une ligne du temps dont on réduit la précision au fur et à mesure que l’on se projette dans le futur. On a ainsi visualisé les 3 prochains mois, les prochains trimestres etc.

Chaque participant note sur les post-it les prochaines échéances auxquelles il pense. Chacun des participants positionne ses propositions sur la ligne de temps et les présente à l’ensemble du groupe. L’intérêt de l’exercice est à nouveau de susciter le dialogue et l’échange d’idées entre les personnes ainsi que de clarifier les choses.

Les participants ont visualisés la charge de travail pour l'équipe au dessus de la ligne de temps
Les participants ont visualisés la charge de travail pour l’équipe au dessus de la ligne de temps

L’atelier est un franc succès;  en quelques heures, les principaux jalons métier ont été identifiés et la feuille de route a été mise en place et approuvée par l’ensemble des intervenants.

A noter que le poster a été gardé sur le mur pour aider l’équipe à garder le cap sur le long terme.

On a par ailleurs observé que les post-it ont été par la suite déplacés pour représenter l’apparition de nouvelles priorités et pour visualiser les retards du projet.

Même si vos projets n’utilisent pas les méthodes agiles, une approche telle que celle-ci vous permettra d’apporter une dynamique de groupe qui donnera la bonne direction à vos développements futurs.

Un tout grand merci à Bruno pour m’avoir donné l’occasion de partager cette expérience avec vous. En espérant qu’elle vous inspire dans vos propres projets.

Agilement vôtre,

Frédéric.

@fredvandaele

Frédéric travaille chez Trasys. Praticien Agile, Il est passionné par les nouvelles méthodes de travail et les nouvelles formes de collaboration. Il intervient au sein des équipes comme coach Agile et est un speaker régulier des conférences Agiles comme en 2013 à l’Agile Tour Brussels. Vous pouvez le retrouver sur twitter (@fredvandaele)


C’est quoi les méthodes « Agile » ?

Il y a quelques mois j’ai été invité par le « Cluster » à animer un workshop d’introduction d’une journée sur les méthodes « Agile ». Le workshop était intitulé « How can agile methods accelerate your growth? ».

Durant une pause du workshop j’ai été interpellé par Juan, le responsable qui m’a demandé si on pouvait faire une petite interview. J’ai accepté avec plaisir et quelques jours plus tard, une fois la vidéo en ligne, j’ai découvert que non seulement ils avaient publié la vidéo mais également fait un montage du workshop.

Je me suis dit que ce serait intéressant à visionner si vous ne connaissez pas les méthodes Agile ou si vous vous demandez à quoi peut ressembler une de mes formations.

Donc voici la vidéo ci-dessous:

Quelques photos sont également disponibles.

Pour votre information, Software in Brussels est un ensemble d’éditeurs de software basés à Bruxelles. L’objectif du cluster est de promouvoir et faciliter le développement et la croissance de sociétés « software » à Bruxelles. http://www.softwareinbrussels.be


Coaching @ Startup Weekend Brussels 2013

Last weekend, I had the pleasure to be invited to work as a coach during the Startup Weekend Brussels 2013. I knew the concept of this event, one friend of mine won in 2011 🙂

If you don’t know what that is, here’s some Intel.

National Television filiming the event
National Television filiming the event

What’s a Startup Weekend ?

Startup Weekend is the largest community of passionate entrepreneurs with over 1000 past events in 470 cities around the world. If you want to put yourself in the shoes of an entrepreneur, join 100.000 starters and register to a Startup Weekend event.

Who it is for ?

Students, young starters, confirmed entrepreneurs, with a project or not! A large panel of profiles are welcome : developer, designer, architects, financial, commercial, marketing, legal, …

Whatever your profile is, if you are creative, ambitious and motivated, if you have a startup mindset, or if you have always dreamed to start your business, Startup Weekend is the place to be!

What’s happening during this event ?

Almost every teams were using Agile. Sometimes unknowingly :)
Almost every teams were using Agile. Sometimes unknowingly 🙂

On Friday evening, participants present their fresh new ideas. Best ideas are selected and teams are formed to start their projects. Over the activities during the weekend, participants get valuable advices, inspiration, coaching, and new contacts. The goal is to develop a “working prototype” and a “business model” to present on Sunday evening to a jury of experts. Best projects are then awarded and the weekend ends celebrating participants.

Startup Weekend is an opportunity to show your talents, your skills, and to share ideas. It is also an excellent way to collaborate with professionals from different horizons and to meet real entrepreneurs, journalists and investors.

Congratulations to the winners. One of them is Marc, an active member of the Agile Belgium Community 🙂

Bruno.


Scrum appliqué à toute l’entreprise

Le 11 avril, j’ai eu le plaisir d’être orateur au ScrumDay à Paris. Le ScrumDay c’est une conférence d’une journée au cours de laquelle plus de 500 personnes se sont réunies autour du thème Scrum.

La session que je présentais s’intitulait:

Agile appliqué à toute l’entreprise. Retour d’expérience sur le marché des payements électroniques. Il s’agissait d’un retour d’expérience sur une mise en place d’Agile (principalement Scrum) au sein d’une grande entreprise Belge (et internationale)

Scrum in the company
Scrum appliqué à une société entière

Je n’étais pas seul à présenter, en effet Frédéric, le client avec qui j’ai réalisé ce projet s’est joint à moi pour présenter cette session. Encore merci à lui d’avoir pris sur son temps et d’avoir effectué le déplacement.

Vous pouvez retrouver ci-dessous la vidéo de notre session. Bravo à l’équipe du ScrumDay qui a monté une vidéo où vous pouvez également voir les slides en même temps.

Voici également la présentation de cette session.

Scrum appliqué à toute l’entreprise from Bruno Sbille

Merci aux organisateurs du ScrumDay et à IBM notre hôte de la journée pour une organisation impeccable.

Bruno.


Salut à toi 2013

Closing Agile Tour Brussels

Bonjour à tous,

La fin d’année 2012 a été bien remplie… voici mes dernière nouvelles.

L’ Agile Tour Brussels, a été un succès, nous étions presque sold-out et nous avons reçu beaucoup de feedback positif. Nous referons une édition en 2013 ! Si vous voulez faire partie de l’équipe d’organisation, n’hésitez pas à me contacter. Les présentations sont disponibles via http://atbru.be.

Mon premier Agile Grenoble a été génial. Une des meilleure conférence de France. J’ai particulièrement apprécié l’audience très mature.

Voici les slides de mes présentations:

« The Agilists ou Duo de retour d’expérience sauce aigre douce » avec Alexis Monville.

« Les Men In Black font de l’Agile » avec Alexandre Boutin.

Fin Novembre a été pour moi l’occasion de prendre part à la conférence XPDays Benelux voici mon support pour la session:

« Learn different leadership styles with Star Wars Coaches« 

Introduction:

Slides:

J’étais supposé présenter une session avec Martin Mahaux: « Rapid Design: Improvise Your User Stories! » Mais quelqu’un d’autre a réorganisé mon agenda… 🙂

Que ce soit pour trouver votre route ou bien pour continuer à tracer votre chemin que 2013 soit plein d’accomplissements pour vous 🙂

Bruno.


Scrum passe (encore) à la télé…dans le monde des jeux vidéos !

Quand Scrum passe *encore* à la télé

Il y a quelques mois j’ai participé à un programme de formation organisé par le studio de jeux vidéo Fishing Cactus. Ce programme permet d’apprendre les métiers de l’industrie des jeux vidéos. En ce qui me concerne je donnais la partie gestion et organisation de projets via les méthodes Agile et Scrum, méthodes de référence dans le monde du jeu vidéo.

Après quelques mois, certains étudiants se sont associés et ont créés leur propre studio: Atomic Turtle Studio. Ils ont déjà sortis leur premier jeu: Drip.

Dans cette vidéo c’est l’occasion de les découvrir et, à nouveau, voir Scrum en pratique. Vous pouvez même entre le mot « Scrum » dans l’interview à 1’43 ». (Vidéo Tele MB – Mons Television)
[EDIT: vidéo supprimée malheureusement]

[EDIT2: Voici une vidéo de leur nouveau studio: https://www.telemb.be/article/creative-valley-dragon-slide]

Par ailleurs, je suis en train de préparer un article de blog sur Scrum et Agile dans le monde des jeux vidéos. Nous reparlerons d’ailleurs de ces 2 studios dans cet article.

A suivre…

Bruno.


Visualisez vos problèmes !

Parfois les problèmes potentiels sont visibles…ou pas assez

Cet article est l’œuvre d’un blogeur invité: Alan Hortz. Voir en fin d’article pour de plus amples informations.

Le Problem Log, à priori ce nom peut sembler familier à une personne ayant déjà travaillé dans le milieu de l’informatique, une telle personne peut s’imaginer d’emblée un fichier informatique au format texte avec beaucoup d’informations, telles que l’heure, une description précise du problème, l’endroit exact dans le programme informatique ou le problème est survenu. En bref un gros fichier rempli d’information et finalement assez difficile à comprendre.

C’est précisément l’image qui m’est venue à l’esprit lorsque Bruno Sbille m’a parlé pour la première fois du Problem Log, une petite dizaine de questions plus tard, la définition du Problem log avait pris une tout autre forme, celle d’un fichier Excel avec deux colonnes, un descriptif du problème rencontré et un statut, le problème est réglé ou ne l’est pas.

Première version du Visual Problem Backlog

Fort de cette définition, j’ai donc créé un fichier Excel en quelques clics de souris et le tour était joué. Et ensuite? Voilà exactement la question que j’ai posée à Bruno après avoir fièrement sauvegardé le fameux fichier. Bruno m’expliqua que le rôle du Scrum Master est entre autres de faire en sorte que l’équipe progresse le mieux possible en rencontrant le moins d’obstacles possible et que tous les problèmes rencontrés par l’équipe ou par le Scrum Master lui-même devaient y être consigné.

Le jour suivant, durant le « Daily Meeting », j’écoutais attentivement, je concentrais mon attention sur les paroles prononcées par les membres de l’équipe, j’attendais impatiemment que le mot « problème » soit prononcé pour enfin pouvoir alimenter ce merveilleux fichier qui allait résoudre tous les problèmes de productivité, en tout cas je le pensais. Ce mot clé n’était pratiquement jamais prononcé par les membres de l’équipe, et lorsqu’il l’était il était toujours accompagné d’un adjectif qualifiant le problème de mineur ou de simple à résoudre, parfois même lorsqu’un problème était évoqué par un membre d’équipe il était aussitôt rediscuté par un intervenant externe qui annulait le caractère problématique du sujet discuté en moins de dix secondes.

J’allais vite comprendre que derrière le discours d’une personne se cache bien des choses, tout d’abord, il y a le ressentit de la personne au moment ou elle parle publiquement, ensuite, il y a le vocabulaire employé et l’intonation de sa voix, enfin la gestuelle qui accompagne le discours est tout aussi importante.

Visual Problem Backlog après 2 sprints, ajout de statuts

Un acteur connu a dit en son temps « Il faut être aware », je comprends un peu mieux ce que ce brave homme voulait dire, c’est donc après avoir travaillé mon écoute, au sens large, que j’ai été confronté à une autre difficulté, la résolution des problèmes. Et oui, l’un ne va pas sans l’autre, des problèmes surviennent, il est nécessaire de les résoudre, ou tout du moins mettre en place des actions concrètes destinées à atténuer les impacts négatifs de ceux-ci.

Qu’est-ce qu’un problème finalement, une simple ligne dans un fichier Excel lui-même logé bien au chaud dans une généalogie de dossiers aux noms peu évocateurs ? Je suis arrivé à une conclusion personnelle, pour résoudre efficacement un problème qui survient dans une équipe, il doit être compris de tous et être présent à l’esprit de tous jusqu’à ce qu’une solution acceptable soit trouvée. Fort de cette conclusion, il me fallait trouver un moyen pour atteindre cet objectif, c’est alors que je me suis souvenu des sages paroles de Bruno, « Toujours mettre en place la solution la plus simple et adapter ensuite ».

Afin de mettre en place une solution qui amène de la visibilité auprès de l’équipe et des chalands, j’ai utilisé un flipchart (ou paperboard), c’est un outil facile à déplacer et en général il est toujours possible d’adapter sa hauteur. Une seule feuille est utilisée, une seule ligne délimite la feuille en deux colonnes. Deux libellés de colonnes ont été inscrits, la première colonne libellée « Open » contient les points bloquants et les problèmes qui sont découverts, la deuxième colonne libellée « Closed » contient les éléments qui ont été résolus.

À la fin de chaque daily stand-up, je résume les problèmes « entendus », je les note sur un post-it et je les place dans la colonne OPEN, je résume les avancées faites sur les autres post-its existants de cette colonne et déplace ceux qui ont été résolus dans la colonne CLOSED.

Visual Problem Backlog après 4 sprints et enrichi par les autres équipes

Le fichier Excel est toujours utilisé pour conserver à un seul et même endroit les problèmes rencontrés, en effet à la fin de chaque sprint la feuille est débarrassée des problèmes réglés.

Cette solution est en place depuis quelques mois, au cours des derniers sprints, les membres de l’équipe eux-mêmes prenaient le soin de placer les problèmes rencontrés dans la colonne OPEN et de mettre à jour le statut des problèmes résolus.

Toute l’attention doit être mise sur les éléments qui empêchent l’équipe d’être efficace et il est important de faire vivre ce flipchart en faisant régulièrement le point avec l’équipe et les parties prenantes.

L’exercice qui consiste à identifier les problèmes au sein d’une équipe n’est pas évident de premier abord, il se pratique à tous les moments de la journée, il faut être attentif aux comportements et discussions sur le plateau afin de déceler les problèmes et mieux définir les conditions dans lesquelles ils se posent.

Alan Hortz.

A propos de l’auteur:

Alan est actuellement Scrum Master pour la société Ogone. Ogone est un acteur spécialisé dans les services de paiement électronique.

En plus de ses 9 années d’expérience dans le monde IT, il termine actuellement un master en informatique aux facultés universitaires Notre Dame de la Paix à Namur.

Alan est passionné par l’informatique depuis que ses doigts se sont posés sur le clavier d’un Commodore 64. Depuis sa curiosité l’a amené à explorer les différentes techniques de développement logiciel tel que le unit testing, le développement mobile, l’intégration continue et récemment Scrum et d’autres méthodes Agile.

Profil LinkedIn

@AlanHortz

Photo: Virginie Sbille.


Quand Scrum passe à la Télé…

Scrum sur le terrain…

RTL-TVI (TV Nationale belge) a réalisé un reportage sur l’e-commerce en Belgique. Dans ce reportage vous pouvez apercevoir un de mes clients qui utilise les méthodes Agile.

C’est l’occasion de voir une belle utilisation du Management Visuel et de voir une équipe en train de faire sa Scrum « daily-meeting ».

Le partie nous concernant démarre aux alentours de 2’15 ».


3/5 Un daily meeting efficace ? Oui bien sûr, mais comment ? (Cinq facteurs de succès pour vos projets Agile/Scrum)

La Daily Meeting

Attention cher ami(e)s, jamais introduction d’un article n’aura été aussi longue…donc, accrochez-vous !

Tout d’abord, cet article est l’œuvre d’un blogeur invité: Giuliano Abraini. Son nom ne vous est peut-être pas étranger en effet c’est lui qui avait écrit l’excellent article: la gestion des risques en mode Agile.

Ensuite, cet article s’inscrit dans la série Cinq facteurs de succès pour vos projets Agile/Scrum et fait suite à l’article 2/5 Personnalité des différents acteurs (Cinq facteurs de succès pour vos projets Agile/Scrum). Ouf voilà pour l’intro, et maintenant place à l’article de Giuliano.

Après avoir posté un premier article sur le blog de Bruno (la gestion des risques en mode Agile) et puisque l’expérience était amusante, me voilà de retour avec un autre sujet.

En effet, je voudrais vous parler d’un moment capital dans un projet Scrum : le Daily/Scrum Meeting.  Et plus exactement, j’ai envie vous donner quelques petits trucs pour en améliorer l’efficacité.

« On fait des réunion debout » C’est souvent ce qu’on entend des gens qui découvrent Scrum.

Vous savez déjà à quel point ces 15 minutes quotidiennes sont essentielles afin de communiquer avec l’équipe, d’assurer un bon déroulement du sprint, de veiller à une répartition adéquate des efforts, de permettre à l’équipe de s’auto-gérer, etc, etc…
Si j’étais téméraire (et je le suis), je dirais qu’un projet Scrum sans Daily Meeting, c’est un peu un paquet de frites sans Andalouse (Ketchup, Mayonnaise et Américaine sont acceptées aussi).

Le hic est que le Daily Scrum souffre de la routine et des habitudes qui s’installent durant la vie du projet, un peu comme dans un vieux couple.  Voici donc quelques idées pour (re)dynamiser votre Daily Scrum et faire de ce meeting un moment efficace :

1)    L’heure du meeting

une des choses les plus « tue l’amour » pour les réunions récurrentes c’est lorsqu’elles sont censées commencer tous les jours à la même heure mais qu’en réalité ce n’est pas le cas.  Donc, fixez l’heure de début du Daily Meeting et tenez-vous y tous les jours.

S’il y a des retardataires, visez à ne pas pénaliser l’ensemble du groupe.  Commencez sans eux et prévoyez un petit défi sympathique pour les retardataires.  Ce «défi» doit marquer les esprits sans pour autant blâmer la personne.

Les coups de fouet sont donc fortement déconseillés.  Par contre, puisque vous êtes fan de Michael Jackson (si si, tout le monde est fan de Michael), vous pourriez prévoir, par exemple, que le retardataire effectue un superbe Moonwalk durant le meeting sous les encouragements du reste de l’équipe.

2)    Stand-up meeting

Lorsque vous tapez ces mots dans Babelfish vous obtenez la traduction suivante : « réunion comique ».  Or le véritable intérêt d’un stand-up meeting est de rester debout.  En effet, le côté court, dynamique, synthétique du Daily Scrum s’évapore comme par enchantement dès que les participants ne sont plus debout.
Evitez donc d’y amener des chaises, de vous tenir contre le mur, de vous asseoir sur le bord du bureau, etc.

3)    Préparation

Afin de gagner en dynamisme et en efficacité une petite préparation est utile.  Pour ce faire, il existe un moyen simple afin que chaque membre de l’équipe prenne quelques minutes avant la réunion en répondant aux questions suivantes :

⁃    Qu’est-ce que j’ai fait hier ?
⁃    Quelles ont été les difficultés que j’ai rencontré ?
⁃    Qu’est-ce que je vais faire aujourd’hui ?
⁃    Ai-je besoin de l’aide de membres de l’équipe ?

La réponse à ces questions constitue le contenu de l’intervention de chaque Team Member.  Cela vous aidera à canaliser plus efficacement la portée et la durée des interventions.

4)    Temps de parole

Voici un autre aspect qui pose généralement problème.  En effet, l’équipe aura vite tendance à basculer en mode « explication détaillée » et par conséquent à allonger la durée du Daily Meeting jusqu’à le transformer en un moment interminable.
La préparation du meeting devrait déjà limiter le phénomène.  Mais cela risque de ne pas être suffisant.  Prévoyez donc un temps de parole de 3 à 4 minutes grand maximum par personne et surtout intervenez si ce temps est dépassé.

Pour vous y aider, quelques outils existent comme la « boîte à meuh » pour marquer la fin du temps de parole, ou encore l’application iphone « Agilely Timer » pour gérer le temps de parole de chacun.

5)    Changez d’animateur

Une petite expérience qui peut être sympa à réaliser est de changer régulièrement d’animateur du Daily Meeting, en prévoyant que les Team Members soient animateurs à tour de rôle.  Ce système permet de répondre à plusieurs objectifs :

⁃    faire monter l’équipe en compétence ;
⁃    prévoir des back-ups lorsque vous êtes absent ;
⁃    obtenir l’adhésion des plus retissants ;
⁃    leur faire prendre conscience des comportements « dérangeants » durant un Daily Meeting.

6)    Afficher et expliquer clairement les règles

Comme toujours en Scrum, prévoyez d’afficher et d’expliquer minutieusement les règles du Daily Meeting afin que l’ensemble de l’équipe sache ce que vous attendez d’eux.

7)    Daily = quotidien…ou pas

Le Daily Meeting est a priori…quotidien.  Cependant, dans certaines situations, en fonction du rythme de travail de l’équipe, de la périodicité des délivrables, il peut être utile de réduire la fréquence de ces réunions à 2 ou 3 fois par semaine.

Comme toujours, soyez à l’écoute de l’équipe et elle ne sera que plus réceptive des messages que vous lui envoyez.

C’est déjà fini !  Je suis sûr que vous avez d’autres propositions, donc n’hésitez pas à les poster en commentaire.

J’en profite aussi pour remercier Bruno de m’avoir, une nouvelle fois, laissé de l’espace sur son blog 😉

A la prochaine,
Giuliano.

A propos de l’auteur:

Je suis consultant, chef de projet depuis 4 ans et j’ai une expérience dans l’IT de plus de 9 ans.  Plus précisément je suis spécialisé en SCRUM et en PRINCE 2 (certifié Foundation).
Après un master en sciences économiques et financières, je suis tombé un peu hasard dans le monde de l’IT.  Depuis je ne le quitte plus…
Durant mes différentes expériences, j’ai eu l’opportunité de recouvrir différents rôles (Analyste, Product Manager, Chef de projet) et d’être actif dans de nombreux secteurs (banques, finance, secteur public).
Ma motivation principale en tant que chef de projet est de satisfaire le sponsor du projet, et de faire en sorte que l’ensemble de l’équipe projet y trouve sa place.

En dehors de ma vie professionnelle, j’adore voyager et je suis un mordu de sport.
Vous pouvez me contacter via giuliano.abraini@gmail.com ou sur http://www.linkedin.com/pub/giuliano-abraini/0/992/32b