Reuniones de equipo efectivas

Soy líder de un equipo de 8 programadores en una compañía de aproximadamente 20 técnicos. Están trabajando en una variedad de proyectos, estos proyectos también involucran a personas de otros equipos que están fuera de mi control. Mi organización no está haciendo un desarrollo ágil adecuado, y son algo resistentes al cambio, pero he estado celebrando reuniones de pie diarias dentro de mi equipo y todos las hemos encontrado útiles y todos están comprometidos y hemos terminado dentro 10-15 minutos También tengo actualizaciones individuales semanales con cada miembro del equipo donde discutimos varios temas generales (tanto técnicos como no técnicos) con más detalle, así como varias reuniones temáticas ad-hoc.

Con lo que he estado luchando, sin embargo, es con mi reunión semanal del equipo. Está perdiendo fuerza y ​​no he podido mantener a la gente interesada.

Todavía quiero celebrar una reunión más larga, incluso si tiene que ser quincenal o mensual. El propósito era discutir varios temas que no se pueden hacer durante una reunión de pie porque requieren más tiempo. Las actualizaciones mías incluyen un resumen de cada proyecto actual en el que están trabajando (ya sea según lo programado, varios retrasos, etc.), cualquier cambio de dirección, proyectos futuros, cambios en el proceso de desarrollo, etc. Sin embargo, termina siendo una conferencia mía, y al menos 2 personas obviamente están excluidas y el resto están a lo sumo levemente interesados.

Traté de hacer que las personas se involucraran más haciéndolas hablar sobre su semana, pero con 8 personas lleva mucho tiempo y (en parte porque gran parte de su trabajo no se cruza tanto), la mayoría del resto del equipo lo hace. no me importa en qué han estado trabajando sus compañeros de trabajo con más detalle (obtienen una visión general de alto nivel durante las paradas).

Entonces, durante estas reuniones, al menos algunas personas están muy aburridas, y es casi vergonzoso para mí mantenerlas. Es un marcado contraste con nuestras vigorosas reuniones matutinas de pie.

¿Algún consejo sobre lo que puedo hacer para mantener a las personas más comprometidas y más interesadas? ¿Y cómo puedo hacer que presenten cosas en sus foros o que comiencen discusiones que involucren a todos en lugar de ser un monólogo mío?

Dijiste que las reuniones se sienten como si estuvieras dando conferencias. Si le parece así, y el equipo no parece interesado en lo que tiene que decir, ¿por qué todavía tiene la reunión? Si solo les está lanzando información, y no está atrayendo su atención, ¿por qué no resumir todo en un correo electrónico semanal?

Si desea aprovechar esa hora que tiene con todo el equipo, puede considerar realizar una retrospectiva. Puede presentar la retrospectiva con simple honestidad de su parte: dígales que no siente que las reuniones anteriores hayan sido productivas y que quiere probar algo diferente para ayudar a todos a beneficiarse de la hora que tienen juntos.

En los retros donde trabajo, vamos a tener tres columnas en una pizarra, por lo general poner un smiley, meh, y la cara triste en la parte superior, por ejemplo :), :|y :(. Luego, los miembros del equipo pueden poner cualquier cosa en la pizarra de la que les gustaría hablar con todo el grupo.

En la columna feliz, puedes celebrar los éxitos (como felicitar a Alice y Bob por el lanzamiento de un proyecto en el que trabajaron juntos), y puedes declarar la victoria con los nuevos procesos que estás probando (como el nuevo rastreador de errores es mucho mejor que el el viejo).

En la columna meh, pones cosas que no son exactamente felices o tristes para la semana. Tal vez haya comprado licencias para la nueva versión de su IDE, y alguien no haya visto ninguna ventaja del nuevo IDE, podrían poner eso en la pizarra para descubrir si todos los demás sienten que la actualización no valió la pena o si otras personas lo han hecho. encontró formas en que es realmente superior a la versión anterior.

En la columna triste, pones cosas que no han ido bien durante la semana. Identificar los puntos críticos para la semana es, en mi opinión, el mayor beneficio de una retrospectiva. Todo el equipo puede discutir soluciones a un problema real. Por ejemplo, en equipos que trabajan en una única base de código, alguien podría decir que la clase FooBar no se puede mantener y ha sido la causa de horas de depuración. De repente, descubres que todos los demás miembros del equipo también perdieron varias horas esta semana con FooBar, pero nadie dedicó tiempo a limpiarlo. En ese caso, el equipo puede decidir colectivamente que tiene sentido que alguien pase tiempo refactorizando ese código la próxima semana.

Después de que todos escriben sus temas propuestos en la pizarra, me gusta repasar brevemente cada tema y hacer que su autor dé una explicación de 10-30 segundos del tema. Esta sección de la reunión es fácil de descarrilar, por lo que tendrá que tener cuidado de mantener a las personas en el tema; por ejemplo, alguien dirá que X ha sido un problema y alguien más comenzará a hablar sobre una solución al problema; Las soluciones no deben discutirse hasta después de la votación. Al presentar los temas, puede encontrar formas de agrupar varios temas relacionados estrechamente.

Después de las presentaciones, todos obtienen tres votos que pueden distribuir entre los temas como mejor les parezca. Finalmente, los votos son contados, y cualquier tema que tenga el mayor número de votos es lo que el equipo discute. Para cada tema, determine si hay una acción que deba tomarse. La celebración de un éxito generalmente no tiene un elemento de acción, pero la refactorización de código específico se puede asignar a una persona. Los elementos de acción generalmente deben ser completables por una persona, pero a veces son elementos de acción de "todo el equipo", como ser consciente de tener buenos mensajes de confirmación.

La mayoría de las retros tienden a centrarse en los temas de la columna triste, y prácticamente ninguna retros discute todo lo que está escrito en la pizarra. La reunión tiende a terminar siempre que se acabe el tiempo. Inmediatamente después de la reunión, verifique que los elementos de acción se asignen a personas específicas; haga esto de la manera que tenga sentido para su organización.

He tenido un gran éxito con las retrospectivas. Son una excelente manera de crear cohesión en un equipo, y son una excelente manera de reflexionar sobre la semana anterior y refinar su proceso. Creo que si prueba esto con su equipo, estarán mucho más comprometidos con sus reuniones.

¡Bienvenido al mundo de la gerencia media!

¡Va a encontrar que este tipo de problema sucede MUCHO!

Tienes 3 opciones:

Big Stick Haz esto o te despiden, nunca funciona. No lo hagas

Propiedad Consíguelos para facilitar las reuniones. Da un paso atrás y nomina a alguien más. Téngalo como una posición giratoria donde una persona diferente aloja cada vez.

Habla lo tácito Por lo que has dicho, todos están aburridos, entonces ¿por qué no preguntarles eso? Estas aburrido ? / ¿Es esto una pérdida de tiempo, etc. ¿Por qué nos escuchan? ¿Cuál es el valor en esto?

No estaba claro en su pregunta por qué quiere hacer esto. Si usted es el único que siente que estos son valiosos, ¿está dispuesto a cambiar? Pregúntales qué quieren. Son personas de software, su trabajo es resolver problemas todo el día, ¡resuelve este!

Intente dar a los desarrolladores más valor en sus reuniones. Algunos ejemplos pueden ser:

• demostraciones cortas que muestran nuevas características desarrolladas en el reciente sprint. (presentado por todos)
• una discusión de lecciones aprendidas en la que tienen la oportunidad de cambiar la forma en que el equipo trabaja y mejora (la discusión llevó su mano derecha al equipo, y usted está allí para justificar sus decisiones de gestión. similar a una sesión de ventilación 1 a 1 pero más grande)
• una conferencia sobre un nuevo proyecto de código abierto que podría ser relevante o un lenguaje de codificación diferente, como Lang o Golang funcionales o hilos verdes en python. (quizás presentado por uno de los desarrolladores más jóvenes, o en forma de un video en línea)
• Una discusión dirigida por un ingeniero de ventas que describe un problema de ingeniería terriblemente difícil que su cliente está tratando de resolver. (mismo trato con el gerente de soporte / servicios que intenta reducir los costos de soporte al mejorar la usabilidad del producto)
• un pesebre que revela las diversas alternativas estratégicas que la compañía podría haber tomado y cómo habría afectado a la ingeniería dado el panorama competitivo.
• un asesor externo que brinda sesiones de consultoría sobre tecnologías que ya usa pero no al máximo (generalmente nosql, cep, RDBMS, redes, seguridad, monitoreo ...)
• un recorrido por el código en el que todos pueden aprender nuevos códigos de codificación o depuración o pruebas de productividad (por ese desarrollador que tiene una productividad 10 veces mayor).
• una sesión de codificación donde no se permite el mouse. Aprenda los atajos IDE cosita.
• charla de un contador sobre dinero 101 temas relacionados pensiones, inversiones
• hablar sobre programación social y carrera (intercambio de pila, twitter, github, blogs personales, LinkedIn, reuniones en su área)

¿Puede la reunión o celebrarlo con mucha menos frecuencia? Escriba sus conferencias en un correo electrónico regular y envíelo a todos.

Solo tenga reuniones si las personas en ellas realmente tienen razones para participar en ellas. De lo contrario, realmente está perdiendo el tiempo de la gente.

No celebre largas reuniones y aproveche el software de gestión de proyectos. Si desea mantener a las personas interesadas, condense y resalte lo que importa y guarde el resto para los registros e informes del proyecto. Concéntrese en los hitos, las entregas, los aspectos más destacados y los objetivos, y si solo se aplica a 1/3 de las personas, guárdelo para un hilo de discusión del proyecto.

• Mantenga sus reuniones cortas
• Aproveche el software de gestión de proyectos
• Manténgalo personal, decidido y conéctese con las emociones y los objetivos.
• Resolución de problemas en grupos focales, no en foros
• Obtenga comentarios de sus compañeros

Además, no permita que otros salten a la conversación y continúen con su trabajo a menos que tengan puntos establecidos que quieran abordar. Si desea comentarios, prepárese o guárdelo para un hilo de comentarios en algún lugar en línea donde las personas tengan tiempo de abordarlo. Este es uno de los problemas más molestos con las reuniones; dando tiempo al piso a los compañeros por respeto. Mantenga esas cosas al final después de haber abordado todo lo que necesita para transmitir.

Tome directivas sobre el enfoque de gestión de su proyecto y fomente las buenas prácticas de desarrollo liderando con el ejemplo.