Est-il jamais acceptable d'avoir des discussions non liées à l'enregistrement lors des réunions Scrum Daily Standup?

J'espère que les gens me laisseront une question potentiellement évidente. J'ai travaillé dans un certain nombre d'organisations qui ont des réunions de mêlée quotidiennes. Certaines organisations sont très strictes quant à l'utilisation de la mêlée uniquement pour l'enregistrement (les "trois questions" - qu'avez-vous fait hier, que faites-vous aujourd'hui, avez-vous des bloqueurs?), Mais d'autres organisations qui ont tendance à avoir d'autres informations générales annonces ou discussions techniques détaillées.

J'ai entendu l'argument, comme dans cet article , selon lequel autoriser une discussion non liée à l'enregistrement comme celle-ci est une erreur - la réunion Scrum ne doit pas être utilisée pour des annonces générales du Scrum Master, une discussion technique, etc.

Le principal mal que j'ai vu de cela est que les réunions peuvent durer plus longtemps que nécessaire (et c'est ennuyeux d'être forcé de s'asseoir sur une discussion de détails qui ne me concernent pas).

Il est assez clair que les discussions qui ne sont pas liées à l'ensemble du groupe et qui ne font pas partie des "trois questions" ne devraient pas faire partie du stand-up. Cependant, s'il y a d'autres annonces qui sont pertinentes pour l'ensemble du groupe et doivent être discutées de toute façon, est-ce nuisible d'en discuter à ce stade (plutôt que lors d'une réunion ou d'un courriel séparé)?

Le but du Daily Scrum est que l'équipe de développement passe en revue les dernières 24 heures et met à jour son plan pour les prochaines 24 heures.

Tout ce qui atteint cet objectif et peut être couvert en 15 minutes est exactement ce à quoi sert le Daily Scrum, selon le Scrum Guide. Si vous avez des conversations plus longues qui doivent avoir lieu, alors gardez simplement une note courante de ce qu'elles sont et, à la fin du Daily Scrum, divisez-vous en petits groupes qui se soucient de ce sujet.

Ce que le Daily Scrum n'est pas pour trouver des solutions aux problèmes. Faites cela après ...

Bien sûr, c'est acceptable, mais concentrez-vous d'abord sur les choses importantes. S'il nous reste du temps dans les 15 minutes, ce qui est assez courant pour une équipe de développement de 5 personnes qui grouille (car elles se synchronisent plus souvent pendant le développement), je n'ai aucun problème avec les communications et / ou les annonces supplémentaires. Tant que nous les reportons jusqu'à la fin du Quotidien.

En tant que Scrum Master, je m'assure que l'équipe répond en quelque sorte aux trois questions clés.

Le Daily Scrum est un événement encadré de 15 minutes pour que l'équipe de développement synchronise les activités et crée un plan pour les prochaines 24 heures.

Parfois, une courte discussion technique est nécessaire pour synchroniser l'équipe. En tant que Scrum Master, je m'assure que nous respectons le délai de 15 minutes et interrompons les discussions plus longues qui se tiendront après le stand-up.

L'équipe de développement ou les membres de l'équipe se réunissent souvent immédiatement après la mêlée quotidienne pour des discussions détaillées, ou pour adapter ou replanifier le reste du travail du Sprint.

Vous cherchez d'un point de vue non Scrum et plus agile. Concentrez-vous sur ce qui fonctionne et ce qui ne fonctionne pas pour l'équipe. Assurez-vous simplement que l'équipe décide et expérimente les changements si elle pense que cela les rendra plus efficaces et produira des logiciels de meilleure qualité.

Les membres de l'équipe doivent garder à l'esprit le but du standup - c'est-à-dire de se permettre mutuellement de contribuer à des problèmes qui peuvent prendre plus de temps lorsqu'ils sont gardés confidentiels ou dans un cercle restreint. D'un autre côté, il ne serait pas très agile d'éviter les problèmes importants et qui concernent toute l'équipe mais qui ne correspondent pas au critère de référence énoncé dans le livre de poche Scrum. Il serait stupide de planifier une réunion distincte simplement à cause d'une règle qui vise évidemment à gagner du temps.

Il n'est pas toujours clair pour un orateur quel est son problème. Si lui permettre de babiller pendant un certain temps, il sera clair pour quelqu'un d'autre qu'il a du mal ou qu'il suit une voie sans issue, vous pourrez peut-être quelque part après tout. Trop se préoccuper de la forme peut également nuire à la productivité et frustrer les gens.

Selon la culture, le standup peut être strict ou inclure des problèmes sociaux. Cela ne devrait jamais être un événement insensé qui passe par les mouvements qui serait considéré comme une "mêlée de zombies".

Il y a souvent une dichotomie entre ce que diverses personnes insistent avec véhémence sur Scrum et le concept de personnes sur les processus.

S'il y a des informations à communiquer, c'est finalement un appel au jugement. S'il est susceptible de provoquer un nombre important de discussions, il est préférable de le déplacer à un autre moment. Si c'est juste quelque chose de rapide comme un temps d'arrêt du serveur, etc., cela peut être fait ici et là. Il y aura bien sûr des nuances entre les deux, auquel cas le Scrum Master devrait simplement suggérer qu'il est mis hors ligne une fois que 15 minutes (ou autre) se sont écoulées.

