¿Cómo facilito una reunión de planificación eficaz con un equipo remoto?

TLDR: Hable con el equipo.

Tenga en cuenta los cuatro principios básicos del Manifiesto Ágil , particularmente el primero:

Individuos e interacciones sobre procesos y herramientas.

De los cuatro principios, el primero es el único que sufre directamente por tener un equipo repartido. Y según su pregunta, parece que está tratando de resolver este problema implementando un proceso. Si observa nuevamente el primer principio, debería ser evidente por qué esto es problemático.

Con ese pensamiento en mente, analicemos sus tres problemas:

La reunión de preparación de trabajos pendientes no funciona porque quieren diseñar la solución durante la reunión. Quieren estimar solo cuando entienden y han diseñado en gran medida la solución.

Lo mejor, creo, es primero desglosar esto en por qué esto es un problema. ¿Cuál es el propósito de su reunión de preparación de Backlog? Y, lo que es más importante, averigüe cuál es el propósito de su equipo de desarrollo , ya que puede ser diferente. ¿Es solo para seguir su procedimiento, según lo ordenado por... su procedimiento? Si es así, entonces los problemas se hacen evidentes. ¿Es algún otro propósito realmente útil, por ejemplo, como sugirió @Mark C. Wallace, para desarrollar planes, prioridades y/o arquitectura? Si es así, traiga sus inquietudes al Equipo de desarrollo sobre cómo no se está cumpliendo con este propósito y pídale sugerencias sobre cómo solucionarlo. Cualquier sugerencia creada internamente, o en colaboración, será aceptada mucho más fácilmente que una impuesta al Equipo desde arriba.

Quieren tomar 'descansos' para discutir cosas en su idioma nativo

Además de obtener un nuevo equipo que hable inglés, en realidad solo hay dos soluciones para esto. O el Equipo mejora su inglés (podría, por ejemplo, enviarlos a una clase de algún tipo, idealmente con dinero de la Compañía). O podrías mejorar tu (insertar idioma extranjero aquí). O ambos.

No quieren crear historias de usuario ellos mismos, lo cual está bien, pero tampoco están de acuerdo con la forma en que el PO divide las historias.

Como siempre, colabora . Descubra por qué al equipo no le gusta cómo el propietario del producto divide las historias. Tal vez estén equivocados. Tal vez el PO está equivocado. Tal vez ambos estén equivocados. La única forma de averiguarlo es una discusión abierta, sin prejuicios preexistentes. Un objetivo que probablemente debería abordar es obtener una comprensión compartida de cómo se deben dividir las historias. Un enfoque es simplemente reducirlos lo más pequeños posible sin dejar de ser capaces de proporcionar valor comercial. Otro enfoque es seguir el mnemotécnico INVEST .

Aquí hay algunos problemas como los veo:

• Barrera del lenguaje natural
• Desacuerdo sobre la división adecuada del trabajo
• Desacuerdo o ambigüedad sobre el resultado deseado de la "preparación de retrasos"

Parece que usted, como Scrum Master, ahora tiene algunas responsabilidades:

• Guíe al equipo hacia una comprensión compartida más detallada de cómo se ve el corte deseable
• Llegar al fondo de lo que debería ser el resultado de la sesión de preparación. Si el equipo se siente incapaz de estimar sin un plan detallado, ¿por qué? ¿Qué pasaría si no requirieras un presupuesto en ese momento?
• El equipo debe hacer más explícitas sus expectativas sobre el lenguaje. Tal vez necesite un acuerdo de trabajo sobre cuándo usar qué idiomas.

Sospecho que cualquier trabajo que involucre historias que usted personalmente haga solo con el PO no conducirá en la dirección correcta; el equipo necesita encontrar el equilibrio correcto de PO y equipo de desarrollo.

Parece que te estás alejando de ágil. Debido a que el equipo no está siguiendo sus expectativas de proceso, usted propone reducir su rol al de ratificador. Eso socavará su compromiso.

