Me hicieron una pregunta interesante para la que no tengo una respuesta estricta. Solo tengo sugerencias, por lo tanto, me gustaría hacerle la misma pregunta:
¿Cómo cree que deberían manejarse las reuniones regulares de scrum cuando se trata de tiempo? Digamos que tiene sprints de 2 semanas de duración, entonces en teoría: Planificación - 4 horas como máximo Revisión - 2 horas como máximo Retro - 1,5 horas como máximo
Ahora la secuencia para mí es clara -> Planificación de Sprint -> Revisión de Sprint -> Retrospectiva de Sprint.
La pregunta es -> ¿debería suceder todo esto en un día (por supuesto, dado el hecho de que puede ser más corto: planificación 1 hora, revisión 1 hora, retro 1,5 horas)?
En mi opinión, los beneficios de tal distribución son que, al tener todas estas reuniones en un día, tenemos el resto del tiempo en sprint para trabajar en historias de usuarios, discusiones de proyectos, actividades de refinamiento de cartera de pedidos, etc. - trabajo regular.
Sin embargo, pasar todo el día en reuniones puede hacer que sean ineficaces y que el equipo sea menos activo y que se pierdan las ideas de Scrum.
Dividirlos en dos días nuevamente hace que dos días sean un poco menos productivos cuando se trata de trabajo regular, sin embargo, el equipo debería poder beneficiarse más de una mayor actividad durante las reuniones.
Mi idea es que no hay una respuesta estricta y uno debe tener en cuenta el contexto del equipo, PO, proyecto, etc. y adaptarlo para que se ajuste mejor a las necesidades del equipo.
¿Cuáles son sus opiniones?
La respuesta más simple es preguntarle al equipo. Vaya con lo que se sienta más cómodo. Si no funciona, adapte y cambie las reuniones.
He trabajado con algunos equipos que prefieren tener todas las reuniones en un día. Lo ven como un día de 'no intervención' y les gusta quitarse de en medio en lugar de tener reuniones dispersas.
A otros equipos no les gusta pasar todo el día en reuniones y descubren que la planificación es menos efectiva al final de un ajetreado día de reuniones.
La pregunta es -> ¿debería suceder todo esto en un día (por supuesto, dado el hecho de que puede ser más corto: planificación 1 hora, revisión 1 hora, retro 1,5 horas)?
La cadencia típica de una ceremonia de Scrum es organizar Sprint Planning y luego, en el punto medio de la caja de tiempo, ejecutar una ceremonia de Refinamiento de Backlog. La revisión del sprint ocurre al final de la caja de tiempo, ya que es cuando vence el trabajo que el equipo se comprometió a entregar. Finalmente, se lleva a cabo una retrospectiva del Sprint para analizar las mejoras en el entorno de trabajo y las prácticas antes del próximo Sprint.
Tradicionalmente, para un Sprint de dos semanas sería
Sé que algunos equipos han experimentado con sprints de lunes a viernes, sprints de miércoles a miércoles, pero no he encontrado una práctica de trabajo que coloque la revisión del sprint, la retrospectiva y luego directamente la planificación en el mismo día.
Personalmente, creo que cualquier beneficio que surja de concentrar todas las ceremonias en un solo día sería erradicado por la grave caída de la moral y la concentración que se derivaría de tal técnica.
Mi respuesta firme es que las ceremonias de Scrum deben ocurrir durante dos días como mínimo, pero idealmente un tercer día incorporaría el refinamiento de la acumulación.
Creo que Sprint Planning es una introducción bastante relajada a la nueva semana y planificamos los lunes. Siempre me aseguro de llegar con bocadillos y bebidas para el equipo (queso, donas, café gourmet, etc.).
Comenzamos la planificación de Sprint aproximadamente 1 hora después de que comience la jornada laboral, lo que le da tiempo al equipo para revisar los correos electrónicos después del fin de semana y cotejar todos sus compromisos, días festivos y limitaciones antes de llegar a la sesión de planificación.
De hecho, ejecutamos una sesión de Planificación de Sprint de tres horas, pero esa es una adaptación que encontramos debido a nuestro flujo de trabajo.
Normalmente termina alrededor de las 12:15, momento en el que hacemos una pausa para almorzar. En ese descanso coloco cada una de las cartas comprometidas de nuevo en el tablero y el equipo regresa del almuerzo listo para comenzar a trabajar recogiendo sus primeras cartas alrededor de la 1 p.m.
Nuestra agenda de planificación de Sprint es la siguiente (siéntase libre de robar)
Para las retrospectivas de Sprint, utilizamos un round robin de ideas de Retromat , un generador de retrospectivas.
Como dijiste, no hay necesariamente una respuesta "correcta". Sin embargo, en los equipos con los que trabajé, lo divido en dos días, pero es la tarde del primer día y la mañana del segundo. El mayor éxito que he tenido hasta ahora ha sido
Día 1:
Retrospectivo
Revisión de Sprint
--Fin del día--
Dia 2:
--Comienzo del día--
Planificación de Sprint
Personalmente, me gusta tener la retrospectiva antes de la planificación del sprint porque a menudo encuentro que el equipo decide hacer cosas en el siguiente sprint que deben tenerse en cuenta en la planificación. El orden del día 1 puede ir en cualquier dirección. Retro antes de la revisión corre el riesgo de perderse cosas de la revisión en el retro, que por otro lado corre el riesgo de que los elementos de revisión anulen las lecciones importantes de todo el sprint. Entonces, los cambiaré dependiendo del equipo. Tener la planificación a primera hora el día 2 significa que las personas llegan frescas y las otras reuniones todavía están claramente en la memoria, pero no están poniendo a prueba su capacidad para concentrarse en la planificación.
Estoy de acuerdo en que no hay una respuesta correcta y realmente depende del equipo.
Dicho esto, la forma en que dirige las reuniones tiene un gran impacto en las cosas. Esto se refiere a la facilitación básica de reuniones y no es específico de Agile.
Publique una agenda con anticipación: en promedio, la mitad de su equipo odia ser sorprendido. Quieren ir a una reunión bien preparados. Esto incluye proporcionar una actualización sobre el trabajo pendiente actual en el correo electrónico o en la invitación del calendario, incluso si es fácil de extraer de la herramienta que elija.
Publicar la agenda durante la reunión. Una agenda que se muestra en la primera diapositiva de un mazo .ppt (un crimen mayor en cascada) es inútil tan pronto como cambias de diapositiva. Publique la agenda claramente para que todos la vean.
Asegúrese de que haya un reloj en la habitación, grande y fácil de leer. Sí, todos tienen un teléfono celular. Eso requiere más esfuerzo y atrae más atención (de todos) que una mirada rápida a un reloj de pared. También significa que todos están exactamente al mismo tiempo.
Haz una agenda basada en el tiempo. La agenda de Venture es excelente. Sin embargo, póngalo en horas de reloj, por lo que "Reunión abierta: 10:00, Planificación y visión: 10:05, Estado de desarrollo y arquitectura: 10:10". Al poner la hora en que comienza el elemento de la agenda, hace que sea mucho más fácil rastrear su agenda. Si son las 10:15 y aún no ha iniciado Dev and Arch Status, sabe que necesita eliminar 5 minutos de Dev y Arch o ponerse de acuerdo con el equipo para eliminarlo en otro lugar.
Planifique y programe descansos: la ciencia y los años de experiencia nos han demostrado que la mente humana no puede permanecer enfocada por más de 90 minutos seguidos. Después de esto, incluso el tema más atractivo comenzará a perder el foco. Planifique sus descansos en la agenda y luego hágalos cumplir. Los ingenieros son conocidos por el síndrome de "sigamos adelante, ya casi terminamos". Es posible que se hagan más rápido, es posible que no hayan surgido los problemas correctos porque los cerebros estaban demasiado confusos.
Limite la tecnología: un buen equipo ágil en funcionamiento ya lo sabe. Si todos tienen su computadora portátil abierta y activa, consumirá energía. La mayoría de los equipos exitosos que conozco harán toda su planificación con un muro anticuado y lo publicarán y luego lo transferirán a la herramienta electrónica de su elección. Incluso apoyaría un tazón de teléfono, donde todos ponen su teléfono durante la planificación. Pueden tenerlos en los descansos.
Nuevamente, no es ágil, solo una buena facilitación de reuniones que puede hacer que una ceremonia ágil sea aún más efectiva.
Nuestro equipo prefiere tener todas las reuniones en un día. Nuestro horario es el siguiente, cada dos martes:
El aseo se lleva a cabo los martes a mitad del sprint. Este cronograma fue sugerido en mi clase de capacitación de Scrum Master, y está funcionando muy bien para nosotros.
En mi opinión, estos deberían ser generalmente a lo largo de dos días.
Sin embargo, depende del tamaño, las preferencias, etc. del equipo, pero también de la duración de los sprints. El equipo debe decidir colectivamente sobre esto de acuerdo con los valores de Scrums. @CodeGnome preguntó de dónde sacó @Arek sus tiempos. Estos se basan en reducir a la mitad los cuadros de tiempo máximo de las guías de scrum para un sprint de 1 mes.
Las razones por las que creo que generalmente debería ser de dos días se deben tanto al enfoque como al contexto.
En primer lugar, tener un día lleno de reuniones generalmente no es una buena idea, ya que las personas pierden el enfoque fácilmente y se pierden algo. Esto puede aliviarse un poco teniendo descansos regulares, digamos cada hora si es un requisito.
En términos de contexto, estamos viendo elementos de un sprint y luego elementos de otro sprint, por lo que es bueno darles un descanso en el medio.
También hay una sobrecarga comercial general que se debe considerar, y que alguien más mencione, con respecto a la revisión de correos electrónicos y otras actividades comerciales. Se debe dar tiempo para que se realicen, teniendo en cuenta que nadie debe estar completamente asignado a un sprint para tener en cuenta estos de todos modos.
Si se encuentra en una situación en la que quedan unas pocas horas al final del día, estas actividades adicionales se pueden completar junto con potencialmente algo de capacitación para que nunca se pierda el tiempo.
Sin embargo, volviendo a mi comentario anterior, lleve esta información al equipo y déjelos decidir colectivamente. No está escrito en piedra y también puede cambiar con el tiempo de acuerdo con Kaizen.
Todd A. Jacobs
Arek
yegor256