¿Cuáles son algunos buenos consejos para practicar scrum con equipos de desarrollo remoto (10,5 horas de diferencia horaria)?

Answer 1

Todas las respuestas aquí son muy buenas y han cubierto casi todos los puntos relevantes aquí, pero quería agregar solo algunos puntos.

Debería estar en una plataforma de video chat con capacidades para compartir la pantalla. Supongamos que utiliza el zoom para que pueda compartir los tableros del equipo scrum de, por ejemplo, herramientas ADLM como versionOne. Por lo tanto, puede rotar el tiempo, pero al comienzo del horario de trabajo en cualquiera de los dos lados, Ubicación 1 y Ubicación 2 es cuando debe hacer que el standup diario se coordine a través del video para que los miembros del sitio y fuera del sitio puedan participar juntos en el standup diario a la vez.

Porque de esta manera, cuando todos los jefes se comunican entre sí al mismo tiempo y en la misma plataforma, definitivamente se borrarán muchas fallas de comunicación provocadas por la diferencia entre la distancia y las zonas horarias, y la productividad y la coordinación definitivamente mejorar.

A continuación, intente y vea si las tareas que se pueden paralelizar son en realidad, lo que se distribuye entre los miembros en las 2 ubicaciones separadas por este intervalo de tiempo. Entiendo que esto no es posible todo el tiempo, pero lo he hecho y he visto resultados muy ventajosos.

También es beneficioso coordinar las actividades de administración de etiquetas de compilación y lanzamiento. Por supuesto, esto se vuelve más útil cuando el CI / CD NO está en su lugar, como he visto en varios lugares donde hay un nivel de automatización pero no es un CI / CD y el control se basa en el monitoreo. Por eso, si surgen problemas en la compilación en el EOD de la ubicación 1, la resolución del problema puede continuar con la gente de la ubicación 2. Por lo tanto, explicar el tercer consejo aquí es distribuir esas tareas también entre las personas de las dos ubicaciones.

Answer 2

He vivido en sus zapatos, dirigiendo equipos de ingeniería tanto a corto como a otro. Near-shoring era bastante similar a un proyecto de ingeniería local que no es necesario para aprovechar las comunicaciones alternativas en algunos casos, por ejemplo, una idea de sala de chat persistente como Slack. He usado esto con un diferencial de tiempo de hasta 2 horas y significa un poco de retraso cuando pregunto algo cuando entro pero necesito esperar a que el Valley se conecte. Esto no es tan malo y simplemente lo solucionamos con nuestros horarios.

Mi experiencia fue en la India y ahí tienes un desafío adicional para los de los Estados Unidos, porque nunca estás realmente en el proyecto al mismo tiempo. Encontré a mis colegas dispuestos a trabajar tarde mientras trabajaba temprano para que pudiéramos hablar por teléfono, pero además el uso de algo como Slack se vuelve más importante. De hecho, en ese proyecto no teníamos Slack o una herramienta similar y encontramos que nos comunicamos a través de un gerente central que ayudaría a recopilar la pregunta o inquietud. Tener una buena persona puntual lo que es muy importante.

El otro efecto de esta diferencia de tiempo fue la lentitud de la comunicación, y eso significaba que no podíamos realizar mis sprints preferidos de 2 semanas y en su lugar optamos por un sprint de 4 semanas. La “respuesta al día siguiente” simplemente significaba que necesitábamos sprints más largos. Un equipo realmente bueno podría hacerlo mejor, y estos muchachos estaban llegando al punto en que empezamos a pensar en ello, pero simplemente no con la experiencia. Además, este sprint más largo tendía a parecerse un poco a una pequeña cascada de 4 semanas: hubo una tendencia a codificar durante 3 semanas y realizar pruebas en la última semana, lo que funcionó pero no fue ideal en mi libro. Nuevamente, estaban progresando para mejorar esto (fue un poco de resaca por un enfoque de comando y control en el pasado).

Usted, además de las notas anteriores, probablemente tendrá que trabajar algunas horas extrañas para ejecutar un proyecto de este tipo, pero le puedo decir que esto puede funcionar y funciona.

Answer 3

1.Crear un equipo trabajando en la introducción de Scrum.

El equipo debe estar formado por personas que representan a los líderes de proyecto actuales (gerentes de proyecto), gerentes de departamento (opcionalmente miembros de la junta directiva) y empleados.

Tareas básicas del equipo:

• El análisis de la situación actual y los cambios en la organización que deben ocurrir para que se presente Scrum.
• Selección de equipos y proyectos.
• Interacciones de los proyectos y procesos de Scrum (proyectos) sin Scrum. Desde que introducimos la metodología con pasos pequeños, siempre hay conflictos con otros proyectos que se realizan en la empresa. Debemos tratar de identificarlos y prevenirlos antes de que aparezcan.
• Usar la metodología Scrum también para el proyecto de introducción. Esté abierto a todos los comentarios, aprenda de sus errores y realice mejoras en otros sprints.

2.La elección de equipos y proyectos.

