Pourquoi et pour quelles raisons les développeurs peuvent ne pas aimer la «mêlée quotidienne»? [fermé]

Tenir une mêlée quotidienne présente des avantages, tels que:

1. L'équipe se coordonne les uns avec les autres
2. Tout le monde sait quelle quantité de travail a été effectuée
3. Le graphique de Burndown est de plus en plus complet
4. Le tableau de tâches est mis à jour
5. Ça ne dure pas beaucoup, 15 minutes ne tueront personne

Cependant, récemment (après 6 mois d’implémentation et d’utilisation de Scrum), j’ai l’impression que nos développeurs n’aiment plus beaucoup la scrum au quotidien. Les gens ne font que mettre à jour le tableau de tâches, sans en expliquer suffisamment et il semble qu'ils en ont assez. Je vois que lorsque, pour une raison quelconque, nous ne le tenons pas, ils deviennent un peu plus heureux.

Je ne sais tout simplement pas ce qui pourrait mal se passer avec ça. Y a-t-il des raisons mentionnées quelque part pour les inconvénients que la "mêlée quotidienne" peut avoir pour une équipe? Quelles pourraient être les raisons pour les développeurs de se lasser de la mêlée quotidienne?

J'ai déjà participé à une équipe "SCRUM" avec plusieurs employeurs. Il me semble que les responsables considèrent le "point de presse quotidien" comme le principal objectif de SCRUM et le fixent comme objectif, au lieu de l’avoir comme objectif: un moyen de parvenir à un cycle de développement plus efficace .

Très rapidement, les réunions de 15 minutes sont devenues des réunions de 45 minutes. Les mises à jour étaient inefficaces car les gens étaient occupés à bâiller et à penser "quand on peut déjà y aller" au lieu d'écouter les autres, et cela romprait également les routines des gens (par exemple, un hibou et se rendre au travail à 9 heures pour cette réunion stupide tous les jours est une raison suffisante pour que je quitte ce travail).

Lorsque les gestionnaires prennent une idée qui peut être bonne si elle est appliquée correctement et la poussent à l'extrême, ils obtiennent l'exact opposé des résultats escomptés. Personnellement, je pense que plus je participe à des réunions, moins je travaille. J'ai 2 réunions régulières par semaine dans mon calendrier et j'en saute généralement une. Les réunions sont pour les gestionnaires, laissez les développeurs à faire leur travail.

Je suis sûr qu'il y aura beaucoup d'amateurs de SCRUM qui diront "Mais c'est tellement merveilleux" - eh bien, sauvez-le, j'ai tout entendu.

Je trouverais chaque jour un événement ennuyeux et inutile si j’avais l’impression qu’il y avait peu ou pas de valeur. Quelques facteurs peuvent réduire l’utilité d’un stand-up quotidien.

• L'information partagée ne me concerne ou ne m'affecte en aucune manière.
• Absence de propriété de l'équipe et tout le monde travaille toujours sur leurs propres projets.
• Absence de communication d'équipe en dehors du stand-up.
• Absence de progrès visibles ou communiqués.
• Absence d'informations à partager.

Celles-ci me viennent à l’esprit, mais il ya toujours plus de raisons possibles.

Peut-être devriez-vous simplement demander aux développeurs pourquoi ils ne semblent pas être intéressés? Si vous voulez plus / une meilleure communication, cela devrait commencer par vous.

Certains des problèmes rencontrés avec les réunions quotidiennes de SCRUM:

