Scrum a Escala - Ciclo Scrum Master
Un conjunto de equipos Scrum que tienen la necesidad de coordinarse entre sí componen un Scrum de Scrums (SoS, por sus siglas en inglés). Este equipo es un Equipo Scrum en sí mismo, responsable de un conjunto totalmente integrado de incrementos de producto potencialmente implementables al final de cada Sprint de todos los equipos participantes. Un SoS funciona como un Equipo de Release y debe ser capaz de entregar valor directamente a los clientes. Para hacerlo efectivamente, debe ser consistente con la Guía de Scrum; es decir tener sus propios roles, artefactos y eventos, aunque dada su naturaleza escalada hay algunas consideraciones adicionales:
Roles:
El SoS necesita tener todas las habilidades necesarias para entregar un producto totalmente integrado potencialmente implementable al final de cada Sprint y para facilitar la coordinación entre equipos cuando fuera necesario. (Puede necesitar arquitectos experimentados, líderes de QA, miembros del Equipo Product Owner y otros conjuntos de habilidades operacionales).
Además, tiene representación del Product Owner para resolver problemas de priorización. El Scrum Master del Scrum de Scrums se denomina Scrum de Scrums Master (SoSM, por sus siglas en inglés).
Eventos:
Manejo de Impedimentos a nivel SoS: El SoSM debería facilitar el Refinamiento del Backlog, evento donde los impedimentos son identificados como "listos" para ser removidos, y el equipo determina cuál es la mejor manera de removerlos, y cómo sabrán cuando estén "hechos". Estos ítems de backlog de eliminación de impedimentos son priorizados para los equipos que están en el mismo backlog creados por el SoS, CPO y Equipo Product Owner. Se debe prestar especial atención a la Retrospectiva de SoS en la que los representantes de los equipos comparten cualquier aprendizaje o proceso de mejora que haya sido exitoso en sus equipos individuales, para estandarizar esas prácticas en todos los equipos dentro del SoS.
Dado que el equipo SoS necesita ser capaz de responder en tiempo real a los impedimentos planteados por los equipos participantes, al menos un representante de cada equipo (usualmente el Scrum Master del equipo) debe participar en la Scaled Daily Scrum (SDS).
El SDS:
El evento SDS es similar a la Daily Scrum, ya que optimiza la colaboración y performance de la red de equipos. Cualquier persona y cantidad de miembros de los equipos participantes pueden asistir según sea necesario:
· es un timebox de 15 minutos o menos,
· debe participar un representante de cada equipo incluyendo el equipo de Product Owners,
· es un foro donde los participantes discuten qué está yendo bien, qué se está haciendo, y cómo los equipos pueden trabajar juntos más efectivamente. Algunos ejemplos de lo que se podría discutir son:
· ¿Qué impedimentos tiene mi equipo que les impedirán cumplir su Objetivo del Sprint (o impactarán el próximo release)?
· ¿Mi equipo está haciendo algo que evitará que otro equipo cumpla su Objetivo del Sprint (o impactará en el próximo release)?
· ¿Hemos descubierto algunas nuevas dependencias entre los equipos o alguna forma de resolver una dependencia existente?
· ¿Qué mejoras hemos descubierto que puedan ser aprovechadas por los equipos?
El Scrum de Scrums Master (SoSM)
El Scrum Master del Scrum de Scrums se llama Scrum de Scrums Master (SoSM), es responsable del release del esfuerzo conjunto de los equipos y debe:
· hacer visible el progreso,
· hacer visible el backlog de impedimentos a toda la organización,
· eliminar impedimentos que los equipos no pueden resolver por sí mismos,
· facilitar la priorización de los impedimentos, poniendo especial atención en las dependencias entre equipos y la distribución del backlog,
· mejorar la eficacia del Scrum de Scrums,
· trabajar cerca del Equipo de Product Owners para tener un Incremento de producto potencialmente implementable al menos cada Sprint
· y coordinar la implementación de los equipos con los Planes de Release de los Product Owners.
Escalar el SoS
Dependiendo del tamaño de la organización o de la implementación, se puede necesitar más de un SoS para entregar un producto muy complejo. En esos casos, se puede crear un Scrum de Scrum de Scrums (SoSoS, por sus siglas en inglés) a partir de múltiples Scrums de Scrums. El SoSoS es un patrón orgánico de equipos Scrum infinitamente escalable. Cada SoSoS debe tener SoSoSM y versiones escaladas de cada artefacto y evento.
Escalar los SoS reduce la cantidad de canales de comunicación dentro de la organización para que la complejidad esté encapsulada. El SoSoS interactúa con un SoS de la misma manera que un SoS interactúa con un solo equipo Scrum permitiendo la escalabilidad lineal.
Diagramas de ejemplo:
SoS de 5 Equipos
SoSoS de 25 Equipos
NOTA: Si bien la Guía de Scrum define que el tamaño óptimo de un equipo es de 3 a 9 personas, Harvard Research determinó que el tamaño óptimo de un equipo es de 4,6 personas(1). Experimentos con equipos Scrum de alta performance han demostrado reiteradas veces que 4 o 5 personas trabajando es el tamaño óptimo. Es esencial para la escalabilidad lineal que este patrón sea el mismo para el número de equipos en un SoS. Por lo tanto, se seleccionaron pentágonos para representar a un equipo de 5. Estos diagramas son solo ejemplos, su diagrama organizacional puede ser muy diferente.
(1) Richard Hackman, Leading Teams: Setting the Stage for Great Performances, (Boston, Harvard Business School Press, 2002).