Somos un equipo de 7 desarrolladores, 2 pasantes, un especialista en experiencia de usuario y un miembro de control de calidad. El equipo suele tratar con nuevos clientes. No todos los miembros están involucrados en el mismo proyecto; normalmente hay dos clientes paralelos con 3 o 4 equivalentes a tiempo completo asignados. Pocos miembros están involucrados en ambos proyectos al mismo tiempo y uno o dos se encargan de los pasantes.
Para cada proyecto hemos separado las tareas pendientes y las ceremonias programadas en diferentes momentos. Tratamos de no superponer estas reuniones para que los miembros comunes puedan asistir a ambas. esto va bien
Sin embargo, todo el equipo está haciendo la reunión diaria (DM) juntos.
Entonces comenzamos con el Proyecto A, los miembros involucrados con el Proyecto A presentan su progreso, los impedimentos y lo que pretenden hacer durante el resto del día y una vez que esto termine, llegamos al Proyecto B. Luego los pasantes presentarán su progreso a nosotros.
Hay varios problemas con esto. Los miembros involucrados únicamente en un proyecto no tienen contexto sobre el otro proyecto, porque no participan en las otras reuniones, ni en el desarrollo. Reconocen algunos términos, ideas y verbos, pero todavía no pueden comprender realmente de qué están hablando los otros miembros. Comienzan a aparecer signos visibles de aburrimiento, como revisar el teléfono, caminar de un talón a otro con impaciencia, poner los ojos en blanco repentinamente o sonrisas poco educadas. Esto presiona al otro equipo para que acelere su DM y, por lo tanto, no se están enfocando realmente en los impedimentos reales o en la sincronización entre los desarrolladores que están trabajando en una determinada historia/tarea.
Los DM no toman más de 10 a 14 minutos para ambos proyectos juntos.
Además de eso, el Proyecto A tiene una reunión diferente con el Product Owner (PO) media hora después de esta reunión en ciertos días de la semana (M, W, F). Esta reunión no es más que una actualización de estado de la orden de compra, pero en realidad no ayuda al proyecto. Acordamos hoy que al menos en estos días no tener los dos y tener solo el del PO y discutir aquí el DM de siempre. El PO obtiene más contexto por lo tanto.
Los argumentos para mantener el DM con todo el equipo son dos. Primero, el hecho de que, bueno, somos un equipo y este es el único momento en que estamos todos juntos, así que lo usamos para unir al equipo. La otra es para que todos sepan qué está pasando, en qué está trabajando cada uno, de qué trata el otro proyecto o qué elementos de apoyo aparecen de proyectos más antiguos (aunque no muy a menudo).
Solo tengo 1,5 años de experiencia con Scrum y no estoy seguro de cómo debemos proceder con esto. Siento que tener un DM por proyecto es mejor, pero recibo un fuerte 'NO' en contra de miembros clave, algunos creen que quiero intentar dividir el equipo.
¿Cómo debemos lidiar con esto?
Esto es romper una de las reglas fundamentales de Scrum, que sería "un equipo, una meta, una responsabilidad". Es increíblemente difícil para un equipo trabajar en dos cosas al mismo tiempo, lo he visto intentarlo en múltiples ocasiones, pero nunca lo he visto funcionar.
(De hecho, la última vez que vi que lo intenté fue a principios de este año, con mi equipo, y el resultado final fue que el equipo se fracturó y tuvimos que hacer nuevos equipos).
Mi sugerencia honesta sería: dividirse en dos equipos. Tiene suficiente gente para dirigir dos equipos más pequeños, y el tiempo que dedica a una reunión para un proyecto en el que no trabaja es básicamente una pérdida de tiempo colosal. Ya habrás notado esto para todas las demás ceremonias, pero también se aplica a la diaria. De todos modos, su equipo está en el lado "demasiado grande" de un equipo scrum, por lo que no debería doler mucho dividirse de todos modos.
Además, siempre que sea un equipo, eso también significa que, según Scrum, todo su equipo es responsable de ambos proyectos, lo que significa que si alguno de ellos está retrasado, todo el equipo debe trabajar en el más importante. Supongo que tampoco estás haciendo eso, lo que significa que efectivamente ya tienes dos equipos.
Pero si quiere mantenerlo como un gran equipo , divida el scrum diario de todos modos. Si la gente se aburre durante el día a día, es que algo anda mal, y en este caso es simplemente que una actualización para un proyecto que no es tuyo no sirve de nada. Deja que la gente trabaje. En general, en cualquier reunión, si siente que su presencia no está aportando nada, abandone esa reunión. Eso va para el diario también.
En mi equipo anterior, el último esfuerzo para mantener el equipo unido a pesar de trabajar en dos proyectos diferentes fue realizar una breve reunión de felicidad antes del almuerzo, donde ambos grupos de proyectos se reunieron para compartir cómo se sentían y celebrar juntos cualquier éxito. Eso al menos mantuvo algo de espíritu de equipo, pero en última instancia, dividir el equipo y formar nuevos equipos para cada proyecto fue, con mucho, la mejor opción.
Dos cosas tienen que suceder:
Hay que dejar de lado la reunión diaria con ambos equipos. En mi experiencia, no genera mucho valor para todos los puntos que usted y Erik mencionaron. En su lugar, debe adaptar sus ceremonias según el siguiente punto
Una de estas sugerencias dependiendo de su situación:
De la Guía Scrum :
Los Equipos Scrum se organizan a sí mismos [...] Los equipos que se organizan a sí mismos eligen la mejor manera de realizar su trabajo, en lugar de ser dirigidos por otros fuera del equipo.
Los Equipos Scrum se autoorganizan . Si el proceso de su Equipo Scrum está siendo rehén de las partes interesadas externas, entonces realmente no está haciendo Scrum, ni se está dando cuenta de todos los beneficios que Scrum tiene para ofrecer.
Tu primer paso es preguntarle al Equipo . Puede hacer esto combinando su reunión retrospectiva de Sprint en una (más sobre eso a continuación) y preguntando allí, o simplemente en una reunión improvisada.
Su pregunta da la impresión de que el Equipo no quiere combinar el Daily Scrum, pero ¿realmente les ha preguntado ? Su pregunta no especifica quién dio las 'razones para no dividirse', pero implica que no fue el equipo. Así que obtenga su opinión primero.
Después de eso, su tarea es convencer a las partes interesadas de que debe comenzar a hacer que el Equipo se organice por sí mismo. Si puedes convencerlos, genial. De lo contrario, asegúrese de que estén conscientes de que lo que están haciendo no es Scrum y conlleva costos (como una moral más baja del desarrollador, una productividad más baja, falta de innovación, etc.). Después de eso, solo asegúrese de que estos costos sean tan visibles como sea posible. posible a los interesados. Es su responsabilidad tomar decisiones. Es su responsabilidad asegurarse de que sientan el dolor de las malas decisiones, para que puedan darse cuenta de que se tomaron malas decisiones y actuar en consecuencia.
Si quiere mi opinión subjetiva (que no es tan relevante como las opiniones de su equipo, pero puede ser un buen punto de partida/conversación para que discutan el tema), entonces debe dividir los Scrums diarios pero combinar la retrospectiva del Sprint y (con asistencia opcional a la mitad del otro Equipo) el Sprint Review.
La Retrospectiva del Sprint es una oportunidad para que el Equipo Scrum se inspeccione a sí mismo y cree un plan para implementar mejoras durante el próximo Sprint.
Muchas mejoras están relacionadas con el proceso, más que con el proyecto, y como tales beneficiarían a ambos Equipos. Personalmente, considero que vale la pena la sobrecarga de escuchar mejoras no relacionadas con el proyecto.
La Revisión de Sprint es un poco más complicada. Sugiero que se combine debido a:
Durante la Revisión del Sprint, el Equipo Scrum y las partes interesadas colaboran sobre lo que se hizo en el Sprint.
Sin embargo, eso se complica por:
En función de eso y de cualquier cambio en el Product Backlog durante el Sprint, los asistentes colaboran en las próximas cosas que se podrían hacer para optimizar el valor.
La razón por la que creo que lo primero podría ser útil es porque creo que realizar la demostración como un equipo completo puede ayudar a unir bien al equipo. El Equipo del Proyecto B sería tratado como partes interesadas externas del Proyecto A (y viceversa). Serían capaces de ver el estado del producto (desde un punto de vista comercial, no técnico). También pueden unirse a la celebración de la finalización del Sprint (suponiendo que su Revisión del Sprint generalmente tenga un ambiente de celebración, que en mi opinión subjetiva debería).
La razón por la que desconfío de esto es porque la segunda parte de la Revisión del Sprint, la parte de planificación, no es realmente relevante para ambos equipos. Tal vez podría sugerir que los miembros del equipo se alejen durante la parte de planificación de la revisión del otro equipo.
Como siempre, pregunta al Equipo.