Yo iría por el otro lado. Pregunte al equipo cómo resolver el problema. Si no arreglamos el trabajo atrasado, siempre estaremos mirando árboles, no bosques. Si diseñamos en las sesiones de backlog ( en lugar de la actividad prevista de la sesión de backlog), nos ahogaremos en deuda técnica. Con base en eso, ¿cómo podemos, como equipo, cambiar nuestro comportamiento para resolver el problema?

Algunos dicen que Agile no funciona sin que el equipo esté en un solo lugar, yo diría que para que Agile funcione debe haber un buen proceso establecido. Tenga en cuenta que Agile es exclusivo de la mayoría de los equipos, ya que tienen diferentes antecedentes detrás de ellos.

La mayoría de los equipos terminan hibridando los enfoques, haciendo scrumbans, o parte del flujo de trabajo para obtener requisitos/redacción de historias se realiza en cascada iterativa. Dado que scrum / o ágil en su conjunto no es una bala de plata (especialmente dado que tendrá plazos en algún momento).

También obtuvimos un equipo remoto y se nos ocurrió el siguiente enfoque híbrido, donde:

1. BA / PO redacta las historias para el análisis preliminar, ya que se comunican con los clientes

2. Más tarde, se sientan y discuten (obtuvimos una diferencia de 9 a 13 horas entre los miembros del equipo) el plan para la próxima función con el equipo de desarrollo. Siempre hay una moderación, cuando se trata de reuniones, para que nadie quede fuera de alcance. Esa redacción temprana ahorra tiempo, ya que no se escribe toda la historia, por lo que si los desarrolladores torpedearon la idea, no se perdió el tiempo.

3. La descomposición se realiza junto con los desarrolladores, porque los desarrolladores realizan los bits descompuestos. Así que la última palabra es de ellos (dado que están dispuestos a colaborar). El trabajo de BA / PO es asegurarse de que el problema se presente lo suficientemente claro

4. Entonces, después de que todo el equipo aprueba y estima los fragmentos descompuestos (no practicamos los puntos de la historia), movemos las historias a Listo para la implementación y comenzamos a trabajar en ellas. No usamos sprints, pero tenemos un tablero Kanban, por lo que aquí no se necesita planificación de sprints, así como iteraciones.

Quizás esto te ayude un poco :) Lang. La barrera es irresoluble, hasta que sus desarrolladores lleguen a algún campamento de inglés para hablar y comprender con fluidez, pero para el 90% de las discusiones, el inglés simple siempre es suficiente para obtener la noción de la historia y agregar notas sobre la implementación.

En mi opinión, es bastante complicado hacer que Agile funcione a menos que haya un equipo. Un equipo trabajando en una habitación en una zona horaria. No puede controlar la zona horaria, pero la tecnología puede ayudar a crear una habitación virtual.

Definitivamente debería intentar asegurarse de tener una cámara web en cada oficina que esté encendida durante el horario laboral y ver si pueden trabajar al menos de 4 a 6 horas juntos. Si esto no es posible, abandone Scrum y vaya a la vieja escuela.

PO tendrá que documentar los requisitos en detalle. Intente usar una combinación de casos de uso y estructuras alámbricas. El Scrum Master actual revisará esto y se asegurará de que sea lo suficientemente detallado antes de enviarlo al equipo extranjero.

Todavía puede asegurarse de que la PO esté disponible a corto plazo si el equipo de desarrollo necesita una aclaración. Incluso puede dividir el proyecto en partes y pedirle al equipo de desarrollo que publique cosas mensualmente como máximo.

Esta respuesta puede ser controvertida, pero nunca he visto equipos que no puedan trabajar juntos, al menos a través de una cámara web, tener éxito con Agile. Los equipos ágiles son como unidades del ejército o equipos de fútbol. No tienes un equipo de fútbol o una unidad del ejército si la mitad de ellos están en alta mar.