Contamos con un equipo de desarrollo que trabaja en múltiples "productos". Creamos una acumulación unificada de historias de usuarios y tratamos de manera efectiva los múltiples productos como diferentes áreas de características del mismo gran producto virtual. Idealmente , cada iteración se enfoca en historias de usuarios relacionadas, por lo que, en la práctica, eso no se vuelve demasiado loco, aunque a menudo hay elementos no relacionados de alta prioridad que hacen el corte.
Mi organización está creciendo hasta el punto en que ya no es sostenible que haya un solo equipo de scrum. Estoy pensando en cómo hacer que esto funcione para que las historias de usuario se dividan de una manera que sea a) funcional para los equipos yb) mantenga todo el trabajo enfocado en las prioridades generales de la organización.
Queremos mantener un trabajo atrasado general para los múltiples equipos; mantener a toda nuestra organización trabajando en prioridades unificadas es parte del objetivo de todo esto. (Y he visto el consejo de que este es el camino correcto a seguir ).
Una división obvia son las responsabilidades funcionales. Los productos A y B van al Equipo 1, mientras que los productos B y C van al Equipo 2. Supongo que así es como lo hace la mayoría de la gente. El problema con esto es que a veces los productos B y C pueden no ser una prioridad en absoluto . (Dado que trabajamos con un horario académico, ese suele ser el caso en ciertas épocas del año). En ese caso, terminamos con el Equipo 2 trabajando en elementos de más abajo en la cartera de pedidos que realmente no coinciden con las prioridades del organización en su conjunto, solo porque oye, eso es lo que dice su trabajo. Una posible solución es hacer que los equipos sean fluidos, con miembros del equipo cambiados del Equipo 2 al Equipo 1 cuando los productos del Equipo 1 son la prioridad actual.
Otro enfoque es hacer que la primera parte de la reunión de planificación del sprint involucre a ambos equipos. Habría una discusión grupal sobre qué historias de usuario van a dónde y cuánto puede comprometerse cada equipo. El problema claro con esto es que es difícil de escalar, pero he oído hablar de personas que lo hacen de todos modos . Una solución es que cada equipo envíe solo delegados a esta parte de la reunión de planificación. Estos delegados tendrían la responsabilidad de negociar una selección razonable de historias de usuarios para su equipo.
¿Qué enfoque es mejor y por qué?
En el modelo donde los equipos tienen diferentes áreas de responsabilidad pero la composición del equipo cambia cada ciclo, ¿ cuándo se hacen las reasignaciones y de quién debería ser esa responsabilidad?
En el modelo donde la reunión de planificación incluye a todos los miembros del equipo de todos los equipos, ¿cómo se hace que funcione de manera efectiva? ¡El consenso es muy difícil cuando hay más de unas pocas personas involucradas!
En el modelo donde los delegados asisten a la parte inicial de la reunión de planificación, ¿cuánta autoridad deben tener esos delegados y qué sucede cuando sus compromisos no coinciden con los del equipo?
¿Hay un refinamiento de estas ideas o un modelo diferente para el scrum de varios equipos que debería considerar?
Agregaría una opción adicional: permita que sus equipos de scrum seleccionen lo que quieran de la acumulación.
Les ha dado a los equipos de scrum un backlog general priorizado y saben lo que son capaces de entregar. Si permite a los equipos la libertad total de tomar las historias que quieran en sus sprints, entonces el proceso general debería ofrecer resultados óptimos. Esto solo se complica si los equipos de scrum realizan reuniones de planificación de sprint separadas simultáneamente...
Como propietario del producto, como siempre, solo necesita intervenir si los equipos de scrum no están tomando sus elementos de mayor prioridad en sus sprints. De lo contrario, debe establecer por qué en diálogo con los maestros de scrum y juntos acordar alguna acción.
En primer lugar, al hacer que su equipo sea funcional, está violando la regla ágil/SCRUM y ya describió por qué es malo.
A continuación, podría permitir que los equipos elijan EE. UU. de BL comunes, pero podría llevar a una situación en la que un solo equipo recogerá los primeros N EE. UU. de mayor prioridad. Es posible que al final del sprint no entreguen uno de los EE. UU. y te pierdas algo importante. Está bien si tienes otro sprint, pero ¿si es la fecha de lanzamiento?
Todos conocen la regla: no compare la velocidad de los equipos , pero significa que no debemos comparar las estimaciones de los equipos también, por lo que los resultados de la estimación recopilada son inútiles .
Mi propuesta será restringir a un solo equipo para que se ocupe de la parte superior de la cartera de pedidos o distribuir este riesgo manualmente. Le sugiero que no involucre a todos los equipos o representantes de equipos en la estimación, le darán estimaciones agregadas, podría priorizar el trabajo pendiente común y distribuirlo entre los equipos.
Ejemplo: si tiene 2 equipos de scrum y priorizó BL común, podría distribuirlo de la siguiente manera:
EE.UU._1 -> equipo_1
EE.UU._2 -> equipo_2
EE.UU._3 -> equipo_1
EE.UU._4 -> equipo_2
Cada equipo estimará su propio trabajo atrasado y las prioridades estarán junto con las generales.
mattdm
Pablo Harrap
el_probador_renuente