Skip to main content

1.7. Implementación de Scrum en grandes organizaciones.

Scrum está diseñado para funcionar en proyectos de cualquier tamaño, por lo que, haciendo algunos ajustes a lo explicado en las anteriores secciones, puede ser utilizado en grandes proyectos.

A continuación, se encuentra el detalle de cada uno de los elementos que deberían considerarse como parte de la adopción de Scrum en la organización.

1.7.1. Ceremonias Scrum en grandes proyectos

Las ceremonias sugeridas para grandes proyectos de Scrum son:

Scrum de Scrums

El Scrum de Scrums es el evento enfocado en la coordinación de los Sprints para múltiples equipos dentro del mismo proyecto.

  • Este evento por lo general tiene una duración de 15 minutos.
  • En algunos proyectos donde la necesidad de comunicación entre equipos es vital (ej: cuando existen dependencias), se realiza diariamente.
  • Se debe realizar por lo menos 1 vez por Sprint.
  • Es dirigida por un Scrum Master.
  • Participan los representantes de cada equipo perteneciente al proyecto.

Objetivos de la reunión

  • Coordinar el trabajo de múltiples equipos que trabajan para un mismo proyecto.
  • Evitar atrasos por dependencias o riesgos no identificados a tiempo.

Para garantizar efectividad en este evento, se realizan las siguientes preguntas:

  • ¿En qué ha estado trabajando tu equipo?
  • ¿En qué va a trabajar tu equipo?
  • ¿Han tenido impedimentos?
  • ¿Existen dependencias entre tu equipo y otros equipos?

Coordinación de Sprints

Cuando en un proyecto se cuenta con múltiples equipos, es importante garantizar que sus Sprints se mantienen coordinados en el tiempo, es decir, todos los equipos inician y terminan sus Sprints en las mismas fechas.

Ilustración 21 - Coordinación de Sprints.

Algunas consideraciones a tener en cuenta son:

  • Debería realizarse una sola reunión de planificación de Sprint.
  • Podría hacerse una sola reunión de revisión del Sprint.
  • Cada equipo debe realizar su propia retrospectiva. Sin embargo, es importante hacer una sesión periódica de lecciones aprendidas de todos los equipos para compartir el conocimiento adquirido en cada equipo.

1.7.2. Artefactos Scrum para grandes proyectos

El Product Backlog

A menudo, varios Equipos Scrum trabajan juntos para desarrollar el mismo producto. Para describir el trabajo a realizar sobre el producto se utiliza un único Product Backlog.

  • Podría usarse un atributo del Product Backlog para agrupar los elementos que pertenecen a los distintos equipos.

1.7.3. Roles en grandes organizaciones/proyectos

Escalar Scrum en grandes organizaciones es un tema que cada vez ha requerido más atención, pues cada organización tiene sus propias necesidades, puntos de dolor, y distribución de equipos y/o productos. Uno de los puntos a tener en cuenta es la asignación de roles, dado que, para escalar Scrum, no bastará solamente con definir los tres roles fundamentales en los equipos (Development team - Scrum Master - Product Owner), pues se necesitará mejor coordinación en medio de la alta complejidad y saturación que representa un proyecto / organización grande.

Program Owner

Cuando los proyectos hacen parte de un programa, el rol de Program Owner toma bastante relevancia. El Program Owner será el rol responsable de:

  • Gestionar el Product Backlog del programa.
  • Garantizar la entrega de beneficios.
  • Aprobar o rechazar los cambios a nivel de programa.
  • Coordinar el trabajo con los distintos Product Owner de cada proyecto perteneciente al programa.

Agile Coach

El Agile Coach (Coach ágil) es quien se encarga de promover la adopción de la agilidad en una organización o proyecto grande, independiente del punto en el que se encuentre, es decir que puede involucrarse en cualquier momento sin importar qué tanto progreso se lleve.

Contar con el apoyo de un Agile Coach conlleva a fortalecer el interés del personal en la adopción de la agilidad, mejorar la ejecución de técnicas y métodos ágiles, e incluso puede brindar un acompañamiento completo en la transformación ágil de una empresa que esté fundamentada en métodos tradicionales y que no haya escuchado antes de agilidad.

Cabe hacer una aclaración importante sobre el Agile Coach, dado que este rol no se encarga de tomar decisiones técnicas, pues su trabajo es guiar a las personas para conseguir que sean ellos quienes tomen las buenas decisiones.

Para que un Agile Coach se desenvuelva con éxito, debe contar con una serie de capacidades, conocidas como “las 11 competencias del Coaching”, una guía desarrollada por ICF (International Coach Federation) para estructurar y desarrollar el proceso de Coaching.

