---

¿Cómo escalar Scrum para proyectos distribuidos y grandes? ¡La respuesta puede sorprenderte!

Scrum, tal como lo hemos descrito hasta ahora, funciona mejor con un único Scrum Team en una sola ubicación. Sin embargo, en la realidad, un único Scrum Team a menudo no puede ejecutar un proyecto completo, o sus integrantes deben distribuirse entre varias ubicaciones.

Cuando un equipo no puede satisfacer las necesidades del producto, la organización puede plantearse incorporar más equipos. La distribución geográfica por sí sola no exige más equipos, y añadir personas puede aumentar los costes de coordinación. En muchos casos también hemos observado equipos distribuidos entre ubicaciones o continentes muy distantes.

Hay numerosas razones para que una organización distribuya sus equipos entre distintas ubicaciones:

• Razones técnicas: Algunos conocimientos necesarios para desarrollar componentes del software no están disponibles localmente en la sede central,
• Razones de especialización: Algunas capacidades relacionadas con distintas actividades de ingeniería de software no están disponibles localmente. Por ejemplo, la automatización de pruebas, el diseño de interfaces de usuario o la integración del software propio con el de otros proveedores pueden requerir especialistas externos a la sede central,
• Razones de tamaño: El proyecto incorpora más personas para entregarlo a los clientes dentro del plazo previsto. En este caso, la organización necesitará más integrantes de los que razonablemente caben en un único Scrum Team. Esto puede requerir varios Scrum Teams cohesionados en lugar de ampliar indefinidamente un solo equipo,
• Razones empresariales: Utilizar recursos humanos de ubicaciones con costes menores o mantener la continuidad del trabajo mediante ingenieros en distintas zonas horarias puede constituir un buen caso de negocio.

Como la comunicación es una parte integral de Scrum, todos los integrantes del Scrum Team deben esforzarse por superar los desafíos de trabajar en un proyecto distribuido. Además, todos deben tener acceso a herramientas de comunicación, incluidas audioconferencias, videoconferencias y herramientas para compartir pantalla.

Las herramientas habituales de gestión de proyectos ayudan a mantener una comunicación saludable y continua. Pueden incluir Product Backlogs, Sprint Backlogs, listas de incidencias y herramientas para compartir conocimientos y noticias, entre otras.

Organización del proyecto: varios equipos

La forma más sencilla de ampliar Scrum en un proyecto de mayor escala es aumentar el número de equipos en la misma ubicación.

Si varios equipos deben colaborar para ejecutar un proyecto, lo mejor es aumentar su número progresivamente.

¿Qué significa esto para ti?

Varios equipos en una sola ubicación

En la mayoría de las organizaciones, el crecimiento progresivo es más manejable que lanzar diez equipos nuevos de golpe. La mejor práctica es empezar con un único Scrum Team. Después de varios Sprints satisfactorios, pueden incorporarse uno o dos equipos adicionales. Una vez que compruebes que estos equipos (consulta más información sobre Varios Scrum Teams) trabajan bien juntos, puedes seguir incorporando Scrum Teams a tu organización de proyecto distribuida.

Aumentar el número de equipos

Hay dos formas habituales de crear Scrum Teams nuevos:

• Dividir un Scrum Team existente en varios equipos y añadir integrantes donde y cuando sea necesario,
• Crear un Scrum Team con ingenieros completamente nuevos que hasta entonces no hayan participado en el proyecto.

Dividir un Scrum Team existente tiene la ventaja de aprovechar a quienes ya tienen conocimientos y experiencia en el proyecto en curso.

Por ello, estos equipos nuevos suelen ser productivos, al menos en cierta medida, desde su formación. El principal inconveniente es que el Scrum Team existente y plenamente operativo se ha dividido ahora en dos equipos. Esto puede causar problemas de motivación entre sus integrantes. Especialmente si los cambios se realizan sin anuncio ni justificación previos de la alta dirección, y sin que los integrantes estén preparados mental y técnicamente.

Al añadir equipos completamente nuevos, los existentes pueden conservar su estructura y continuar sus Sprints. Aun así, hay que prestar atención a la coordinación, la incorporación y la integración con los equipos nuevos. Además, desarrollar los conocimientos y el impulso necesarios para poner en marcha equipos totalmente nuevos llevará más tiempo.

Independientemente de cómo incorpores Scrum Teams a tu organización, recuerda estos principios:

• Empieza con pocos Scrum Teams,
• Aumenta el número de equipos gradualmente,
• Garantiza la continuidad del trabajo y una entrega fluida de software y valor de negocio durante los periodos de cambio y crecimiento,
• Si hay problemas importantes que dificultan la productividad y la continuidad del trabajo, resuélvelos antes de ampliar la organización con más Scrum Teams.