• ceux qui durent trop longtemps. Vous ne voulez pas de responsable dans ces tâches quotidiennes, car elles sont la cause première de ce type de problèmes. Voyez comment ce sont généralement ceux qui utilisent une chaise (oui, devoir se lever, c'est inciter les gens à être rapides)
• avoir à entendre parler de quelqu'un (ou de 2 ou 3 développeurs) décrivant tout problème isolé qu'il a longuement au lieu de décider d'organiser une autre réunion réelle plus tard pour en discuter avec ceux qui sont concernés
• heures stupides. Ces réunions ne doivent pas forcément avoir lieu le matin: vous ne parlez pas de ce que vous avez fait hier, vous ne décidez pas ce que vous ferez aujourd'hui; vous parlez de ce que vous avez fait entre le dernier jour et celui-ci et décidez ce que vous ferez jusqu'au prochain.
• manque de propriété de l'application pour les développeurs. SCRUM fonctionne si les devs ne sont pas traités comme des singes à code. Le premier signe du processus qui tourne mal est que les développeurs ne sont pas ceux qui évaluent combien de temps il faudra pour que quelque chose soit fait.
• Encore des heures stupides. Si une partie de l'équipe a commencé à travailler sur certaines choses et est "dans la zone" quand le quotidien se produit, cela devient un problème. Un bon moment pour les avoir tous les jours est celui où personne ne devrait travailler (après le déjeuner, par exemple, ou juste avant d'entamer des discussions pendant le déjeuner).

Le timing est le tueur pour beaucoup. Les programmeurs aiment coder tard, dormir tard et rentrer après la pointe du matin. Devoir être en poste à une heure fixe - bien trop tôt pour eux. Et trop tard pour ceux qui peuvent arriver plus tôt et qui commencent déjà à travailler.

Le flux est un autre problème. Un programmeur en flux avec certaines fonctionnalités fonctionnera jusqu’à tard dans la nuit, rentrera chez lui et reviendra rechargé et prêt à continuer. Avoir à s'asseoir lors d'une réunion avec des problèmes pour la plupart non liés peut le distraire.

Mon observation est que beaucoup trop souvent, ces réunions sont destinées aux responsables qui ont l’impression de faire quelque chose plutôt que d’être utiles à l’équipe et au projet.

Par exemple, une équipe est affectée à une série de corrections de bugs courts sur différents projets. Ils ne travaillent pas vraiment en équipe mais en tant qu'individus. Toutefois, comme la politique de l'entreprise / du service l'exige, le chef / responsable de l'équipe tient malgré tout une réunion journalière. Tout ce qui est accompli consiste à prendre 15 minutes ou plus pour une réunion inutile et 15 à 30 minutes de distraction et de manque de productivité avant et après la réunion.

Maintenant, j'ai vu que Scrum réussissait bien dans un projet avec des délais serrés et nécessitant beaucoup de coordination entre les personnes travaillant sur différents projets. Dans ce contexte, c'était un excellent système. Mais, dans le contexte de "Nous organisons une réunion parce que nous sommes un magasin scrum / agile et que nous sommes supposés le faire" peut vraiment nuire.

Assurez-vous que personne ne monopolise la réunion.

Si 4 développeurs parviennent à résoudre leur problème en 5 minutes et que les 10 minutes suivantes sont consacrées à l'écoute du chef d'équipe détaillant tous les développements incroyables et impressionnants qu'il a réalisés, dont la plupart ne sont ni aussi incroyables ni impressionnants. comme il le pense, les gens vont s'ennuyer très vite.

Prenez du recul et pensez à votre équipe:

• Travaillent-ils efficacement?
• Les tâches sont-elles terminées à temps?
• Le code est-il robuste et bien écrit?
• Est-ce que l'équipe s'assure que rien ne tombe entre les mailles du filet?
• Est-ce que l'équipe se coordonne elle-même afin de ne pas dupliquer le travail ou de ne pas se marcher sur les pieds?

Si votre réponse à toutes ces questions est "Oui", vous devriez peut-être réfléchir à la raison pour laquelle vous souhaitez imposer des tâches très occupées, telles que des réunions quotidiennes, des graphiques de burndown et des tableaux de tâches de votre équipe. Quelle valeur ajoute-t-il? Voulez-vous générer des données bureaucratiques uniquement pour votre propre plaisir ou essayez-vous de rendre l'équipe plus productive?

Y a-t-il eu une baisse de productivité depuis l'arrêt des mêlées quotidiennes, ou tout tourne-t-il comme avant? Si rien n'a changé, pourquoi continuer les réunions?

