Pour cela, chaque participant répond à trois questions :
- Qu'est ce que tu as fait hier ?
- Quel problème as-tu rencontré ?
- Que vas-tu faire aujourd'hui ?
Je profite également de l'occasion pour donner des informations diverses à l'équipe sur ce qu'il se passe à l'extérieur de la bulle
formée par l'équipe ou à propos de choses qui peuvent avoir un impact sur elle.
Évidemment, pour que la réunion porte ses fruits, chaque participant doit avoir le temps nécessaire pour s'exprimer, et c'est là mon premier problème.
L'équipe est composée de 5 personnes, 4 développeurs et un administrateur système et réseau, mais il y a actuellement deux sprints en cours au sein de l'équipe.
Précision importante, les deux sprints sont indépendants fonctionnellement, mais reposent tout deux sur la même base de code.
Des problèmes rencontrés par l'équipe effectuant le premier sprint sont donc susceptibles d'être également rencontrés par l'équipe du second sprint, et réciproquement.
De même, des modifications ou des corrections réalisées dans un sprint peuvent avoir un impact sur le déroulement du second.
Or, cela n'arrive pas tous les jours, et il arrive donc régulièrement qu'une partie de l'équipe patiente durant plusieurs minutes à ne rien faire car ce qui est raconté ne la concerne pas.
Pour autant, je pense qu'il est risqué de laisser partir de la réunion les membres du premier sprint si les membres du second sprint ne se sont pas encore exprimé totalement.
Je pourrais éventuellement les rappeler en cas de besoin, mais cela voudrait dire les importuner alors qu'ils sont déjà peut être en plein travail, et je pense que le remède serait pire que le mal.
Autre problème, la réunion prend à mes yeux trop de temps, et une partie de l'équipe, sinon la totalité, est d'accord avec moi.
Évidement, cela est induit entre autre par le problème évoqué précédemment, mais pas uniquement.
Il arrive en effet fréquement que la discussion, à partir d'un certain point, n'ait plus pour but de répondre aux trois questions, mais de débattre d'un problème ou de sa solution.
Pris dans la discussion, et aussi parce que j'ai toujours peur d'interrompre un processus dont il peut émerger une très bonne solution à terme, j'ai alors beaucoup de mal à intervenir afin d'interrompre l'équipe et de la recentrer sur l'objectif de la réunion.
Plusieurs minutes peuvent alors passer alors que le problème ne concerne pas forcément l'ensemble de l'équipe.
Enfin, j'ai également un problème au niveau de l'horaire.
Les membres de l'équipe sont censés arriver au bureau à 8 h 30, mais comme tout le monde peut être ralenti par la circulation, et notamment moi, la réunion commence à 9 h 00.
Dans les faits, l'horaire est respecté, mais je m'aperçois que du coup, le début de la réunion provoque souvent l'interruption de discussions initiée entre 8 h 30 et 9 h 00 en rapport avec les sprints en cours
Je me retrouve alors face à mon problèmes précédent, mais même si j'ai plus de facilité à le résoudre en interrompant les gens pour forcer
le début de la réunion, je trouve que ce n'est pas optimum.
Évidemment, j'ai consulté l'équipe afin de trouver des solutions, mais je n'ai pas eu de réponse vraiment pertinente.
Ce matin, l'un des développeurs a pris l'initiative de chronométrer la réunion, en laissant le chronomètre bien visible, et la réunion n'a pas dépassé la quinzaine de minutes, soit trois minutes par personne en moyenne, ce qui me semble le maximum adminissible.
De mon point de vue, elle a été plus rapide que d'habitude, et le chronomètre peut donc être un bon moyen de stimuler
les gens afin qu'ils soient plus efficaces dans leur communication.
Cependant, il n'y a pas eu de débats importants aujourd'hui, et l'efficité de la méthode reste donc encore à pleinement démontrer.
Par le passé, j'ai déjà été confronté à des problèmes de durée concernant la réunion quotidienne, mais le problème n'avait pas la même origine et j'avais trouvé assez facilement une solution satisfaisante.
Mais là, je suis un peu à sec, donc si vous avez des suggestions, lachez-vous dans les commentaires !
6 réactions
1 De Jérôme - 13/01/2012, 15:40
Hello,
Quelques pistes (ça vaut ce que ça vaut):
1. Mettre en place un compte à rebours de 15min à 0, quand le truc sonne la réunion est terminée, quoiqu'il arrive. Au début ça va être un peu dur car tout le monde ne se sera peut-être pas exprimé, mais après quelques jours ça devrait rentrer dans l'ordre. De plus ça va forcer les intervenants à s'exprimer plus efficacement.
2. Bannir les expression "pelottes de laines", du style "et si on ...", "oui mais..." etc, car généralement c'est la porte ouverte à la digression voire au débat alors qu'un stand up meeting n'est pas fait pour ça. On ne prends pas de décision en stand up meeting, on fait juste un rapide briefing.
3. Lorsqu'une personne a un soucis, tu le note et tu en reparle directement avec elle une fois le scrum meeting terminé. Ca évite de pénaliser les autres à écouter un truc qui ne les concernent peut-être pas.
4. Le chronomètre (comme décrit en #1) c'est bien, mais pas sur le long terme, le but est de mettre en place une culture de la parole efficace. Donc tu peux mettre en place un chronomètre pendant une semaine et voir ce qu'il se passe la semaine suivant sans chronomètre. Si tu sens que ça ne bouge pas alors ne remets plus. Par contre si jamais tu sens que le temps du meeting commence à s'allonger, ressort le chrono, et ce jusqu'à ce que ça finisse bien par rentrer dans la tête de tout le monde qu'il faut être super efficace pour décrire les affaires courantes. Etre efficace ne voulant pas dire pour autant qu'il faut éluder/cacher les problèmes, c'est simplement une question de vocabulaire.
Voilà, j'espère ne pas avoir trop enfoncé de portes ouvertes.
Bonne journée
2 De Gérald - 13/01/2012, 16:00
Si tout le monde n'arrive pas aux même horaires... quid d'un daily en milieu de journée (avant / après manger, avant de partir => ce qui peut aussi, dans certains cas, limiter les dérives)
3 De mageekguy - 13/01/2012, 16:01
@Gérald : J'ai suggéré, mais la suggestion n'a suscité l'enthousiasme.
4 De M - 13/01/2012, 16:05
15 minutes me semblent un peu longues pour un daily avec seulement 5 personnes.
Essayez de ne pas dépasser 5 minutes, le daily n'est pas une réunion.
Reporter les discussions hors du daily pour ne pas bloquer tout le monde.
Bonne chance.
5 De langlois_s - 14/01/2012, 11:30
Ma contribution à 2cts :
Tu pourrais démarrer en resserrant sur les recommandations préconisées par scrum. Lorsque tu jugera que l'équipe est suffisamment aguerrie vous pourrez ajuster cette pratique dans le cadre de vos rétrospectives.
Exemple, en partant du principe que l'on a bien deux équipes et deux sprints (?) :
- un daily scrum meeting par sprint/équipe - example #1 (9h - 9h15) -- #2 (9h15 - 9h30)
- la réunion timeboxée à 15' - si impression de ne pas avoir été très efficace ou si tout le monde n'a pas réussi à s'exprimer ou si quelqu'un arrive en retard ou si... pas grave, on clôture en l'état, çà sera mieux demain ou bien on optimisera à la rétrospective pour le sprint suivant...
- Quel est l'intérêt d'amorcer des discussions avant la réunion (entre 8h30 et 9h) ? Les personnes arrivant à 8h30 pourraient commencer leur journée -(ex. traitement mails, ...)
- Focaliser sur les trois questions
See ya
6 De Amaury - 25/01/2012, 14:57
Quelques pistes :
- Faire la réunion debout. Personnellement, je ne pratique pas, mais pas mal de monde fonctionne comme ça. Bizarrement, les gens vont à l'essentiel quand ils ne peuvent pas s’asseoir. Attention toutefois à ne pas générer de problèmes (personnes handicapées, ou simplement avec des problèmes de jambes ou de dos).
- La réunion du matin ne doit pas être une réunion de projet. C'est souvent la grande erreur qui fait dériver. Si chaque personne doit présenter là où en est le projet sur lequel elle travaille, et non pas là où en sont ses tâches individuelles. Ainsi, on peut identifier les retards et les points de blocage. Éventuellement, si un point précis mérite qu'on entre plus en profondeur, cela reste possible. Cela permet aussi d'identifier les réunions plus spécifiques qu'il faudra peut-être démarrer rapidement pour débloquer tel ou tel projet.
- Il faut bien choisir les personnes qui assistent à cette réunion. À une époque, je faisais 2 petites réunions. La première avec les développeurs + l'administrateur système, la seconde avec les intégrateurs + webdesigners. Ça ne marchait pas très bien. Maintenant, je fais un point individuel avec l'admin sys. Un autre point avec les développeurs + intégrateurs. Et je vois les webdesigners lors de points projets (pas tous les jours). Ça parait évident a posteriori. Ce genre d'affinage améliore grandement la productivité des réunions.
Pour finir, je ne suis pas un adepte du chronomètre. Je préfère donner un "budget-temps", je n'hésite pas à recadrer ceux qui commencent à dériver, mais je me laisse aussi la possibilité de faire durer la réunion 25 minutes les quelques fois où c'est nécessaire.