Recomiendo la introducción de Scrum paso a paso, comenzando con 1-2 equipos, y no en toda la compañía a la vez. Por supuesto, incluso hay grandes empresas, que introdujeron Scrum a la vez en toda la organización, por ejemplo, Salesforce. Sin embargo, cuando actuamos sin el apoyo de un sujeto externo, es mejor un enfoque iterativo. Si usted es una microempresa, entonces puede introducir la metodología en toda la empresa.

• Busca personas entre tus empleados que ya hayan trabajado en Scrum. Si tienen buenas experiencias, únase a los primeros equipos de Scrum.
• Elija Scrum Masters: deben ser personas de mente abierta, con ganas de aprender. Si no tienen experiencia, envíelos a capacitación externa, preparándose para el rol de Scrum Master y persuade a asistir a las reuniones de los grupos de discusión Agile.
• Elegir propietarios de productos: hacerlos coincidir con la competencia del producto, que se está realizando.
• Nunca unirte a roles de Product Owner y Scrum Master.
• Elegir proyectos, que no duren más de medio año y, preferiblemente, estos que son, en cierta medida, independientes de los procesos sin Scrum en la empresa.
• Agregar un nuevo proyecto cada 2 meses.

3. ambiente de trabajo

• Haga que sus equipos trabajen en una habitación y con el acceso al tablero.
• Los miembros del equipo deben trabajar solo en un proyecto.
• Supervise que no hubo desviaciones de las reglas de Scrum. Sentirás la tentación (muy rápidamente) de ajustar la metodología a tus necesidades, pero no lo hagas al principio.

4.Educación / Comunicación.

Antes de la introducción, es muy importante que todos sepan qué es Scrum y por qué queremos presentarlo. Yo sugiero:

• Envío de información (al comienzo) a todos los empleados, pero no archivos PDF con descripción de la metodología. Mis sugerencias:

http://scrumtrainingseries.com

• Organizar una reunión de apertura, durante la cual explicaremos nuestros objetivos de introducción y un proceso gracias al cual queremos lograrlos.
• Organizar una reunión (una vez al mes), durante la cual conoceremos una situación de introducción.

Más en: http://www.startupfreak.net

Answer 4

Mi equipo en Hubstaff practica scrum y somos 100% remotos. Aquí hay una publicación en el blog que publicamos recientemente titulada Simplificar la gestión de proyectos con Scrum en menos de 10 minutos. Esperamos que encuentre esto útil para su propio equipo.

Descargo de responsabilidad: soy el co-fundador de Hubstaff

Answer 5

Pocas pautas para equipos distribuidos:

1. Mantener los equipos limitados a una ubicación (todos los miembros de un equipo en una ubicación: SM, PO y devTeam)

2. Use la cartera de productos electrónicos, la cartera de sprint y la placa scrum

3. Para minimizar las dependencias entre los equipos, tallar cuidadosamente las historias

4. Se debe planificar Scrum of Scrum (o cualquier interacción entre equipos) para minimizar el dolor inducido por las diferencias de zona horaria.

5. Si es posible, trate de obtener horas de trabajo superpuestas

6. Si es posible, prever los viajes para los miembros del equipo (no solo para los gerentes y las OP)

7. Mantenga abiertos múltiples canales de comunicación (correo electrónico, mensajería, videollamada, etc.)

8. Si es posible, proporcione un número de alias en el extranjero al equipo

Autor: El manifiesto ágil en inglés.

Blog: Agile, Scrum, Kanban, Solution Architecture

Twitter: @tjain

Answer 6

El mejor consejo que podría darte es evitarlo.
¿Como lidiar con?

Asegúrate de que el equipo remoto sea un Equipo COMPLETO de Scrum. Una de las mayores fortalezas de Scrum es la ubicación conjunta y las líneas de comunicación cortas. Asegúrese de que el equipo pueda trabajar en equipo sin depender de alguien externo (a 10.5 horas de distancia).

También traiga a los equipos al inicio del desarrollo y tráigalos de vez en cuando para mantenerlos conectados al otro lado.

También ayuda a poner una comunicación de dúplex completo preferentemente con un enlace de video. Y para mantener una línea de comunicación abierta en todo momento.

Answer 7

Scrum es mejor cuando todos los miembros del equipo están en la misma sala.

Si realmente necesita dividir al equipo en diferentes ubicaciones, convierta a cada equipo en su propio equipo Scrum.

Si, por alguna razón, realmente quieres dividir a un solo equipo de Scrum en múltiples ubicaciones, entonces prepárate para tener mucho trabajo adicional que hacer. Al menos debes comenzar las primeras semanas con todos en la misma habitación. Cuando las cosas se mueven suavemente, puede dividirse en diferentes zonas horarias de nuevo.

Recuerde lo que significa Scrum: un grupo de personas con talento se reúnen y actúan, mientras que Scrum Master los protege de todo lo que dificulta su desempeño.

Answer 8

Siga el manual y los consejos de sus socios. es simple