15 minutes. Est-ce que ces 15 minutes (plus le temps de s'y préparer) transmettent suffisamment d'informations nouvelles et utiles entre les membres de l'équipe pour améliorer la productivité des équipes pour la journée à venir de plus de 15 minutes? S'il n'y a pas assez de contenu de mêlée utile chaque jour, les membres de l'équipe pensent probablement qu'ils feraient beaucoup plus de progrès vers les objectifs s'ils sortaient de cette réunion dès que possible et se remettaient au travail.

Si vous souhaitez simplement mettre à jour le tableau et le graphique fréquemment, placez des versions brouillon sur un wiki.

Je vous conseillerais, si vous teniez la réunion rétrospective, de voir «Ce qui s'est bien passé» et «Ce qui ne s'est pas bien passé» et de voir si les développeurs ont répertorié la réunion stand-up quotidienne comme une perte de temps. Ensuite, vous devrez le réorganiser un peu.

Mon expérience personnelle:

• Le but est de savoir ce que nous faisons aujourd'hui et où nous étions hier. Au lieu de s'en tenir à l'ordre du jour, on se lance dans une discussion technique sur les bloqueurs entre 2 personnes et les 15 autres s'ennuient. Identifier le problème mais discuter à l'extérieur
• Les gens n'arrivent pas à l'heure dans la salle de réunion et cela devient un cycle que certains font exprès. Donc, le Scrum Master doit avoir une discussion discrète avec eux en dehors de la réunion pour s'assurer qu'ils commencent et se terminent à l'heure.
• Nous mettons déjà à jour les tableaux de burndown en dehors de la réunion Scrum, ce n'est donc pas l'objectif principal du stand-up quotidien.

La résistance survient lorsque: 1) Ils sont utilisés pour forcer les gens à se précipiter pour 9 heures du matin. C'est un stress supplémentaire quand le train est en retard. 2) Mauvaise direction de mêlée. Le leader devrait dire aux gens de ne pas laisser de problèmes en dehors des lignes téléphoniques, plutôt que de laisser les gens écouter quelque chose qui ne les concerne pas. 3) contenu sans valeur. C'est encore une question de leadership scrum. Il est censé être un forum pour traiter les goulots d'étranglement, les problèmes de trajectoire et les collaborations potentielles. Ce qui se passe en réalité, c’est que tout le monde dit ce qu’ils attendent de travailler ce jour-là, ce qui n’est ni utile ni intéressant pour qui que ce soit. 4) debout. Je ne resterai pas debout. La logique derrière la position était que cela encourage les gens à être brefs. En fait, les gens ne font que claquer.

J'ai géré et fait partie de plusieurs équipes Scrum. La principale raison pour laquelle les développeurs n'aiment pas Scrum sont:

• Comme ils sont dirigés par un très mauvais scrum master, si cela prend 45 minutes, votre scrum master doit pouvoir mieux contrôler la mêlée.
• La plus grande et la plus honnête raison pour laquelle ils n'aiment pas ça, c'est parce qu'il est très difficile de se cacher dans une mauvaise éthique du travail, c'est-à-dire, de manière plus flagrante, que cela montre les gens paresseux. Certains développeurs avec lesquels j'ai travaillé sont choquants, ils prennent des jours à effectuer des tâches qui devraient durer 30 minutes. Un bon PM devrait supprimer les obstacles pour les développeurs, ce qui signifie qu'ils devraient être capables de s'acquitter de leurs tâches dans un sprint. Les développeurs n'aiment pas cela parce qu'ils doivent se lever chaque jour et démontrer les progrès qu'ils ont réalisés. Cela provoque de l'anxiété quand ils ne peuvent pas démontrer de progrès pour quelque raison que ce soit. Si c'est à cause d'un problème valide, un bon scrum master devrait résoudre ce problème le plus rapidement possible.

Le problème survient lorsque les Scrum Masters n’ont pas l’autorité, les compétences ou la capacité nécessaires pour résoudre les problèmes de blocage. En fait, j'en ai vu enterrer des problèmes en espérant qu'ils disparaîtront. C'est désastreux.

