Réunions d'équipe efficaces

Je suis chef d'équipe d'une équipe de 8 programmeurs dans une entreprise d'une vingtaine de techniciens. Ils travaillent sur une gamme de projets, ces projets impliquent également des personnes d'autres équipes qui sont hors de mon contrôle. Mon organisation ne fait pas de développement agile approprié, et elle résiste quelque peu au changement, mais j'ai tenu des réunions quotidiennes de stand up au sein de mon équipe et nous les avons toutes trouvées utiles et tout le monde est engagé et nous en avons fini avec 10-15 minutes. J'ai également des entretiens individuels hebdomadaires avec chaque membre de l'équipe où nous discutons de divers sujets généraux (à la fois techniques et non techniques) plus en détail, ainsi que diverses réunions thématiques ponctuelles.

Ce avec quoi je me bats, cependant, c'est ma réunion d'équipe hebdomadaire. Il perd de la vitesse et je n'ai pas réussi à garder l'intérêt des gens.

Je veux toujours tenir une réunion plus longue, même si elle doit être bimensuelle ou mensuelle. Le but était de discuter de divers sujets qui ne peuvent pas être abordés lors d'une réunion debout car ils nécessitent plus de temps. Les mises à jour de ma part incluent un résumé de chaque projet en cours sur lequel ils travaillent (que ce soit dans les délais, divers retards, etc.), tout changement de direction, projets futurs, changements au processus de développement, etc. Cependant, cela finit par être une conférence de ma part, et au moins 2 personnes sont évidemment zonées et les autres sont tout au plus légèrement intéressés.