Según ICF, las 11 Competencias del Coaching se clasifican en cuatro grupos según su funcionalidad dentro proceso de Coaching seguido con el cliente, quedando de la siguiente manera:

A. Establecer los cimientos
1. Adherirse al código ético y estándares profesionales. Capacidad de comprender la ética y los estándares del coaching y de aplicarlos apropiadamente en todas las situaciones de coaching.
2. Establecer el acuerdo de Coaching. Habilidad de entender lo que se necesita en cada interacción específica de coaching y establecer el acuerdo con cada nuevo cliente sobre el proceso y la relación de coaching.
B. Crear conjuntamente la relación
3. Establecer confianza e intimidad con el cliente. Habilidad para crear un entorno seguro que contribuya al desarrollo de respeto y confianza mutuos.
4. Estar presente en el Coaching. Habilidad para tener plena conciencia y crear relaciones espontáneas de coaching con el cliente, usando un estilo abierto, flexible y que demuestre seguridad y confianza.
C. Comunicar con efectividad
5. Escuchar activamente. Habilidad para enfocarse completamente en lo que el cliente dice y lo que no dice, entender el significado de lo que se dice en el contexto de los deseos del cliente, y apoyar al cliente para que se exprese.
6. Realizar preguntas potentes. Habilidad de hacer preguntas que revelen la información necesaria para sacar el mayor beneficio para el cliente y la relación de coaching.
7. Comunicar directamente. Habilidad para comunicarse de manera efectiva durante las sesiones de coaching, y utilizar el lenguaje de modo que tenga el mayor impacto positivo posible sobre el cliente.
D. Facilitar aprendizaje y resultados
8. Crear consciencia. Habilidad de integrar y evaluar con precisión múltiples fuentes de información y de hacer interpretaciones que ayuden al cliente a ganar consciencia y de ese modo alcanzar los resultados acordados.
9. Diseñar acciones. Habilidad para crear con el cliente oportunidades para desarrollar el aprendizaje continuo, tanto durante el coaching como en situaciones de la vida o el trabajo, y para emprender nuevas acciones que conduzcan del modo más efectivo hacia los resultados acordados.
10. Planificar y establecer metas. Habilidad para desarrollar y mantener con el cliente un plan de coaching efectivo.
11. Gestionar progreso y responsabilidad. Capacidad de poner la atención en lo que realmente es importante para el cliente y dejar la responsabilidad para actuar en manos del cliente.

Tomado y adaptado de: International Coach Federation España. https://www.icf-es.com/mwsicf/ser-coach-de-icf/competencias-coaching-icf-espana

Diferencias entre el Agile Coach y el Scrum Master Es muy común pensar que el Agile Coach es el mismo Scrum Master de un equipo Scrum, y aunque tienen objetivos muy similares, su nivel de actuación no es el mismo:

  • El Agile Coach actúa nivel global, suele ser externo al equipo y no pertenece a un proyecto o equipo específico, a diferencia del Scrum master que sí pertenece a un equipo o proyecto.
  • El Agile Coach está a un nivel estratégico y táctico, el Scrum Master generalmente está a un nivel táctico.
  • El Scrum Master está involucrado directamente con un equipo/proyecto, mientras que el Agile Coach está involucrado más desde un nivel organizativo, por lo que tiene un alcance mucho más amplio que el Scrum Master.

Line Manager:

Un Line Manager (Gerente de Línea) es el rol responsable de gestionar una línea de negocio de la organización, lo cual va desde el manejo y desarrollo del producto, calidad, procedimientos de producción y entrega del producto / servicio, crecimiento, cumplimiento de objetivos, hasta precios y estrategias.

El Line Manager actúa como un engranaje estratégico en dos aspectos:

  • Decisiones relacionadas con la línea de negocio, al garantizar que los nuevos programas, proyectos, productos, servicios se desarrollen y ejecuten de manera oportuna y efectiva. Una de sus grandes responsabilidades es identificar problemas relacionados con alcanzar los objetivos de la estrategia.
  • Liderazgo del personal que hace parte de la línea de negocio, promoviendo la motivación e influyendo en los empleados para que trabajen en el mejor clima posible y eficazmente hacia la consecución de los objetivos establecidos por la organización.

Dada la criticidad e importancia del Line Manager, es vital que la persona que ocupe este rol tenga un gran compromiso con la organización, muy similar a pensar y actuar como un CEO (para la línea de negocio), con una mirada holística y con mayor foco en el comportamiento de la línea de negocio en el mercado y de cara al cliente final.

