Cartera única. Múltiples equipos. ¿Cómo manejar el refinamiento de la cartera de pedidos?

Puedo ver por qué los desarrolladores se han negado, ya que el enfoque actual no suena constructivo.

Tampoco veo un problema con su solicitud, ya que básicamente piden refinar las historias con los miembros del equipo correctos o subconjuntos del grupo de desarrollo general.

Desde la perspectiva de BA, y habiendo desempeñado el papel yo mismo, también entiendo los desafíos de realizar múltiples reuniones de refinamiento.

Dos sugerencias para ofrecer++:

• Considere cuándo está realizando las sesiones de preparación de trabajos pendientes. El BA está retrocediendo porque la configuración actual probablemente no permita suficiente tiempo de refinamiento
• Trate el refinamiento como un proceso continuo; no debería ser necesario esperar hasta la hora de la reunión designada si hay algo que podría solucionarse antes (esto requiere trabajar en conjunto con el scrum master, por lo que se minimizan las interrupciones del sprint actual)

++ Las sugerencias son de este artículo, consulte las opciones 3 y 4. http://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/

En primer lugar, asumiré que esta migración es el único proyecto en el que cualquiera de los equipos tiene que trabajar actualmente.

Para mantener una mentalidad de Scrum, debe encontrar "epopeyas" que un solo equipo de Scrum pueda manejar en su totalidad y distribuir las epopeyas de manera uniforme entre los equipos hasta que se haya entregado el proyecto.

Si no hay absolutamente ninguna forma de que las historias de migración se puedan dividir en "Epics", entonces la única opción razonable es hacer que todos los equipos trabajen juntos desde el mismo tablero con el mismo horario. De lo contrario, ahogará el negocio en la administración de Sprint. Dejaría Scrum y trabajaría desde un tablero Kanban, con cada desarrollador eligiendo una tarea a la vez hasta que el proyecto esté terminado.

Por supuesto, es posible que su empresa no apruebe abandonar la metodología Scrum.

También creo que no ha asignado suficientes recursos de BA al proyecto. Un BA no puede soportar tres equipos Scrum al mismo tiempo, y el BA se convertirá en el factor limitante del proyecto. Las sesiones 1-2-1 con el BA pueden ser adecuadas para los desarrolladores, pero requerirán incluso más tiempo que la sesión de preparación única. No es necesario que todos los desarrolladores estén en la sesión de preparación, un par de representantes de cada equipo deberían ser suficientes, quienes pueden transmitir sus conocimientos al resto.

¿Quién posee las soluciones?

En Scrum, el equipo es dueño de la solución. Usted menciona en la pregunta que la OP está haciendo mucha evaluación técnica. Espero que el BA esté haciendo algo más mientras prepara los elementos atrasados. Si el equipo solo espera recibir soluciones listas para usar, entonces no debería sorprender que no vean valor en dedicar tiempo al refinamiento de la cartera de pedidos.

Entonces, lo primero para resolver el problema debe ser volver a poner la solución en manos del equipo de desarrollo: déjelos hacer el análisis técnico y planificar las migraciones. La OP debe centrarse en el valor comercial y la priorización de los esfuerzos.

Así que volvamos al refinamiento de la cartera de pedidos

Una vez que haces esto, toda la conversación se vuelve mucho más fácil. He trabajado antes en algunos esfuerzos de migración a la nube y, por lo general, son bastante complejos. Esos equipos probablemente necesitarán hablar entre ellos, mucho. Si son dueños de la solución, espero que hagan al menos parte del refinamiento de la cartera de pedidos juntos, y luego lleven parte de su trabajo a sus equipos individuales para refinar aún más. LeSS ofrece una posible solución en este caso ( https://less.works/less/framework/product-backlog-refinement.html )

En la actualidad, BA invita a todos los desarrolladores de todos los equipos a una única sesión de refinamiento para comenzar a discutir las historias en detalle. Los desarrolladores, con razón, se resistieron y 19 de los 21 desarrolladores simplemente abrieron sus computadoras portátiles y comenzaron a codificar nuevamente.

Si tiene un par de equipos de scrum de tamaño mediano, esto puede funcionar. Con equipos más grandes, esto se vuelve muy complicado de manejar, incluso para los scrum masters experimentados. ¿Supongo que estas reuniones duran para siempre también?

Con eso fuera del camino, puedo recomendar lo siguiente:

1. Deje que cada equipo decida quién asistirá a las reuniones de refinamiento de su equipo. Esto puede y debe cambiar de vez en cuando. De esta manera, tendrá menos asistentes y una reunión mucho más enfocada. Tenga cuidado con los equipos que nominan a un novato solo para llenar el espacio en blanco.
2. Asegúrese de que estas reuniones no tomen más del 10% del tiempo de los equipos durante el sprint
3. Sea creativo y haga que las reuniones con muchos asistentes sean divertidas (solo en los casos en que la mayoría de los desarrolladores deben asistir para brindar comentarios). Tal vez use The Big Wall . Esto se usa para la estimación, pero no veo por qué no se puede usar durante los refinamientos donde, por ejemplo, agrupa elementos dependientes en diferentes esquinas de la pared. Esto puede aumentar la participación. Recuerde, el objetivo principal de la reunión de refinamiento es reducir la dependencia entre equipos. Puede agrupar problemas poco claros/supergrandes en otra esquina para que puedan refinarse.

Supongo que la empresa está en proceso de transformación. Implementé parcialmente Scrum pero no delegué responsabilidades y conocimiento del producto a los equipos de Scrum. Lo que es más, esto obviamente no es posible de inmediato. Esto significa que tenemos desarrolladores que pueden manejar tareas técnicas pero necesitan BA para comprender los requisitos.

Lo que ya se dijo aquí BA es cuello de botella y se necesitan más BA. Si no podemos tener más BA, tal vez podamos hacer algo con sesiones 1 a 1. Son muy eficientes porque no perdemos el tiempo de varias personas, pero bloquean el intercambio de conocimientos. BA tiene sesiones 1 a 1 y esto significa que más adelante en la preparación solo esa persona sabe de qué se trata la historia. Recomendaría reemplazar los 1 a 1 con grupos pequeños que trabajan en temas relacionados para mejorar el intercambio de conocimientos. Si cada grupo tiene al menos una persona de cada equipo Scrum, debería mejorar la comprensión de los requisitos funcionales en los equipos. Si los equipos tienen una mejor comprensión y saben en qué están trabajando, deberían estar más comprometidos.