Organización del proyecto: equipos distribuidos

La mayor complejidad de trabajar con varios equipos aparece cuando los Scrum Teams nuevos deben distribuirse entre distintas ubicaciones. Las barreras de comunicación, las dificultades para coordinar el trabajo y los malentendidos sobre las normas comunes del proyecto son solo algunos ejemplos de esa complejidad.

Varios equipos en varias ubicaciones

No abordar estos desafíos tiene consecuencias graves.

Las empresas desperdician miles de millones de dólares de su presupuesto de TI por falta de competencias en Liderazgo organizacional y Conocimientos de Scrum escalado.

Estas cuatro recomendaciones fundamentales te ayudarán a afrontar esos desafíos:

• Asegúrate de que los nuevos integrantes del Scrum Team se formen en Scrum como Scaled Scrum Expert,
• Asegúrate de que los nuevos integrantes conozcan bien el proyecto y comprendan para qué trabajan, tanto desde el punto de vista técnico como del valor de negocio profesional, para que puedan tomar decisiones que aumenten el valor de su contribución,
• Asegúrate de establecer normas del proyecto. Al igual que un único Scrum Team tiene normas de comunicación, planificación y ejecución, una organización con varios equipos debe tener normas de nivel superior para que puedan comunicarse, planificar, operar, resolver problemas y entregar juntos valor al cliente y al negocio.
• Asegúrate de que los integrantes nuevos trabajen, al menos temporalmente, junto a los miembros experimentados del proyecto. Esto puede requerir visitas a otras sedes y formación en el puesto de trabajo. Es perfectamente aceptable e incluso deseable. Así se transfieren los conocimientos con fluidez y se establece un diálogo personal y bidireccional entre personas de distintos equipos y ubicaciones.

Equipos virtuales

Otra modalidad de Scrum Team distribuido tiene a sus integrantes repartidos entre varias ubicaciones. Se denomina «equipo virtual».

El principal desafío es garantizar una comunicación fluida entre sus integrantes. Los Scrum Teams deben seguir celebrando todos los eventos Scrum prescritos para coordinar su trabajo, pero ahora sin estar todos presentes en la misma sala.

Equipos virtuales

Los integrantes de una misma ubicación pueden trabajar juntos en una sala compartida cuando resulte útil, asegurando que quienes trabajan a distancia participen plenamente. Aun así, deben depender más de las herramientas de colaboración y comunicación. Pueden participar en los eventos Scrum desde una misma sala de reuniones y conectarse por videoconferencia con la otra mitad del equipo virtual.

Equipo de Product Owners de Scrum

Como hemos explicado repetidamente en este material, la comunicación regular entre el Product Owner y el Scrum Team es fundamental para entregar un proyecto con éxito.

Los Scrum Teams de distintas ubicaciones necesitan acceso eficaz a las decisiones sobre el producto. Para un único producto, los equipos comparten un Product Owner, un Product Goal y un Product Backlog. El Product Owner puede delegar tareas de apoyo manteniendo su responsabilidad; no es obligatorio añadir un Product Owner responsable diferente para cada equipo.

Esta edición describe un «Scrum Product Owner Team» y un «Chief Scrum Product Owner» como patrón de colaboración organizacional. El Product Owner puede trabajar con delegados u otros especialistas de producto, pero estos títulos no constituyen responsabilidades adicionales de Scrum ni sustituyen al único Product Owner responsable del producto.

El Product Owner responsable, con el apoyo de esta colaboración, se centra en garantizar que:

• Se desarrolle el producto adecuado para satisfacer las necesidades del cliente,
• El Product Owner y sus delegados colaboren eficazmente, ayudando a los equipos a crear valor empresarial y técnico para sus clientes.

El Product Owner sigue siendo responsable de la gestión eficaz del Product Backlog. El trabajo de apoyo sobre requisitos puede beneficiarse de otras competencias y de las aportaciones de las partes interesadas. Entre ellas pueden estar los representantes del caso de negocio, las partes interesadas pertinentes y los arquitectos empresariales y tecnológicos.

Para los equipos que trabajan en el mismo producto, el Product Owner y quienes lo apoyan trabajan con un único Product Backlog ordenado y hacia un Product Goal compartido. Cada Scrum Team entrega algunas de estas historias de usuario. Aun así, habrá historias concretas que requieran la atención y los entregables de varios Scrum Teams.

Equipos de componentes frente a equipos de funcionalidades

Al distribuir el trabajo entre equipos, podemos responsabilizarlos de componentes o funcionalidades específicos del software. Por eso los llamamos «equipos de componentes» o «equipos de funcionalidades».

