Su navegador no soporta JavaScript. Distributed Scrum - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS

Distribuido Scrum

Los equipos distribuidos casi siempre entregan el producto más lentamente, con más errores y con costes más elevados. Sin embargo, la globalización hace que trabajar en distintos lugares sea una realidad, por lo que en este curso online esbozamos una serie de técnicas que minimizarán los costes.

Tiempo estimado para este curso: 65 minutos
Audiencia: Avanzado
Requisitos previos sugeridos: Scrum a escala, RetrospectivaScrum Master

Una vez finalizado:

  • Comprender los costes de distribución
  • Conozca las señales de advertencia de disfunciones causadas por la distribución
  • Aprenda varias pautas para facilitar el éxito de la distribución Scrum
  • Cualificarse para el PMI PDUs. Véase PREGUNTAS FRECUENTES para más detalles
Visión general del Scrum distribuido:
Los equipos Scrum distribuidos son intrínsecamente problemáticos. Tanto si se trata de un equipo distribuido geográficamente como de equipos separados que utilizan un único backlog, no es fácil. De hecho, nuestra primera recomendación es no hacerlo, ya que los costes de productividad casi siempre superan al ahorro.

Por desgracia, la economía globalizada no está alineada con las mejores prácticas Scrum. Sabemos que las organizaciones van a repartir sus equipos por diversos lugares, independientemente de lo que digan los estudios.

La pregunta es: ¿pueden los equipos distribuidos igualar el rendimiento de los equipos ubicados en un mismo lugar? La respuesta es sí, pero es complicado. En este curso compartimos los patrones que se encuentran entre las implementaciones exitosas.

Ver y descargar las diapositivas

[slideshow_deploy id='6140']

Descargar diapositivas Scrum distribuidas

Tres formas de distribuir Scrum
Existen tres configuraciones de Equipo Scrum Distribuido. Los Equipos totalmente integrados pueden lograr los mejores resultados, pero cualquiera de las tres configuraciones puede ser eficaz si se implanta y mantiene con rigor. La variable común a la hora de decidir qué configuración funcionará mejor para su organización es la comunicación. ¿Cuánto necesitan coordinarse los miembros del equipo divididos geográficamente para crear un producto entregable cada Sprint?

Equipo Scrum aislado: Como cualquier equipo Scrum, un equipo aislado debe ser interfuncional, autoorganizado y autogestionado. También debe tener todas las habilidades necesarias para entregar el producto al final de cada Sprint. Sin embargo, están trabajando a partir de su propio Backlog de Producto y no tienen ningún ritual común, como las reuniones de Planificación de Sprint y Retrospectivas con la organización más grande. Ad Words de Google funciona de esta manera. Cada equipo sirve a un mercado específico de manera muy eficaz, pero no tienen una relación formal de colaboración entre sí.

Para los fines de Google, esta configuración funciona bien (generan 90% de los ingresos de Google) y dependiendo de las necesidades de su empresa, puede funcionar bien para usted también. Sin embargo, hay algunos inconvenientes importantes. Aislar a los equipos de esta manera puede agravar los problemas de comunicación intercultural. Por lo general, los equipos subcontratados ni siquiera utilizan Scrum, y su productividad y ritmo pueden ser más parecidos a los típicos proyectos en cascada. Esto dificulta enormemente la comunicación y la transparencia con la organización de origen y puede hacer que el argumento comercial a favor de la externalización sea un poco dudoso. Esta configuración sólo funciona cuando hay poca necesidad de que los equipos Scrum colaboren.

Equipos Scrum solapados con Scrum de Scrum compartidos puede ayudar a minimizar los problemas interculturales y de comunicación vinculando a los equipos remotos a través de un Scrum de Scrum, lo que permite a los equipos estar en múltiples ubicaciones pero trabajar en un proyecto común a través del Product Owner Jefe que coordina los esfuerzos entre todos los Scrum Masters. Estos equipos también comparten un Product Backlog común para coordinar su trabajo. Jeff explica muy bien el Scrum de los Scrum en el vídeo.

Por ejemplo, si los Equipos estuvieran diseñando una suite de software que combina audio, vídeo y edición de texto, quizás un Equipo Scrum se encargaría de desarrollar la interfaz de vídeo mientras que otro Equipo sería responsable de diseñar el editor de texto. Cada equipo seguiría siendo capaz de entregar un conjunto de características al final del Sprint, pero como el Product Owner está trabajando a partir de un Product Backlog y los Scrum Masters de cada equipo se coordinan entre sí tanto como sea necesario, ningún equipo está creando impedimentos para los demás y el código se integra como el equipo espera.

No existe una fórmula para el Scrum de los Scrum. Quizá los diseñadores gráficos deban reunirse mensualmente, los probadores semanalmente y el Product Owner hable a diario con el Scrum Masters. De lo que se trata es de que los equipos alcancen un cierto nivel de saturación de comunicación que les permita coordinar eficazmente su trabajo.

Scrum integrados trabajan a partir del mismo Sprint y Product Backlog. Este puede ser el modelo de distribución más eficiente, pero también el más difícil, cuando los miembros del equipo se encuentran en varios lugares. La mejor práctica es tener aproximadamente la mitad del equipo en un lugar y la otra mitad en otro para que cada lugar tenga masa crítica. Cada parte del equipo debe incluir a miembros interfuncionales para mitigar el riesgo de que el progreso se detenga porque alguien con una habilidad crítica se encuentre en otra zona horaria o geográfica. Por último, es importante permitir que los equipos distribuidos se formen y gelifiquen como equipos ubicados en el mismo lugar. Reunir a las dos mitades del equipo durante los primeros Sprints puede facilitar este proceso.

Scrum Inc. ha utilizado esta configuración integrada para ofrecer casi los mismos resultados de rendimiento que los equipos situados en el mismo lugar.

es_ARSpanish
Acciones