Scrum de Scrum: Desarrollo ágil para grandes proyectos

Se ha dicho que los métodos de desarrollo de software ágil y Scrum, son ideales para proyectos desarrollados por equipos multidisciplinarios de pocas personas y localizados en la misma oficina. Sin embargo, cada vez se observan más ejemplos de grandes compañías utilizando Scrum en proyectos de gran escala, con equipos de proyectos integrados por decenas y hasta cientos de desarrolladores.

La técnica de las reuniones Scrum de Scrum es la que permite escalar el enfoque Scrum para grandes equipos de proyecto a escala corporativa, esta técnica, consiste en dividir un equipo de muchas personas en diferentes equipos Scrum, para luego utilizar reuniones Scrum de Scrum para coordinarlos. A cada reunión de Scrum de Scrum asiste uno o dos integrantes de cada equipo.

En este artículo se discute cuantos equipos Scrum necesitamos para un proyecto dado, que especialistas deben integrar cada equipo Scrum, quienes asisten a la reunión Scrum de Scrum, como se escalan los puntos tratados, frecuencia de estas reuniones y la agenda.

Cuantos equipos Scrum se necesitan

Dado que el tamaño ideal de un equipo Scrum es de entre 5 y 9 participantes, cuando se tienen 10 o más integrantes, la solución es dividir a un gran equipo en subequipos, manteniendo la regla de entre 5 y 9 participantes. Cada equipo deberá tener un Scrum Master, su propia lista de objetivos y características (Backlog) y ser atendido por un dueño de producto (Product Owner).

Que roles de desarrollo de software integran cada equipo de desarrollo Scrum

No es una buena práctica dividir los equipos por componentes o especializados por tecnología, por ejemplo desarrollo de Base de datos, desarrollo de aplicaciones, equipo de pruebas, etc. En su lugar, la buena práctica es crear equipos multifuncionales, cada uno capaz de desarrollar y probar una característica (Feature) del producto, en todos los componentes y capas involucrados. Por ende, el equipo deberá incluir desarrolladores de todas las capas involucradas, analistas funcionales, analistas de pruebas, etc.

Deben distribuirse por igual los niveles de experiencia y conocimiento del negocio (Know-How), con la intención que cada equipo sea capaz de tomar una historia del Backlog y transformarla en un producto.

Curso Práctico de Scrum Master

La mayoría de los cursos de Scrum se enfocan demasiado en la teoría, limitándose al contenido de la Guía Scrum.

Con el Curso Scrum Práctico en Proyectos de Software aprenderás consejos y prácticas aplicables en proyectos reales.

Incluye un módulo de Scrum para grandes proyectos. Inscríbete.

Quienes asisten a la reunión Scrum de Scrum

Cada equipo designa a uno de sus integrantes para asistir a la reunión Scrum de Scrum. Es buena práctica que sea un participante técnico (Desarrollador o Tester), y no el dueño de producto o Scrum Master.

No necesariamente tiene que ser siempre la misma persona, sino que puede rotar según la etapa del proyecto y quien esté en mejor posición para contribuir con la reunión. Al principio del proyecto deberían enviarse a personal técnico o diseño de usuario, mientras que al final debería enviarse a personal que está ejecutando las pruebas.

Si el número de equipos Scrum es pequeño, pueden asistir hasta dos personas por equipo, por ejemplo un participante técnico y el Scrum Master.

Escalamiento de las reuniones Scrum de Scrum

Cuando los proyectos son grandes, las reuniones Scrum de Scrum se pueden escalar en múltiples niveles. Por ejemplo, supongamos que se tienen 49 equipos Scrum de 7 personas cada uno. Por cada equipo se selecciona a una persona a asistir a reuniones Scrum de Scrum, de esta forma, se conforman 7 reuniones con 7 participantes cada una. Por cada uno de estos equipos se puede escalar a 3 equipos y estos a su vez a un equipo directivo. Bajo este ejemplo se tendrían 4 niveles.

Frecuencia de las reuniones Scrum de Scrum

Las reuniones Scrum de Scrum deben ser frecuentes, pudiendo considerar inclusive la frecuencia diaria o tres veces a la semana (por ejemplo los lunes, miércoles y jueves). Se recomienda que tenga la misma duración de la reunión diaria (15 minutos).

Tal como indica Mike Cohn, miembro de la junta directiva del Scrum Alliance (Ver aquí), es aconsejable reservar 30 minutos adicionales para resolución de problemas y consultas de información que surjan de la reunión, dado que si bien a nivel de equipo Scrum se pueden dejar asuntos por resolver en reuniones sucesivas, en las Scrum de Scrum debe buscarse resolución inmediata y así evitar programar muchas reuniones con las mismas personas.

Agenda

La agenda de las reuniones Scrum de Scrum debería ser similar a la de los Scrums diarios, realizando algunos ajustes, dado que en la reunión no están los equipos completos sino representantes de cada equipo. A cada integrante del Scrum de Scrum, que a su vez representa cada uno a un equipo, se le pregunta lo siguiente:

¿Qué actividades ejecutado tu equipo desde la última reunión?

¿Qué actividades realizará tu equipo antes de la próxima reunión? (Próximos pasos).

¿Existen impedimentos en tu equipo?

¿Existe alguna actividad a ejecutar próximamente por tu equipo que interfiera o afecte de alguna forma el trabajo de otro equipo?

Al igual que las reuniones diarias (Daily Scrum), la intención es que la exposición de cada integrante sea breve e ir al grano. Los problemas se pueden mencionar, no se buscan soluciones hasta que cada integrante ha hecho su exposición.

Una vez finalizada se realiza la segunda parte de la reunión, en la cual los participantes discutirán los problemas o situaciones planteadas, o puntos tratados en reuniones previas que aún no se han cerrado.

El equipo mantendrá un Backlog de Scrum de Scrum, el cual es análogo a lo que se llamaría una lista de issues en proyectos tradicionales. Es un simple listado con asuntos que los participantes necesitan tomar acción sobre ellos o hacer seguimiento por alguna razón. Pueden incluirse issues de otros grupos Scrum de Scrum pero que este equipo necesita ser notificado de la resolución.

A diferencia de cada equipo Scrum, el grupo Scrum de Scrum no realiza planificaciones de iteración ni revisiones de Backlogs, cada miembro del grupo es simplemente un participante del grupo al que pertenece, con la intención de coordinar actividades entre grupos Scrum. Cada iteración puede traer consigo un conjunto de participantes diferentes en las reuniones Scrum de Scrum. Quien asume los compromisos y la responsabilidad que el proyecto avance es cada equipo Scrum individual, el grupo Scrum de Scrum no tiene responsabilidades directivas.

Conclusión

Lo dicho anteriormente puede significar que existan personas que necesiten asistir a dos o más reuniones Scrum de Scrum, sin embargo, la experiencia indica que la técnica escala muy bien dado que los participantes claves están involucrados en las reuniones y la información fluye hacia los niveles ejecutores más rápido y con menos interferencia en la comunicación.

Y que hay de usted, ¿Ha aplicado alguna vez el enfoque Scrum a proyectos grandes?, ¿Ha utilizado las reuniones Scrum de Scrum?, ¿Cual ha sido su experiencia?, ¿Que agregaría a lo propuesto en este artículo?, les invitamos a dejar comentarios al respecto en este Post (Los comentarios serán revisados antes que sean visibles en el blog).

¿Buscas más información de metodologías de desarrollo de software?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de desarrollo de software?, entonces presiona "suscríbete" a continuación.

También puedes seguirnos vía Twitter, Facebook o Linkedin: