Cómo aplicar reuniones diarias de pie con un gran equipo en múltiples proyectos

opción 1 : podría funcionar si haces estas paradas extremadamente rápidas y eficientes (15 min es el máximo, la parada podría ser mucho más corta)

opción 2 : me parece un desastre; teniendo tantas personas y proyectos, sería imposible procesarlo todo de manera significativa y aún así mantenerlo por debajo de los 15 minutos; podrías terminar con largas y aburridas "paradas" (las he visto)

Votaría por la opción 3 : intente dividir a su gente en varios equipos y minimice la cantidad de proyectos por equipo (el cambio de contexto requiere mucha capacidad intelectual). El equipo ideal de SCRUM tiene de 5 a 8 personas (afaik).

si puede suspender algunos de sus proyectos, hágalo.

El entorno son múltiples sitios de comercio electrónico y SaaS, por lo que en un momento dado algo puede romperse y enviar todos los planes al viento.

en este caso, puede pedirle a uno de los equipos que se ocupe del problema (o simplemente asignar a uno de los equipos para que sea un equipo de "soporte de productos", por un sprint o para siempre).

Los problemas

Leyendo un poco entre líneas, parece que tienes algunos problemas relacionados.

1. Su "equipo" es demasiado grande para ser verdaderamente ágil. Es posible que desee considerar dividirse en equipos de tigre multifuncionales con un enfoque en lugar de una organización matricial de múltiples proyectos.

2. El propósito de su stand-up realmente no ha sido definido. Los stand-ups verdaderamente ágiles son reuniones de coordinación de tareas, no extracciones de estado de PM.

3. Tiene cuatro gerentes de proyecto, todos los cuales presumiblemente quieren secuestrar los stand-ups para obtener el estado de lo que sea que estén enganchados ese día.

Algunas soluciones potenciales

No hay respuestas fáciles aquí, pero está claro que necesita rediseñar el proceso. Algunas sugerencias incluyen:

1. Dividir en equipos de proyecto de no más de 6-9 miembros del equipo. Si las personas necesitan formar una matriz, simplemente ajuste sus expectativas (y estimaciones) a la baja para tener en cuenta la realidad de los gastos generales de cambio de tareas.

2. Dividir los proyectos entre los PM. Cuatro gerentes de proyecto enfocados en los mismos proyectos son demasiados cocineros en la cocina.

3. Nunca, jamás, utilices los stand-ups como una palanca de estatus. Acosar a la gente por su estatus en otro momento. Use un solo stand-up cada día para permitir que los miembros del equipo coordinen sus tareas para ese día entre sí.

4. Limite los compromisos realizados durante el stand-up a las tareas que se pueden entregar el día actual . Bob necesita algo de Joe para el final del día; ¿Joe puede entregar, o tiene una dependencia que el equipo necesita saber?

5. Organice un stand-up por separado cada día solo para los gerentes de proyecto. Ya sea un Scrum-of-Scrums o simplemente un concurso de "mi hoja de cálculo de Excel es más grande que la tuya", no importa; esta es la reunión donde se deben resolver las dependencias entre proyectos y los problemas de seguimiento, no durante la reunión del equipo de desarrollo.

Costos organizacionales

La conclusión es que su proceso actual es difícil de manejar. Eso no lo hace incorrecto , pero ciertamente lo hace costoso en términos de gastos generales del proceso. En la medida de lo posible, debe trabajar duro para:

1. Reducir los costos organizacionales de los gastos generales del proceso.
2. Haga que los gastos generales sean un costo explícito para la organización y cada proyecto.

Por ejemplo, si su equipo realmente necesita pasar más de 5 horas a la semana en actualizaciones de estado y reuniones, eso es un mínimo de 75 horas-hombre a la semana que debe tener en cuenta en su plan de proyecto y su presupuesto. Una vez que esos costos se hacen claramente visibles para la organización, la alta gerencia puede tomar decisiones informadas sobre si los beneficios del proceso actual superan los costos.

La solución fácil es tener solo un standup que sea para el equipo . Mi recomendación es hablar solo del próximo trabajo y centrarse en aquellos problemas que pueden causar algunos problemas más adelante , como tareas cruzadas, tareas de integración, tareas que están en el tablero durante mucho tiempo.

Con este enfoque, las tres preguntas orientadas al personal deben transformarse en una pregunta orientada a la tarea, pero para proyectos grandes, este tipo de configuración es mucho más eficaz. Como mencioné antes, hay que hablar de asuntos, y el orden recomendado es de derecha a izquierda en el tablero, porque hay tareas que están cerca de terminar. Si pasaron los 15 minutos, detenga la reunión y vea qué se puede hacer de manera diferente la próxima vez para que se ajuste al marco de tiempo. Un truco adicional es hablar sobre aquellos temas que tienen una señal de alto, porque esos son los que deben discutirse con todo el equipo (cómo desatascarlos).

