Réunion quotidienne Scrum: Ponctualité de la présence complète de l'équipe?


9

Je crois comprendre qu'une réunion Daily Scrum devrait être très rapide, organisée de manière amicale et qu'elle nécessite la présence de tous les membres de l'équipe. Parce que l'objectif est d'avoir tout le monde au courant de ce que font les autres.

J'aime les réunions quotidiennes Scrum qui se tiennent comme ça.

Dans mon dernier projet, nos mêlées quotidiennes ressemblent davantage à une réunion de mise à jour du statut. Bien que la position soit que nous tenons Scrums et pratiquons une Agile appropriée.

Nous sommes une équipe distribuée, dans 2 pays différents, et les personnes qui sont dans le même pays ne sont pas dans le même bureau. En conséquence, nous avons des Scrums virtuels.

Le problème est que nos réunions commencent toujours à l'heure, beaucoup de personnes appellent avant l'heure de début réelle, donc elles commencent en fait à la toute première seconde de la réunion. Sans aucune tolérance pour les petits retards.

Par exemple, la dernière fois que nous avons téléphoné et que la personne qui a coordonné la réunion a vérifié si tout le monde était en ligne, nous avons dit qu'un des membres de notre équipe n'était pas encore en ligne mais qu'il appelait. Et on m'a dit de commencer à partager sans attendre le membre de mon équipe.

De plus, tout le monde a beaucoup de réunions, et parfois ils sont consécutifs à la réunion Scrum, il est donc compréhensible qu'ils arrivent pendant la première ou la deuxième minute de la réunion.

Est-ce normal pour les équipes pratiquant des mêlées quotidiennes? C'est la première fois que ça m'arrive.

Je ne trouve aucune bibliographie directement à ce sujet. Bien que la présence de tous les membres de l'équipe soit soulignée, il est également souligné que les réunions doivent toujours commencer en même temps. Mais j'imagine qu'il peut y avoir une petite tolérance de retard.

J'ai même lu sur un blog quelqu'un suggérant que le Scrum Master peut imposer des pénalités si quelqu'un arrive "5 secondes" en retard. Je pensais que les Scrums étaient censés être amicaux, et avoir une pénalité comme ça semble contre-productif.

Quelle est l'approche recommandée dans une situation comme celle-ci?


Si vous avez une mêlée avec 11 personnes et 1 gars avec 1 minute de retard, c'est une perte de 10 minutes de temps en entreprise. Si 1 gars a 6 minutes de retard, c'est déjà une heure. Quelque chose qui peut sembler petit peut s'avérer étonnamment grand.
Pieter B

Réponses:


24

Comme pour toute pratique agile, les équipes de mêlée peuvent décider elles-mêmes. Si cela vous dérange, vous devriez en parler dans votre rétrospective et essayer de trouver une solution qui plaise à tous. Peut-être que les autres membres de l'équipe ressentent la même chose, mais pensent que "c'est comme ça que la mêlée se fait".

Cela étant dit, dans mes réunions de mêlée, je commence le deuxième à moins que trois personnes ou plus manquent. Pour une réunion à laquelle tout le monde est tenu d'assister tous les jours, je pense qu'il est irrespectueux du temps de chacun de faire autrement. Quand je suis celui qui arrive en retard, mon équipe commence sans moi. Si nous avons du temps à la fin, nous revenons aux tâches des personnes qui sont arrivées en retard.

J'ai été moins strict sur la ponctualité dans le passé, et ce qui s'est passé, c'est que les gens qui se sont présentés à l'heure se sont lassés de perdre leur temps, alors ils ont commencé à essayer de deviner quand la réunion commencerait réellement, et à se présenter ensuite à la place, ce qui avait un effet boule de neige.

Pour une réunion quotidienne, ce n'est pas la fin du monde si quelqu'un en manque occasionnellement une partie. J'espère que ce n'est pas la seule communication que vous faites tout au long de la journée.


Je comprends ton point de vue. Bien que je pense que cela brise en quelque sorte l'esprit de la mêlée quotidienne, du moins tel qu'il est décrit. De plus, cela n'a jamais été un retard de plus d'une minute. Et c'est surtout parce que le logiciel ne fonctionne pas bien. Les problèmes de téléconférence habituels.
Sky