Quoi qu'il en soit, je serais enclin à l'avoir à la fin après la fin du processus de standup habituel.

Vous avez demandé: "est-ce dangereux?" mais les autres réponses ont surtout porté sur "est-ce 'le but de la réunion?" "Je pense que ce sont des questions différentes. Cela peut vraiment être nocif lorsque vous glissez d'autres points de l'ordre du jour dans la réunion, surtout si cela devient habituel. Les standups prennent beaucoup de temps chaque jour, généralement à l'heure la plus productive de la journée, le matin lorsque les gens ont beaucoup d'énergie. Vous pouvez saper cette énergie directement des gens s'ils ne peuvent pas compter sur un standup aussi longtemps que nécessaire et non plus, et entièrement pertinent pour eux.

Les gens commenceront à se présenter tard, car ils sont engagés dans quelque chose de «plus productif». Ils ne se présenteront même pas du tout certains jours. D'autres personnes se présenteront en retard ou pas du tout parce que "tout le monde" se présente en retard ou pas du tout. Les problèmes s'aggravent les uns les autres et les stand-up cessent d'être aussi utiles pour leur objectif d'origine. Cela semble extrême, mais je l'ai vu se produire. Si vous faites cela, faites très attention à l'endroit où cela mène.

La plupart des équipes sur lesquelles je travaille tiendront parfois des réunions de conception juste après le standup, et ce n'est pas grave si elles sont utilisées avec parcimonie, mais honnêtement, j'obtiens de meilleurs résultats si je dis à mes coéquipiers au standup que je serai bientôt bloqué ayant besoin d'une contribution de conception et je '' Je vais planifier une réunion pour cet après-midi. Cela leur donne également le temps de réfléchir au problème, et après le déjeuner, les gens entrent un peu dans une crise et veulent changer de rythme. De plus, de cette façon, vous n'incitez pas les gens à concourir pour être les premiers à avoir leur "mini-réunion" après le stand-up afin qu'ils puissent partir.

Bien sûr, je ne recommanderais jamais aveuglément de faire ou de ne pas faire quelque chose simplement parce qu'un gars au hasard sur Internet (même moi) vous l'a dit. Individus et interactions sur les processus et les outils. Si vous décidez d'introduire des points supplémentaires à l'ordre du jour de vos réunions debout, je recommanderais de le mentionner spécifiquement dans la rétrospective suivante, de voir si l'équipe a trouvé cela perturbateur ou non, et de faire des ajustements si nécessaire. En fin de compte, chaque équipe a un niveau de confort différent et aura des idées différentes sur ce qui est approprié ou non.

MISE À JOUR: Je dois préciser: 15 minutes est le temps MAXIMUM que vous devez prendre en compte avec TOUT standup - un standup efficace suivant la règle ci-dessous n'est généralement pas plus de 5 minutes au plus et si vous pouvez distiller ce temps plus loin, encore mieux. Encore une fois, la plupart des discussions que vous jugez pertinentes peuvent facilement être discutées entre les membres de l'équipe en dehors du simple processus d'enregistrement quotidien, un standup est censé être à sa forme la plus pure.

Règle générale avec laquelle je suis resté fidèle lors de projets avec des amis et affiné en milieu professionnel:

• Hier

Ce que vous avez fait hier individuellement pour faire avancer le projet et, le cas échéant, cela a affecté quelqu'un d'autre.

• Aujourd'hui

Comme ci-dessus mais aujourd'hui

• Bloqueurs

Tout ce qui pourrait en provoquer un, déclencher l'alarme, aussi banale soit-elle (cela signifie que quelqu'un peut venir vérifier votre code ou vous faire un bilan de santé mentale)

Tout le reste est une distraction. Cela peut signifier que le sujet «pourrait» sembler pertinent pour l'avancement du projet ne l'est vraiment pas. C'est assez dur mais c'est TRÈS efficace à des fins XP.

Le but de la réunion debout est une communication efficace. Faites-en votre objectif au lieu de suivre une règle aveugle. Depuis que vous avez posé cette question, vous êtes sur la bonne voie.

Toutes vos préoccupations sont valables. Bien que nous puissions essayer d'anticiper si cela crée des problèmes, je répondrais simplement à votre question en vous suggérant de l'essayer.

Évitez ce qui suit:

1. Avoir des réunions trop longues.
2. Trop de gens préfèrent obtenir les annonces ailleurs. Le faire lors d'une réunion programmée est tentant, mais n'en abusez pas. La plupart des gens détestent les réunions ennuyeuses.
3. Les informations ne s'appliquent pas à tout le monde. Quelques exceptions sont bien à l'occasion.
4. Chaque réunion a des annonces par habitude plutôt que par besoin. Soyez profession.

Prenez des décisions éclairées et éclairées et ne vous cachez pas derrière une application excessive ou une prise de règles trop littérale.

La plupart des modèles Agile offrent une excellente structure de départ pour les équipes qui sont nouvelles dans un processus agile. Cela ne signifie pas qu'ils ne peuvent pas être modifiés pour répondre à vos besoins. Si ces annonces n'améliorent pas la communication, ne le faites pas. Semble simple, mais ...