¿Cómo hacer que las reuniones de Scrum of Scrums sean más productivas?

En mi trabajo, tenemos una reunión de Scrum de Scrums donde se reúnen todos los Scrum Masters. Esta reunión se está convirtiendo en una reunión aburrida donde todos dan su actualización de estado. Estoy tratando de hacer que la reunión de Scrum de Scrums sea más proactiva, donde Scrum Masters estará más involucrado con otros Scrum Masters, y donde es más un momento para Scrum Masters llamar dependencias en otros equipos y acordar una solución para eliminar esas dependencias.

¿Cuál es el propósito de la reunión? ¿Es una reunión de coordinación del equipo para identificar las cosas que un equipo podría hacer que afectarán a otro o es una comunidad de práctica de Scrum Master para avanzar en el estado del arte dentro del grupo Scrum Master?
Iba a ofrecer una recompensa por esta pregunta porque creo que es una pregunta de amplia aplicación, pero ha recibido muy poca atención. Sin embargo, hay un error de recompensa de PMSE , por lo que quizás un usuario con un representante para quemar quiera recompensarlo para ver si podemos atraer más atención a esta gran pregunta.
Hola, @CodeGnome, antes de ofrecer una recompensa, sugiero editar la pregunta para que quede claro qué falta y qué espera obtener como respuestas, ya que ya hay 3 excelentes respuestas... En este caso particular, si sus ediciones cambiaría sustancialmente la pregunta, incluso podría ser mejor publicar una nueva pregunta si lo que está buscando no está cubierto en esta. ¡Espero que esto ayude! ¡Buena suerte! :)

Respuestas (5)

La reunión de coordinación de nuestro equipo también se estaba volviendo muy obsoleta, así que hicimos algunas cosas para tratar de mejorarla, lo que parece haber funcionado bastante bien.

  • Enfocamos nuestra reunión de coordinación de equipo alrededor de un tablero, similar a las reuniones de equipo.
  • Cada equipo tiene un carril de natación y coloca una tarjeta que indica en qué están trabajando ahora y después. Esto brinda a los equipos la oportunidad de cuestionarse entre sí cuando existe una dependencia entre ellos, que es nuestra razón principal para ejecutar la sesión.
  • Realizamos un seguimiento de las acciones que han realizado los equipos en el tablero y las revisamos cada semana.
  • Contamos con un proceso para escalar al equipo superior.
  • Cualquiera puede venir, pero debe estar presente un desarrollador senior de cada equipo . Introdujimos esto porque descubrimos que otros miembros del equipo carecían de la comprensión técnica de nuestra plataforma para identificar realmente dónde los equipos se iban a causar problemas entre sí.
  • Mantenemos las tarjetas de las 4 semanas anteriores en la pizarra para proporcionar una referencia rápida de lo que la gente ha estado trabajando.

Ejemplo de tablero

Arriba hay un ejemplo de nuestro tablero.

Sugiero cambiar la forma en que se facilita la reunión de Scrum of Scrum. En lugar de hablar sobre cosas habituales y sobre las tres preguntas , me centraría solo en los siguientes puntos clave y debatiría sobre ellos:

  • Qué equipo entregará hoy : Aquí otros equipos sabrán que algo nuevo (paquete, código, etc.) llegará a su escritorio.
  • ¿Hay algún cambio que se pueda mencionar en los gráficos de trabajo pendiente ?: Otro indicador de que un equipo recibirá algo antes o después de lo esperado.
  • ¿Hay algún cambio en el backlog ? De nuevo, un cambio global importante.

La idea es centrarse sólo en aquellas cosas que afectan a otros equipos . Para hacerlo de manera efectiva, los equipos deben discutir qué llevar a las reuniones de Scrum of Scrum. No debería ser algo que el ScrumMaster descubra. Si el equipo no tiene nada que decir, que el SM diga que no hay nada que agregar a la reunión. Si sucede en múltiples ocasiones, entonces algo está sucediendo a nivel de equipo, lo cual vale la pena revisar.

Además, hay algo más que vale la pena revisar. ¿Cómo es que las personas ágiles convierten su propia reunión en una reunión de estado? No me malinterpreten, nuestros ScrumMasters lo hacen todo el tiempo, pero es posible que pueda encontrar una buena razón y solucionarlo. Todavía no sabemos por qué lo hacen, y ellos tampoco.