Es muy común que en desarrollo de software, el rol de Line Manager tenga diferentes responsabilidades según el ciclo de vida del desarrollo: En etapas iniciales del proceso de desarrollo el Line Manager se encarga de gestionar a los interesados para la recopilación de requerimientos, mientras que en etapas más avanzadas puede coordinar la ejecución de las pruebas de aceptación del producto, o coordinar el despliegue en producción.

En algunos casos se puede confundir el rol del Line Manager con un Gerente de proyecto tradicional, sin embargo cabe la aclaración de que el Line Manager permanece ligado al producto no solo durante el proceso de desarrollo, pues continua al frente del producto en etapas de comercialización, actualización, soporte, servicio, mantenimiento y hasta la eventual salida del mercado, mientras que la responsabilidad del Gerente de proyecto termina cuando el producto se termina de construir y/o el proyecto finaliza.

El Line Manager también asegura un ambiente de cohesión y se centra en la colaboración entre todos los miembros que hacen parte de la línea de negocio (equipos de proyecto, soporte, venta, mantenimiento, etc) con el fin de cumplir con los objetivos de negocio definidos a nivel estratégico.

Diferencias entre el Line Manager y el Gerente de proyecto

Aunque el Line Manager y el Gerente de proyecto tienen responsabilidades muy similares, no se encuentran al mismo nivel de autoridad, ni representan la misma criticidad para la organización:

  • El Line Manager es responsable de asegurar que el producto y/o servicio entregado cumple con las necesidades de los usuarios y expectativas del negocio durante la prestación, mientras que el Gerente de proyecto asegura el cumplimiento de los objetivos del proyecto en cuanto a tiempo, alcance, costo.
  • En una estructura jerárquica típica, el Gerente del proyecto da instrucciones de trabajo a los miembros del equipo del proyecto, independientemente del departamento o grupo funcional del que provengan, mientras que el Line Manager tiene autoridad solamente sobre el personal que hace parte de la línea de negocio que tiene bajo su responsabilidad.
  • El nivel de autoridad del Line Manager tiene mayor alcance en la organización, pues puede tomar decisiones sobre el producto según la estrategia del negocio, lo cual implica que puede afectar la forma en que se desarrolla, soporta, comercializa, entrega el producto / servicio; mientras que el Gerente de proyecto únicamente puede tomar decisiones a nivel de proyecto, es decir, en la construcción del producto / servicio, según lo definido por el Line Manager o equivalente.

Release Manager

El Release Manager (Gestor de versiones) es el encargado de administrar el ciclo de vida de las versiones de los productos a través de los entornos de desarrollo, prueba y producción

Es muy común que el rol de Release Managere se confunda con el de un Project Manager, sin embargo, el Release Manager se considera que tiene mayores responsabilidades ya que se involucra en distintos aspectos de la organización, como la planificación, coordinación, seguimiento, gestión de riesgos, pruebas, comunicación y lanzamiento / implementación de las diferentes versiones de los productos en la organización; mientras que el Project Manager se ocupa

El Release Manager debe contar con la capacidad necesaria para colaborar y negociar adecuadamente entre diversos equipos, con partes interesadas tanto externas a la empresa como internas.

Algunas de las funciones más representativas que debe cumplir el Release Manager, son:

  • Planificar las ventanas de lanzamiento y el ciclo de vida de lanzamiento general de la versión del producto.
  • Gestión de riesgos que pueden afectar el alcance de la versión.
  • Comunicar todos los planes, compromisos y cambios clave del proyecto, incluidos los requisitos.
  • Medir y monitorear el progreso de la versión.
  • Manejar relaciones y coordinar los proyectos entre distintos equipos, para asegurar coordinación en las entregas que se realizan en los diferentes entornos (construcción, pruebas, producción)

1.7.4. Distribución de equipos

Cuando un Proyecto es muy grande y un solo Equipo Scrum no es suficiente para desarrollar todo el trabajo, será necesario contar con múltiples equipos. Algunas de las consideraciones que se deben tener en cuenta para realizar la distribución de los equipos son:

  • Hasta donde sea posible, se debería contar con un solo Product Owner para el proyecto.
  • El tamaño de los equipos debería mantenerse equilibrado.
  • No deberían conformarse equipos especializados, los equipos multifuncionales avanzan más rápido y generan menos dependencias.
  • No deberían cambiarse los miembros de equipo durante la ejecución del proyecto.

El equipo Scrum en grandes proyectos

A menudo, varios Equipos Scrum trabajan juntos para desarrollar el mismo producto. Para describir el trabajo a realizar sobre el producto se utiliza un único Product Backlog.

  • Podría usarse un atributo del Product Backlog para agrupar los elementos que pertenecen a los distintos equipos.