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.
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.
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:
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í.
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.
Piense en cada Scrum Master que asiste al scrum-of-scrums standup como un kanban humano. El trabajo de esa persona es:
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
ben
Todd A. Jacobs
jmort253