J'ai essayé d'amener les gens à être plus engagés en leur faisant parler de leur semaine, mais avec 8 personnes, cela prend beaucoup de temps et (en partie parce qu'une grande partie de leur travail ne se recoupe pas beaucoup), la plupart des autres équipes le font ne se soucient pas de ce que leurs collègues ont travaillé plus en détail (ils obtiennent un aperçu de haut niveau lors des stand-ups).

Donc, pendant ces réunions, au moins certaines personnes s'ennuient beaucoup et c'est presque gênant pour moi de continuer à les tenir. C'est un contraste frappant avec nos réunions matinales dynamiques.

Un conseil sur ce que je peux faire pour garder les gens plus engagés et plus intéressés? Et comment puis-je les amener à présenter des choses sur leur ou à entamer des discussions qui impliquent tout le monde au lieu que ce soit un monologue de ma part?

Vous avez dit que les réunions donnaient l'impression de leur faire la leçon. Si cela vous semble ainsi et que l'équipe ne semble pas intéressée par ce que vous avez à dire, alors pourquoi avoir encore la réunion? Si vous leur lancez simplement des informations et que cela ne retient pas leur attention, pourquoi ne pas tout résumer dans un e-mail hebdomadaire?

Si vous souhaitez profiter de cette heure que vous avez avec toute l'équipe, vous pouvez envisager d'organiser une rétrospective. Vous pouvez présenter la rétrospective avec une honnêteté simple de votre part: dites-leur que vous ne pensez pas que les réunions précédentes ont été productives et que vous voulez essayer quelque chose de différent pour aider tout le monde à profiter de l'heure qu'ils ont ensemble.

Dans retros où je travaille, nous aurons trois colonnes sur un tableau blanc, en mettant généralement un smiley, meh, et triste visage en haut, par exemple :), :|et :(. Ensuite, les membres de l'équipe peuvent mettre au tableau tout ce dont ils aimeraient parler avec l'ensemble du groupe.

Dans la colonne happy, vous pouvez célébrer les succès (comme féliciter Alice et Bob pour la sortie d'un projet sur lequel ils ont travaillé ensemble), et vous pouvez déclarer la victoire avec les nouveaux processus que vous essayez (comme le nouveau traqueur de bogues est bien meilleur que le le vieux).

Dans la colonne meh, vous mettez des choses qui ne sont pas exactement heureuses ou tristes pour la semaine. Peut-être que vous avez acheté des licences pour la nouvelle version de votre IDE, et que quelqu'un n'a vu aucun avantage du nouvel IDE - ils pourraient mettre cela sur la carte pour déterminer si tout le monde estime que la mise à niveau est sans valeur ou si d'autres personnes l'ont trouvé des moyens qu'il est en fait supérieur à la version précédente.

Dans la triste colonne, vous mettez des choses qui ne se sont pas bien passées pour la semaine. Identifier les points douloureux de la semaine est probablement le plus gros avantage d'une rétrospective à mon avis. Toute l'équipe discute des solutions à un problème réel. Sur les équipes qui travaillent toutes sur une seule base de code par exemple, quelqu'un pourrait dire que la classe FooBar est impossible à maintenir et a été la cause d'heures de débogage. Soudain, vous découvrez que tous les autres membres de l'équipe ont également perdu plusieurs heures cette semaine à FooBar, mais personne n'a passé de temps à le nettoyer. Dans ce cas, l'équipe peut décider collectivement qu'il est logique que quelqu'un passe du temps à refactoriser ce code la semaine prochaine.

Après que tout le monde a écrit ses sujets proposés au tableau, j'aime passer brièvement en revue chaque sujet et demander à son auteur de donner une explication de 10 à 30 secondes sur le sujet. Cette section de la réunion est facile à faire dérailler, vous devrez donc faire attention à garder les gens sur le sujet - par exemple, quelqu'un dira que X a été un problème, et quelqu'un d'autre commencera à parler d'une solution au problème; les solutions ne doivent être discutées qu'après le vote. En présentant les sujets, vous pouvez trouver des moyens de regrouper plusieurs sujets étroitement liés.

Après les présentations, chacun obtient trois votes qu'il peut répartir entre les sujets comme bon lui semble. Enfin, les votes sont comptabilisés, et quel que soit le sujet ayant le plus grand nombre de votes, c'est ce que l'équipe discute. Pour chaque sujet, déterminez s'il y a une action à entreprendre. Célébrer un succès n'a généralement pas d'élément d'action, mais la refactorisation de code spécifique peut être attribuée à une seule personne. Les éléments d'action doivent généralement être exécutables par une seule personne, mais parfois ce sont des éléments d'action «pour toute l'équipe», comme par exemple avoir à l'esprit de bons messages de validation.

La plupart des rétros ont tendance à se concentrer sur des sujets dans la triste colonne, et pratiquement aucune rétros ne discute de tout ce qui est écrit au tableau. La réunion a tendance à se terminer chaque fois que le temps est écoulé. Immédiatement après la réunion, vérifiez que les éléments d'action sont attribués à des personnes spécifiques; faites-le de la manière qui convient à votre organisation.

J'ai eu beaucoup de succès avec les rétrospectives. Ils sont un excellent moyen de renforcer la cohésion dans une équipe, et ils sont un excellent moyen de réfléchir sur la semaine précédente et d'affiner votre processus. Je pense que si vous les essayez avec votre équipe, ils seront beaucoup plus engagés pour vos réunions.

Bienvenue dans le monde de la gestion intermédiaire!

Vous allez trouver ce type de problème qui se passe BEAUCOUP!

Vous avez 3 options:

Big Stick Faites ceci ou vous êtes renvoyé - ne fonctionne jamais. Ne le fais pas.

Propriété Demandez-leur de faciliter les réunions. Prenez du recul et nommez quelqu'un d'autre. Ayez-le comme une position tournante où une personne différente accueille à chaque fois.

Dites le non-dit D'après ce que vous avez dit, tout le monde s'ennuie - alors pourquoi ne pas leur demander cela? Vous ennuyez-vous ? / Est-ce une perte de temps, etc. Pourquoi entendons-nous? Quelle en est la valeur?

La question de savoir pourquoi vous voulez faire cela n’était pas claire. Si vous êtes le seul à penser que ces éléments sont précieux, êtes-vous prêt à changer? Demandez-leur ce qu'ils veulent. Ce sont des gens du logiciel, leur travail consiste à résoudre des problèmes toute la journée - résolvez celui-ci!

Essayez de donner aux développeurs plus de valeur dans vos réunions. Voici quelques exemples:

• courtes démos montrant de nouvelles fonctionnalités développées dans le sprint récent. (présenté par tout le monde)
• une discussion sur les leçons apprises dans laquelle ils ont une chance de changer la façon dont l'équipe travaille et de s'améliorer (la discussion a mené votre main droite dans l'équipe, et vous êtes là pour justifier vos décisions de gestion. semblable à une séance de ventilation individuelle mais plus gros)
• une conférence sur un nouveau projet open source qui pourrait être pertinent ou un langage de codage différent tel que Lang ou Golang fonctionnel ou des fils verts en python. (peut-être présenté par l'un des plus jeunes développeurs, ou sous la forme d'une vidéo en ligne)
• une discussion dirigée par un ingénieur commercial décrivant un problème d'ingénierie terriblement difficile que son client essaie de résoudre. (même accord avec le responsable du support / services essayant de réduire les coûts de support en améliorant la convivialité du produit)
• une crèche qui révèle les différentes alternatives stratégiques que l'entreprise aurait pu prendre et comment cela aurait affecté l'ingénierie compte tenu du paysage concurrentiel.
• un conseiller externe qui donne des séances de conseil sur les technologies que vous utilisez déjà mais pas au maximum (généralement nosql, cep, RDBMS, mise en réseau, sécurité, monitoring ...)
• une promenade de code à travers laquelle tout le monde pourrait apprendre de nouveaux codes de codage ou de débogage ou de test de productivité (par ce développeur qui a une productivité 10x).
• une session de codage où aucune souris n'est autorisée. Apprenez le truc des raccourcis IDE.
• exposé d'un comptable sur l'argent 101 questions liées à la retraite, aux investissements
• parler de programmation sociale et de carrière (échange de pile, twitter, github, blogs personnels, LinkedIn, rencontres dans votre région)

Peut la réunion ou la tenir beaucoup moins souvent. Écrivez vos conférences dans un e-mail régulier et envoyez-les à tout le monde.

N'organisez des réunions que si les personnes qui y participent ont réellement des raisons d'y participer. Sinon, vous perdez vraiment du temps.

Ne tenez pas de longues réunions et ne tirez pas parti des logiciels de gestion de projet. Si vous souhaitez garder les gens intéressés, condensez et mettez en évidence ce qui compte et enregistrez le reste pour les journaux et les rapports du projet. Concentrez-vous sur les jalons, les livraisons, les faits saillants et les objectifs, et si cela ne s'applique qu'à 1/3 des personnes, rangez-le dans un fil de discussion de projet.

• Gardez vos réunions courtes
• Tirez parti du logiciel de gestion de projet
• Gardez-le personnel, ciblé et connectez-vous avec les émotions et les objectifs
• Résolution de problèmes dans les groupes de discussion, pas dans les forums
• Obtenez les commentaires de vos pairs

De plus, ne laissez pas les autres entrer dans la conversation et continuer leur travail à moins d'avoir défini des points qu'ils souhaitent aborder. Si vous souhaitez recevoir des commentaires, préparez-vous ou rangez-les dans un fil de commentaires quelque part en ligne où les gens ont le temps de les aborder. C'est l'un des problèmes les plus ennuyeux des réunions; donner du temps aux autres par respect. Gardez ce truc à la fin après avoir abordé tout ce dont vous avez besoin pour passer.

Prenez des directives sur votre approche de gestion de projet et encouragez les bonnes pratiques de développement en donnant l'exemple.