Franchement, dans 99% des réunions de mêlée quotidiennes auxquelles j'ai assisté, il aurait été possible de remédier à la quasi-totalité des discussions / questions / réponses en quelques courriels.

Honnêtement, je pense que nous devons montrer des raisons plus valables pour ne PAS organiser de réunions. Créez des environnements où, lorsque le moment est venu de rassembler tout le monde dans une pièce, il est préférable que ce soit une bonne raison et organisé pour optimiser le gain de temps.

Je déteste les réunions en général et préférerais utiliser la vidéoconférence, les téléphones, les courriels, tout ce qui me permet d’entrer ou de rester dans mon travail sans avoir à me lever et à interrompre mon flux de productivité.

Personnellement, je pense que si vous avez plus de quatre réunions sur une période de 8 heures, les projets ne sont pas bien gérés.

De nombreux facteurs contribuent à la tension lors des réunions. Considérez-les comme l'une des principales raisons pour lesquelles les réunions peuvent vous coûter plus cher qu'elles ne valent:

• Focus - logiciel contre réunions
• Management - les gestionnaires ont besoin de mesures
• Personnalité - Introvertis vs Extravertis
• Time - Interrupts, Maker et Manager time
• Buts, Priorités

Chacun de ces facteurs est expliqué ci-dessous,

Focus - J'aime développer des logiciels, et cela inclut de réfléchir aux défis (problèmes), de créer des solutions, de construire le logiciel et de tenir des réunions qui empêchent de se concentrer sur les tâches qui construisent le logiciel. Il y a un état appelé " Flow " " dans lequel un développeur est immergé dans le problème (problème), a construit un modèle mental de la solution et se concentre entièrement sur la construction de la solution. Un développeur peut travailler jusqu'à minuit, ne sortir que pour manger et dormir, puis retourner dans un état proche de celui où il est parti.

Les développeurs doivent éviter les distractions, et beaucoup trouvent qu'il est avantageux de coder tard dans la nuit (ils évitent le bruit, les appels téléphoniques, les bureaux occupés et les collègues non développeurs qui interrompent leur travail). Et quand vous avez travaillé jusqu’à 10, 11 ou 12 heures, il n’est pas déraisonnable de venir travailler plus tard (10, 11, midi?). Est-il raisonnable de s’attendre à ce que les développeurs travaillent de 9 heures à minuit?

Les réunions Scrum (et toutes les réunions) distraient le développeur de son objectif principal, à savoir la création de logiciels.

Gestion - Les gestionnaires doivent mesurer pour réussir, d'où le besoin de calendriers, de produits livrables, de calendriers, de priorités et de réunions afin de mesurer et de rendre compte des progrès et d'exposer les dépendances, les retards et les zones à risque. Le défi avec Scrum est qu’un manager a besoin de ces choses, mais que le développeur a besoin d’être concentré. Les réunions servent le responsable et permettent au responsable d'obtenir, de mesurer et de suivre l'état et les progrès, mais les réunions offrent rarement une utilité aux développeurs. Considérez que les gestionnaires apportent plus de valeur lorsqu'ils gèrent les distractions, suppriment les obstacles et permettent aux développeurs de se concentrer sur la création de logiciels.

Il existe des solutions au besoin de réunions. Un responsable peut rendre visite à ses développeurs, demander des rapports d’état, adopter un protocole lorsque les interruptions sont moins intrusives ou adopter une stratégie à la charge du développeur pour l'informer de l'avancement des travaux lorsque le développeur est interruptible. Voir la discussion du temps pour pourquoi c'est important.

Personnalité - Considérez que certaines personnes sont des introvertis et que d'autres sont des extravertis. Les extravertis apprécient les interactions sociales et sont rechargés par eux. Les gestionnaires sont généralement des extravertis (car les extravertis sont généralement meilleurs avec les interactions sociales), bien que les introvertis puissent réussir en tant que gestionnaires. Les introvertis peuvent apprécier et même exceller dans les interactions sociales, mais sont rechargés par la solitude. Les développeurs sont souvent introvertis et réussissent à travailler seuls (ou au sein de petites équipes) car ils n'ont pas "besoin" d'interactions sociales; ils peuvent être heureux de travailler seuls sur des problèmes (bien que les extravertis puissent également être des développeurs). Les réunions de mêlée quotidiennes peuvent devenir des rassemblements sociaux, bons pour les extravertis, mais pas si bons pour les introvertis.

