Scrum & Scrum de Scrums (II)

23:04

Siguiendo con el post anterior en el que veíamos por encima Scrum, ahora explicaré la segunda parte:

"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.
           3. Creación de un equipo de Product Owners[1].
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.

You Might Also Like

0 comentarios

Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.

statistics :: ヽ(*・ω・)ノ

Contact Form :: (」゜ロ゜)」