Dices que quieres que la organización sea ágil. Tenga cuidado, ya que esto puede ser un cambio significativo y puede generar resistencia e ineficiencias al menos en el corto plazo. Realmente necesitará planificar esto y contar con la aceptación de su equipo de alta gerencia para que lo respalde en esta tarea antes de intentar implementarla para que pueda abordar de manera proactiva problemas como el que plantea. De lo contrario, se está preparando a usted mismo y a su organización para el fracaso.

Tal vez un mejor primer paso es usar Agile como marco en lugar de seguirlo al pie de la letra. No tiene sentido implementar un sistema para mejorar la eficiencia con un nivel de burocracia que anula cualquier ganancia que pueda obtener. ¿Realmente necesita stand-ups para todos los proyectos todos los días? ¿O puede salirse con la suya haciendo stand-ups cada dos días? ¿Puede limitar el trabajo ágil a menos proyectos para que el equipo pueda familiarizarse con él?

Con 18 personas trabajando en 11 proyectos, debe tener muchas tareas múltiples en marcha. Esto arrastrará hacia abajo todos los proyectos.

Como otros han señalado, es posible que desee crear algunos equipos multifuncionales. Dado que tiene cuatro PM, es posible que desee considerar la creación de cuatro equipos. Eso te dejará corto en algunos recursos y tendrás que compartir los recursos más escasos. Estos serán equipos bastante pequeños. Los PM deben reunirse con frecuencia para tratar temas como la priorización de proyectos, la distribución del trabajo y la dotación de recursos.

Con cuatro equipos, debería poder hacer que cada equipo haga un stand-up rápido con recursos compartidos que asisten a un par de stand-ups. Es posible que desee agregar un stand-up adicional para los gerentes de proyecto.

Trate de tomar un equipo y dedicarlo a un proyecto más corto. Si no son arrastrados entre proyectos, deberían ser más efectivos. Con cuatro equipos podrás experimentar con el proceso. Si esto funciona, puede estar en posición de abogar por equipos más dedicados.

Según mi experiencia, las organizaciones matriciales tienden a tener problemas para mantener al personal en contacto con sus grupos funcionales. Permita algo de tiempo para que los grupos funcionales se reúnan y manejen sus problemas y desarrollen sus habilidades.

Usted dice "Mi objetivo a corto plazo es implementar stand ups diarios"; este no es un objetivo difícil. Si esto es útil no es importante, así que haz reuniones diarias. Tu objetivo debe ser terminar los proyectos lo antes posible, y tu trabajo es encontrar el proceso que satisfaga eso. Tal vez eso sea paradas diarias y tal vez no.

Estoy en una situación similar a la tuya:

• Gran equipo de más de 12 miembros (backend + ios + desarrolladores de Android, evaluadores)
• 6 proyectos. Algunos proyectos necesitan la colaboración de equipos de otras empresas.
• Soy el único PM del equipo.

En el desarrollo de software de la vida real, es deseable gestionar un equipo con un número fijo de personas trabajando en un solo proyecto, pero no solemos estar en esta situación. Por ejemplo, cuando un proyecto se suspende debido a la dependencia con otros equipos (lo que a veces no podemos controlar), necesitamos trasladar temporalmente a los miembros a otros proyectos. Otras veces necesitamos tener una copia de seguridad (en caso de que el único desarrollador de iOS/Android se vaya), para que una persona que trabaje en un proyecto también pueda aprender y trabajar en otros proyectos.

En este caso, es realmente difícil aplicar todas las palabras de Agile . En cambio, tenemos una reunión de pie para cada proyecto cada dos días, es decir, hoy tenemos una reunión para el proyecto 1, 2, 3; mañana tenemos reunión para el proyecto 4,5,6; y luego pasado mañana, proyecto 1, 2, 3 de nuevo.

En la reunión de hoy, no pediré a todos los del proyecto 1, 2, 3 que asistan a la reunión desde el principio hasta el final . Al principio, le pregunto a A, B y C que trabajan en el proyecto 1: tenemos una reunión de pie para el proyecto 1. Después de eso, invito a D, que trabaja en el proyecto 2, a reunirse y libero a A, ya que no está trabajando en el proyecto 2. Ahora B, C y D tendrán reunión para el proyecto 2, y así sucesivamente.

Esto no es Agile, pero hasta ahora estamos contentos con el enfoque actual. Los desarrolladores no necesitan pasar demasiado tiempo escuchando información no relacionada, y obtuvimos suficiente información para trabajar durante 2 días entre reuniones. Si surge alguna pregunta, estamos dispuestos a discutir en persona o convocar una reunión durante la jornada laboral .

Después de todo, la reunión de pie es solo una herramienta; Es posible que no responda a todas las preguntas: debe responder la mayor cantidad posible de la manera más eficiente y utilizar otras herramientas (comunicación durante la jornada laboral) para respaldarlo.