2
C'est beaucoup plus facile en personne car généralement les gens sont assis les uns à côté des autres et peuvent être saisis s'ils sont en retard. Je suis chef de produit sur un projet qui semble similaire en ce sens que nous avons des personnes travaillant dans au moins quatre endroits différents à l'international. C'est plus difficile car parfois les gens sont "en retard" en raison de limitations techniques. Je pense personnellement qu'un équilibre peut être fait si les gens n'en abusent pas.
Gort le robot

@StevenBurnap C'est ce que je ressens, personne dans mon équipe n'est proche. Et qu'une heure de début de réunion est 15 heures, cela ne signifie pas que les gens commencent à parler à 3 heures, cela signifie qu'ils se réunissent à 3 heures.
Sky

Je vote pour celui-ci parce que vous avez d'abord dit que les équipes Scrum peuvent le décider par elles-mêmes, et que vous avez mentionné que certaines personnes peuvent penser que "c'est comme ça que la mêlée se fait". Le reste est relatif, car les conditions de chaque situation sont très difficiles à expliquer ici. Et en ce qui concerne la ponctualité, cela dépend des gens, je préfère ne pas punir les gens qui ont honnêtement eu des problèmes, juste pour la possibilité future d'abus, car les équipes réparties ont des complications supplémentaires que je ne peux pas décrire ici. Merci pour votre réponse!
Sky

1
sauf que dans le monde réel, l' équipe ne prend pas toujours la responsabilité et c'est un manager ou un demi-manager qui prend le contrôle des réunions et les force et applique les règles.
Ancien compte

6

Si vous attendez des gens, cela leur apprend qu'il est normal d'être en retard. Si vous commencez à la minute, les gens apprendront qu'ils doivent être là à temps s'ils veulent participer. La programmation est une activité professionnelle qui nécessite au moins un minimum de discipline.

Cela étant dit, l'objectif du standup quotidien est de discuter de ce que l'équipe a fait hier, de ce qu'elle fait aujourd'hui et de sensibiliser tout le monde aux barrages routiers. L'heure prévue doit être "la première heure du matin lorsque tout le monde est disponible", pas nécessairement une heure précise de l'horloge. L'objectif final est de travailler ensemble en équipe, et non de suivre des règles strictes. Si votre équipe est très nouvelle dans l'agilité, le respect de l'horloge est un bon moyen de développer vos compétences d'équipe. Si vous êtes une équipe mature, faites ce qui fonctionne pour votre équipe.


Le seul problème avec "la première chose du matin quand tout le monde est disponible" est qu'il n'y a pas le rythme obtenu en le faisant en même temps tous les jours. Cela ne permet pas non plus aux arrivées tardives de s'engager dans le travail et de se rattraper afin de ne rien oublier dans leur mêlée quotidienne. Je pense que votre point de départ sans délai est bon! Il apprend à tout le monde à être à l'heure. C'est un excellent point et je proposerai que nous l'adoptions.
jmort253

Je suppose que je n'étais pas assez clair. Je ne voulais pas dire une heure différente chaque jour. Je voulais dire que l'équipe doit choisir la première heure à laquelle ils sont tous disponibles, puis ils devraient utiliser cette même heure chaque jour.
Bryan Oakley

Oh. OK, cela est parfaitement logique alors. Content d'avoir demandé. :)
jmort253

2

Est-ce ainsi que Scrum fonctionne?

