Siguiendo con el post anterior en el que veíamos por encima Scrum, ahora explicaré la segunda parte:
"Scrum de Scrums"
─ Número de personas por sub-equipo:
"Scrum de Scrums"
Introducción
El software es cada vez
más sofisticado y ello implica en la mayoría de las ocasiones que su
complejidad aumente y por tanto, se necesiten tener varios equipos pequeños
(sub-equipos), auto-organizados y multidisciplinares que remen hacia un mismo
objetivo: la creación del producto final.
Los componentes principales
con los que debemos al aplicar Scrum a proyectos grandes es la siguiente:
1.
División
del equipo completo a equipos más pequeños.
2.
Sólo se
debe mantener un único Product Backlog.
A través de las siguientes
secciones ampliaremos estos puntos.
[1] Equipo de Product Owners: esto es una
recomendación cuando la gestión del Product Backlog es muy compleja y se
necesita que haya más de un Product Ownler y además estén lo más sincronizados
posible.
El Equipo y los Sub-Equipos
 |
| División del Equipo en Sub-Equipos |
─ Número de personas por sub-equipo:
Por defecto, Scrum dice
que un equipo no debe tener más de 10-12 personas (existe riesgo de perder el
control) y no menos de 3 personas (ya que la interacción decae). Para formar
los sub-equipos Scrums seguiremos el mismo patrón que para formar un único
equipo Scrum en cuanto al número de personas.
─ Cómo dividir al equipo en sub-equipos:
La recomendación es que
cada equipo tenga bloques de Historias de Usuario completas.
─ Composición y Roles en los sub-equipos:
Cada equipo tendrá un
Scrum Master y un único Product Backlog priorizado y estimado y estimado.
Además las reuniones se mantendrán como con Scrum tradicional.
─ Los sub-equipos forman un equipo:
No se debe olvidar que
todos los sub-equipos forman un único equipo, por lo tanto se debe tener muy en
cuenta la interdependencia entre equipos y tener una visión profunda del
desarrollo global de la aplicación en cada sub-equipo. Para ello veremos
métodos para solventar este problema a lo largo del documento.
Los Product Owner y los Product Master
Como vimos en el apartado
2.1, el Product Owner es el rol más complejo y de más responsabilidad dentro de
los equipos Scrum. Por ello, cuando hablamos de crear sub-equipos necesitamos
también tenemos que pensar en el papel del Product Owner y analizar como
debemos administrar el rol tanto para el Equipo, como para los sub-equipos.
La propuesta es tener un
equipo de Product Owners que sean responsable de mantener un único Product
Backlog donde además es recomendable que exista una jerarquía en la que exista
una persona, denominada Product Master que guíe al equipo de Product Owners y
resuelva las encrucijadas, elaborando un plan estratégico que guíe hacia el
desarrollo completo con éxito del producto a desarrollar.
El Product Master está más
alejado de los sub-equipos, aunque puede tener reuniones con ellos para
dotarlos de la visión global.
El Product Backlog
En este apartado la
tentación general es crear un Product Backlog por sub-equipo, pero se ha
comprobado que es un error. Esto se debe a que la complejidad de cada Product
Backlog retrasa al desarrollo global del producto. Por ello es importante crear
un único Product Backlog, compuesto por Vistas, que serán accesibles por los
sub-equipos de manera individual, asociando una única Vista a cada uno de
ellos.
 |
| Las Vistas de Scrum de Scrums |
El siguiente error que se
comete una vez solucionado este, es crear un Product Backlog único pero
infinito o gigantesco, perdiendo el foco en el desarrollo del producto y
haciendo tedioso su mantenimiento y la conceptualización y asociación de las Vistas
en cada sub-equipo. Por ello es recomendable utilizar siempre un conjunto de
Historias de Usuario abarcable y que no difumine o atrase el avance del
desarrollo. Se suelen utilizar Temas para agrupar las Historias de Usuario.
Las Reuniones
Cuando trabajamos varios
equipos en conjunto, existe un claro peligro de que cada sub-equipo pierda
confianza en otros equipos, promoviendo políticas de comportamiento “egoístas”
para su sub-equipo a la hora de tomar decisiones importantes, que afectan al
conjunto y por lo tanto al desarrollo final del producto.
 |