Heure - Les développeurs ne peuvent pas écrire de code pendant les réunions. Ils ne peuvent pas non plus penser à des problèmes difficiles (à moins qu’ils ne réfléchissent), tout en étant distraits par des réunions. Les développeurs ont besoin de beaucoup de temps ininterrompu pour se concentrer sur la création de logiciels. Les réunions sont des interruptions qui distraient de leurs efforts. Lorsque vous avez été plongé dans la résolution d'un problème pendant des heures, que vous avez presque terminé et que quelqu'un vous dit "temps pour la mêlée", vous êtes interrompu et perdez peut-être des heures de travail tout en "changeant de vitesse". Ou vous êtes resté au travail jusqu'à 23h00, vous avez quitté votre travail, rentré chez vous, dormi sur le problème, vous vous êtes réveillé, êtes retourné au travail prêt à résoudre le problème, puis êtes interrompu après une heure de travail sur un problème, car est "le temps pour la mêlée".

Paul Graham a un excellent article sur Maker Time vs. Manager Time, qui explique ce problème bien mieux que moi. Autant dire qu'une interruption de réunion, planifiée ou non, peut interrompre le flux et forcer un développeur de Maker à celui de Manager. Croyez-moi, vous voulez des développeurs à l'heure de Maker.

Objectifs, priorités - Les développeurs et les gestionnaires ont des objectifs et des priorités différents. Les gestionnaires ont la responsabilité de suivre les calendriers, de minimiser les coûts, de veiller à ce que leurs rapports soient responsables et performants. Les développeurs ont pour objectif de créer le logiciel qui répond aux défis / problèmes. Ces objectifs ne sont pas en conflit, mais c'est le mécanisme de communication qui crée la tension. Les réunions répondent aux besoins du responsable et optimisent son temps, mais elles entrent en conflit avec les besoins du développeur. Les réunions Scrum ignorent la première règle de réunion, "ont un ordre du jour" et ont tendance à errer davantage. Et les réunions sont utilisées pour optimiser la communication (pour le responsable), mais elles coûtent du temps au développeur (interruptions, perte de flux, etc.).

Quel est le but? Construire un logiciel qui réponde aux besoins avec rapidité et qualité tout en respectant les contraintes (qualité, délais, coûts, processus). Scrum et d’autres méthodologies agiles reconnaissent la contrainte de processus et essaient de minimiser ce facteur. Elles ont réussi car elles minimisent cette contrainte. Cependant, l'ajout de réunions coûte du temps, et les interruptions coûtent beaucoup plus au développeur que la durée de la réunion.

Modifiez la réunion pour vous assurer qu'elle offre des avantages:

1. Planifiez-le à un moment qui offre une certaine commodité. Pourquoi ne peut-on pas attendre 30 minutes après le début du travail pour que chacun puisse consulter ses e-mails et organiser ses réflexions pour la réunion. La concision prend la planification. Les personnes non préparées peuvent marcher à tout jamais.
2. Identifiez les problèmes qui auraient pu être évités si un problème avait été communiqué lors de la réunion. Tout le monde a besoin de comprendre quel est le point.
3. Faites tout ce qui est en votre pouvoir pour minimiser l’apport de chacun. Ce n'est pas l'endroit pour débattre. Encouragez les gens à planifier en privé des réunions en dehors de la réunion quotidienne sur un sujet qui nécessite une discussion. Règle: une seule personne parle à la fois.

Tous les plaignants doivent s’assurer qu’ils ne contribuent pas au problème. Si vous pouvez atteindre vos objectifs pour la mêlée quotidienne sans en avoir un de manière moins pénible, nous aimerions l’entendre.