Je vous suggère que les réunions quotidiennes sont trop souvent pour toute activité commerciale, à moins que votre équipe ne soit particulièrement productive (ce qui signifie qu'elle peut produire de grandes quantités de fonctionnalités en très peu de temps).

Si vous décidez d'avoir des balises quotidiennes, elles ne devraient pas durer plus de 15 à 20 minutes, et oui, tout le monde doit être à l'heure ou ils ne participent pas. Les balises sont à l'avantage des membres de l'équipe, pas du scrum master; les pénalités pour les réunions quotidiennes manquantes devraient être traitées de la même manière que tout autre retard.

Bref, je ne vois rien de spécial ici. Je pense que les réunions quotidiennes de toute nature limitent la micro-gestion, mais si vous décidez de les faire, vous devez les faire correctement.


1
N'est-ce pas l'objectif principal d'avoir une réunion non structurée tous les jours que l'équipe puisse savoir ce que tout le monde fait et offrir de l'aide aux autres? Et par conséquent, il est plus important qu'ils soient à l'aise et partagent, que s'ils sont arrivés 30 secondes en retard?
Sky

3
if you know they are calling in, why not wait?- Parce qu'une attente de 3 minutes devient une attente de 5 minutes, puis une attente de 10 minutes ... Comme Tom Hanks l'a dit avec éloquence dans le film Cast Away (lors de la discussion sur le record de ponctualité de Federal Express) "Avant de vous en rendre compte, nous c'est le United States Postal Service. "
Robert Harvey

2
Si vous ne maintenez pas la ponctualité, les gens s'énervent avec vous et les uns avec les autres. Si vous maintenez la ponctualité, les gens se fâchent d' eux-mêmes de ne pas être sûrs d'être prêts. Que préférez-vous?
keshlam

2
Je pense que 15-20 minutes est beaucoup trop long. Si vous allez plus de 5 minutes, vous vous trompez.
Bryan Oakley

2
@RobertHarvey Le but de la mêlée quotidienne est de prendre très rapidement le pouls de l'équipe, d'identifier les obstacles et de planifier des suivis entre les seuls membres de l'équipe nécessaires, sans perdre le temps de tout le monde sur une réunion plus longue et plus traditionnelle. Voir en.wikipedia.org/wiki/Stand-up_meeting#Software_development pour une belle vue d'ensemble. Il existe de nombreuses publications sur la mêlée et vous pouvez constater que la lecture de certaines d'entre elles vous aide à mieux comprendre les questions de la mêlée et vous met en mesure de fournir des conseils spécifiques plus contextuels.
voler le

2

Les gens sur le processus . C'est l'un des principaux locataires d'Agile, si un processus ne fonctionne pas pour votre équipe, supprimez-le ou modifiez-le. Laissez l' équipe la modifier pour l'adapter à leurs besoins.


0

Pensez-y comme ça, quel est l'intérêt du stand up quotidien?

C'est votre chance de soulever des obstacles avec le reste de l'équipe, de signaler que vous pourriez avoir besoin d'aide et de mettre en évidence les changements qui affecteront les autres. Il est important que vous, en tant que développeur, soyez là.

Avec une équipe de 4 à 8 développeurs, ils doivent être rapides et rapides - 30 secondes chacun la plupart du temps. Si je jouais le rôle de Scrum Master, je serais préoccupé par le démarrage tardif des réunions car cela augmenterait le coût de la réunion. De même, les heures de réunion variables créent une distraction pour tout le monde - sommes-nous sur le point de ... Je serais également très conscient de trouver un équilibre entre cela et les besoins pour s'assurer que l'équipe est en mesure de se soutenir mutuellement, donc peut retarder la réunion si nécessaire parce que quelqu'un qui était susceptible d'être gêné était au téléphone / aux toilettes.

Lorsque les équipes sont réparties géographiquement comme vous le décrivez, je signalerais cela comme un obstacle d'équipe à CHAQUE rétrospective. C'est manifestement un obstacle à la performance et à la communication des mêlées qu'ils ne sont pas tous assis ensemble et capables de communiquer librement et facilement.

Je dirais que cela devrait être organisé en deux équipes de mêlée distinctes et le travail organisé de manière à ce que la mêlée de mêlées puisse gérer la communication internationale.


En fin de compte, et selon mon sentiment, le problème n'était pas lié au processus, mais aux personnes. Ils utilisaient le processus comme excuse, car les membres de l'équipe se familiarisaient les uns avec les autres, la tolérance augmentait et tout d'un coup, ils n'avaient pas de problème à attendre 30 secondes ou une minute pour que quelqu'un se joigne, car maintenant ils savaient L'une et l'autre. Je ne conseillerais pas de tenir des SCRUM séparés sauf si les deux équipes travaillent dans des parties très différentes du projet et n'ont jamais besoin d'interagir. Je suis d'accord, les SCRUM doivent être agiles, mais encore plus d'équipes doivent être cohésives et tolérantes quand il y a des problèmes.
Sky
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.