| Reuniones de Scrum de Scrums |
Tiene las siguientes
características:
· Frecuencia: dos o tres veces por semana.
· Duración: lo recomendable es que no sobrepase
los 15 minutos.
· Componentes: un representante de cada
sub-equipo. No tiene por qué ser siempre el mismo, y se recomienda que acuda el
Scrum Master. También existe la posibilidad de que los sub-equipos lleven a
asesores que resuelvan los problemas con mayor eficiencia.
· Estructura: la misma aplicada que a las Daily
Meetings. Impedimentos, Retrospectiva desde la última reunión y que se tiene
que hacer hasta la siguiente reunión.
Las Dependencias entre Equipos
Sin duda alguna, una de
los principales inconvenientes que tiene trabajar en sub-equipos es la
inter-relación que existen entre los distintos componentes y/o tareas de los
mismos.
Para resolver posibles
impedimentos, se han establecido una serie de recomendaciones, que mostramos a
continuación:
· Intercambio de los componentes de los
sub-equipos entre iteraciones: esto favorece la comunicación y cohesiona al
equipo completo.
· Reuniones de Inicio y Fin de Release: es
conveniente reunir a todos los miembros involucrados en el desarrollo del
producto a lo largo de todo el proceso e incluso más tanto al inicio como al
final de la release.
· Sprint Reviews Abiertas: es interesante tener
distintos puntos de vista sobre el desarrollo de un Sprint y por ello es
recomendable invitar a miembros de otros sub-equipos a las Sprint Reviews
siempre que sea posible.
· Retrospectivas Generales: son reuniones en
los que se aprovecha para analizar lo ocurrido durante el Sprint anterior,
similares a las Retrospectivas pero en las que pueden participar miembros de
otros sub-equipos.
· Sincronización de Sprints: es muy
recomendable intentar coincidir las fechas de inicio y fin de todos los
Sprints, así se podrán realizar las reuniones y la sincronicidad de los
miembros de los sub-equipos será mucho mayor. Tampoco hay que ser muy estricto,
puede existir un desfase de 2 o 3 días sin que surjan problemas.
Grupos Transversales
Lo que hace fuerte a
Scrums de Scrums, es la capacidad de los miembros para transmitir experiencias
entre sub-equipos, obtener fuentes de aprendizaje constantes y poder
compartirlas. Para ello se recomienda y se promueve en Scrum de Scrums la
generación de grupos transversales compuestos por diferentes miembros de
sub-equipos, cuyo cometido será especializarse en resolver problemas comunes,
establecer estándares para diferentes tecnologías, o estudiar nuevas fuentes de
información, entre otras muchas opciones. Esto aumenta la cohesión y resuelve
futuros impedimentos.
Conclusiones
Javier Garzás[1]
preguntó recientemente a Jeff Sutherland[2] en
una entrevista personal, cual era el principal problema de Scrum. Jeff Sutherland
contestó: ‘nuestro principal problema es la mala agilidad.’[3].
Si para un solo equipo de
Scrum ya surgen complicaciones, para la correcta ejecución de un Scrum de
Scrums la cosa se complica mucho. La gestión de la interacción, la
interdependencia, la necesidad de transversalidad de los conocimientos entre
sub-equipos y el mantenimiento de Vistas llena de puntos débiles el desarrollo
de un proyecto ágil.
El principal problema que
tienen los equipos al utilizar Scrum de Scrums es la poca o nula
institucionalización de los miembros, y el poco conocimiento colmena, importante
para la correcta finalización de las distintas iteraciones.
A través de esta guía
práctica se ha intentado establecer un código de buenas prácticas recopilado de
diversas fuentes, incluidas nuestras propias aportaciones y algunos puntos se
deben cumplir a raja tabla para evitar el fracaso.
Otro punto importante y a
destacar es la gran disciplina requerida día a día por parte de los diferentes
roles de todos los miembros y que es el mayor impedimento que hemos encontrado
a Scrum de Scrums. No obstante si se tiene en mente o sobre la mesa un proyecto
de grandes dimensiones en el que se requiera por diferentes motivos el uso de
Scrum, Spotify tiene un caso de estudio de la utilización de Scrum de Scrums,
como prueba de éxito de su aplicación en entornos reales[4].
[1] Javier Garzás: experto en Metodologías Ágiles
dentro del habla hispana, autor de ‘Cómo sobrevivir a la planificación de un
Proyecto Ágil’.
[2] Jeff Sutherland: uno de los padres de Scrum.
Estos documentaron el proceso Scrum en un proyecto real en 1993.
[3] Cita Original: Twitter Javier Garzás -
07/11/2013: “@jgarzas: En Estocolmo, acabo de conocer a Jeff Sutherland (padre
de Scrum), a los 3 min. dice "our main problem is the bad agile". Que
grande.”
[4] Caso
de estudio Spotify “Scrum de Scrums”: http://www.javiergarzas.com/2012/11/spotify-agil-desarrollo.html
Bibliografía
1. [Libro] Agile Project
Management with Scrum – [Autor] Ken Schwaber
2. [Web-Blog]
www.javiergarzas.com – [Redactor] Javier Garzás
3. [Libro] Métodos Ágiles
y Scrum – [Autores] Alonso Álvarez García, Rafael de las Heras del Dedo, Carmen
Lasa Gómez
4. [Apuntes Curso] Curso
Scrummanager.net – [Autores] Juan Palacio, Claudia Ruata
5. [Web] AgileAlliance.org – [Post]
http://guide.agilealliance.org/guide/scrumofscrums.html
6. [Web] ScrumAlliance.org – [Post]
http://www.scrumalliance.org/community/articles/2013/june/scrum-of-scrums-running-agile-on-large-projects
7. [Web-Blog] AgileUnleashed.blogspot.com – [Autor] Stoyan Rachev –
[Post] http://agileunleashed.blogspot.com.es/2009/08/scrum-of-scrums-approach-for-scaling.html
8. [Web-Blog] Agile.dzone.com – [Autor] Kelly Waters - [Post]
http://agile.dzone.com/news/scrum-scrums
Y hasta aquí Scrum de Scrums, nos vemos en las siguientes soft-aventuras.
Y hasta aquí Scrum de Scrums, nos vemos en las siguientes soft-aventuras.