Aquí escribí en un blog sobre algunas variantes diarias de stand-up, también puede encontrar algo útil allí.

Definición de Scrum de Scrums

Hay una serie de libros sobre cómo escalar Scrum y estoy seguro de que existen otras definiciones, pero voy a compartir mi definición personal contigo.

Un scrum-of-scrums standup es una reunión de coordinación de dependencias entre equipos scrum.

Idealmente, un scrum de scrums debería tener un Scrum Master separado que no esté usando el sombrero de Scrum Master para otro equipo. Esa persona debería ser el árbitro que haga sonar el silbato cada vez que la reunión comience a desviarse de la vía ágil.

Kanbans humanos

Piense en cada Scrum Master que asiste al scrum-of-scrums standup como un kanban humano. El trabajo de esa persona es:

  • Notifique a los otros equipos que un elemento de trabajo de flujo de valor está listo para ser extraído del equipo de ese Scrum Master.
  • Alerte a los demás equipos de que algún elemento de trabajo está ocupando un espacio de trabajo en curso entre equipos y está atascado dentro del equipo del Scrum Master porque se ha descubierto un defecto o un cuello de botella en el proceso.

En otras palabras, esta debe ser una breve reunión de coordinación y compromiso entre Scrum Masters, en lugar de una revisión, revisión o retrospectiva de estado. Sin embargo, sin un Scrum Master designado para actuar como árbitro del proceso y sin un fuerte compromiso organizacional para inspeccionar y adaptar el nivel de scrum de scrums, las reuniones como la descrita en la pregunta son demasiado comunes.

Estoy de acuerdo con la mayoría de las sugerencias anteriores si está haciendo un scrum de scrums de Scrum Master. Me preguntaría cuál es el propósito de esa reunión. Si se trata solo de la coordinación técnica de las actividades inmediatas, entonces concéntrese en eso y los maestros de scrum (o desarrollador senior) deberían poder manejarlas.

Si el enfoque es mantener a los equipos coordinados más allá de las dependencias técnicas, podría sugerir un scrum de propietarios de productos (suponiendo que tenga propietarios de productos/analistas comerciales o similares en cada equipo) también o incluso en su lugar. Estas personas son responsables de mantener la visión general y garantizar que se satisfagan las necesidades comerciales en lugar de solo mirar el software. En particular, a medida que pasa de estar centrado en el software a centrarse en la solución, la visión más amplia a menudo traerá áreas de enfoque en las que un equipo debe preocuparse más allá de la codificación.

De cualquier manera, usaría el scrum de scrums como algo más que una simple coordinación inmediata entre equipos y una reunión periódica para ver el panorama general del producto (o sprint o lanzamiento).

Scrum enfatiza no solo los equipos autoorganizados, sino también la colaboración de equipos multifuncionales para un mejor rendimiento. Conocida como Scrum de Scrums, esta práctica es importante para proyectos grandes y multidimensionales que requieren que varios departamentos y equipos trabajen en estrecha colaboración para que el desempeño general sea tan efectivo como en proyectos pequeños que involucran equipos más pequeños. La clave de este elemento escalable es el Scrum de Scrums, conocido en el lenguaje tradicional como “gestión de programas”.

Scrum of Scrums es una muy buena práctica, pero su éxito depende de dos factores clave: una coordinación eficaz y un administrador de programas eficiente. Si una o ambas de estas condiciones no se cumplen, Scrum of Scrums demuestra ser el Waterloo de todo el proyecto.

En proyectos que involucran un solo equipo de pocas personas, Scrum Master es el guía y el mentor que conduce al equipo en la dirección correcta. Sin embargo, con varios equipos trabajando juntos en el mismo proyecto, tiene que haber un gerente que pueda coordinarse de manera efectiva entre los equipos. En tal escenario, cada equipo tiene su propio Scrum Master que a su vez se coordina con los Scrum Masters de los otros equipos bajo la guía y supervisión de un administrador general del programa, conocido como Agile Program Manager. Fuente: http://scrum-master.info