Equipos de componentes

En los equipos de componentes, cada equipo solo se ocupa de implementar componentes específicos del sistema completo. Para terminar una historia de usuario, suele ser necesario dividirla en partes menores que puedan implementarse dentro de un componente. Las dependencias entre los componentes de estos equipos hacen imprescindible la integración continua para entregar con éxito.

Equipo de Product Owners de Scrum

Estas dependencias pueden dificultar la entrega de una funcionalidad completa dentro de un Sprint. Deben abordarse mediante colaboración e integración: los equipos que trabajan en un producto siguen necesitando un incremento integrado y utilizable que cumpla su Definition of Done compartida.

Esto aumenta el tamaño de los lotes y los plazos de entrega del trabajo en curso todavía sin integrar. Esto no parece tan conveniente, porque los Scrum Teams deben buscar incrementos de software entregables en lotes menores y con plazos más cortos.

La ventaja de los equipos de componentes es que facilitan concentrarse en los detalles de arquitectura y diseño de componentes concretos y desarrollar conocimientos especializados sobre ellos. Esto puede resultar muy beneficioso para componentes que requieren investigación e innovación.

Por otra parte, sus integrantes solo se especializan en componentes individuales del sistema completo. Pueden perder la visión general y el sentido de la necesidad empresarial de las funcionalidades.

Recuerda que nuestros clientes no nos pagan por entregar componentes, sino funcionalidades con las que desarrollar su actividad. Sin esa atención constante a las funcionalidades, la optimización general y la integración del software pueden requerir más tiempo. Como las decisiones de estos equipos tienden a optimizar componentes individuales, pueden crear cuellos de botella invisibles para el éxito y rendimiento de la solución completa.

Equipos de componentes

Equipos de funcionalidades

Los equipos de funcionalidades son plenamente responsables de implementar las historias de usuario tal como se especifican en el Product Backlog. Ya no es necesario dividir a los equipos por componentes. Cada equipo de funcionalidades entrega una funcionalidad completamente operativa y su valor de negocio asociado.

Equipos de funcionalidades

Sus integrantes tienen competencias multifuncionales y actúan con la mayor autonomía posible para entregar con rapidez. Su ventaja es que el equipo conserva el conocimiento del sistema, lo que facilita integrar sus funcionalidades con el resto.

Sin embargo, puede resultar más difícil desarrollar conocimientos suficientes sobre los componentes. Además, crear un equipo de funcionalidades autónomo que entregue rápida e independientemente lleva tiempo, porque formar un equipo interdisciplinario no es sencillo. Aun así, estos equipos de alto rendimiento sacan el trabajo adelante en la mayoría de las organizaciones, probablemente también en la tuya.

¿Cómo elegir entre equipos de componentes y de funcionalidades?

En la práctica, la mayoría de las grandes organizaciones utilizan tanto equipos especializados en componentes como equipos de funcionalidades.

Equipos de componentes y de funcionalidades

El equipo C del gráfico es un equipo de componentes. Proporciona servicios de infraestructura planificados y bajo demanda a los demás equipos, que funcionan como equipos de funcionalidades. El equipo C no implementa directamente historias de usuario completas. Entrega los requisitos de las historias de usuario asumidas por los equipos de funcionalidades.

Así se reduce al mínimo el número de personas cualificadas con conocimientos sobre esos componentes que necesitan los equipos de funcionalidades.

El Scrum Master en un proyecto distribuido

En un proyecto distribuido, el papel del Scrum Master es aún más esencial. En estas configuraciones:

• Se requiere un esfuerzo adicional para alinear a los equipos con los valores de Scrum,
• Establecer las normas de cada equipo y del proyecto que afectan a varios equipos lleva más tiempo,
• Por último, habrá numerosos impedimentos debido al aumento de dependencias entre los equipos y sus entregables.

El Scrum Master debe ser accesible y eficaz al apoyar al equipo. Compartir una ubicación física puede ayudar, pero no es un requisito de Scrum y el apoyo remoto es posible. La organización del trabajo distribuido debe permitir al Scrum Master:

• Ayudar a conseguir que se eliminen los impedimentos al avance del equipo,
• Ayudar al equipo a establecer acuerdos de trabajo eficaces, y
• Ayudarle a mejorar su uso de Scrum.

Algunas organizaciones utilizan un Scrum Master principal para apoyar el acompañamiento y la coordinación entre equipos. Es un patrón organizacional opcional, no una jerarquía obligatoria ni un sustituto de las responsabilidades de cada Scrum Team.

Cada Scrum Team de la organización mantiene la responsabilidad del Scrum Master y necesita apoyo eficaz para sus propios eventos, autogestión y mejora.