Curso:

SCRUM GRAND MASTER

 pag. 2

Presentación:

En esta unidad exploraremos técnicas, prácticas y herramientas

avanzadas que, si bien no son parte del marco de trabajo de
Scrum, suelen complementarlo en equipos maduros.
 pag. 3

Unidad 3:

Herramientas Avanzadas para Scrum

 pag. 4

Objetivos:

Al terminar la Unidad los participantes:

❑ Entenderán herramientas, prácticas y técnicas avanzadas

que complementan al Marco de Trabajo de Scrum.

❑ Contarán con referencias para profundizar problemáticas

avanzadas relacionadas con Scrum.

❑ Contarán con elementos de ayuda y guías para el

crecimiento como Scrum Master y la implementación de
Scrum.
 pag. 5

Temario:

1. Introducción
2. Duración del Sprint
3. Sprint 0
4. La 4ta Pregunta
5. Sprint H
6. Aterrizaje de Emergencia
7. Herramientas de Software para Scrum
8. Escalando Scrum
9. Comunidades y Certificaciones
10. Conclusiones
 pag. 6

Temario Detallado
1 Introducción ............................................................................................................. 8
2 Definición de la Duración del Sprint ......................................................................... 9
2.1 Introducción ....................................................................................................... 9
2.2 Elección por default ........................................................................................... 9
2.3 Aspectos a Considerar ....................................................................................... 9
3 Sprint 0.................................................................................................................... 11
3.1 Definición ......................................................................................................... 11
3.2 Entregables/Resultados Típicos ....................................................................... 11
3.3 Sobre el Uso del Sprint 0 .................................................................................. 12
4 La 4ta Pregunta ....................................................................................................... 14
5 Sprint H ................................................................................................................... 15
5.1 Definición ......................................................................................................... 15
5.2 Entregables/Resultados Típicos ....................................................................... 15
5.3 Sobre el Uso del Sprint H ................................................................................. 16
6 Aterrizaje de Emergencia ....................................................................................... 18
6.1 Definición ......................................................................................................... 18
6.2 Antes de cancelar un Sprint ............................................................................. 19
7 Herramientas de Software para Scrum .................................................................. 20
7.1 Del Uso de las Herramientas en Scrum ........................................................... 20
7.2 Herramientas: ¿para Qué?............................................................................... 20
7.3 Algunas características a Considerar ............................................................... 21
7.4 Las más conocidas............................................................................................ 21
8 Escalando Scrum ..................................................................................................... 22
8.1 Scrum de Scrums.............................................................................................. 22
8.2 Dinámica .......................................................................................................... 23
Frecuencia y Duración ............................................................................................ 23
Preguntas ................................................................................................................ 23
8.3 Escalamiento de Roles ..................................................................................... 24
Dueño de Producto General ................................................................................... 24
Scrum Master General ............................................................................................ 24
8.4 Escalamiento en Varios Niveles ....................................................................... 25
 pag. 7

8.5 Frameworks para Escalar Scrum ...................................................................... 25

SAFe - Scaled Agile Framework .............................................................................. 26
LeSS – Large Scale Scrum ........................................................................................ 26
Nexus ...................................................................................................................... 26
Scrum at Scale......................................................................................................... 26
9 Comunidades y Certificaciones .............................................................................. 27
9.1 Comunidades ................................................................................................... 27
Scrum Alliance ........................................................................................................ 27
Scrum Manager ...................................................................................................... 27
Comunidad Latinoamericana de Metodologías Agiles ........................................... 27
9.2 Certificaciones.................................................................................................. 27
10 Conclusiones ........................................................................................................... 29
 pag. 8

1 INTRODUCCIÓN
En esta unidad presentamos algunas técnicas, prácticas y herramientas que suelen
complementar el marco de trabajo básico de Scrum, en particular en equipos con
Scrum Masters maduros. Cabe aclarar que seleccionamos las técnicas, prácticas y
herramientas más relevantes/difundidas, ya que la lista podría ser muy larga y/o con
elementos de poco uso, poca calidad o poca relevancia.

En las distintas secciones recorremos estas técnicas, prácticas y herramientas en el

orden que suele seguir un proyecto. Este recorrido empieza por la definición inicial de
la duración del Sprint (Sección 2). Repasaremos algunos Sprints especiales: Sprint 0 y
Sprint H (Secciones 3 y 5). Introduciremos una técnica adicional para mejorar la
ceremonia de Reunión Diaria (Sección 4). Veremos los casos extremos de cancelación
de Sprint (Sección 6), y el uso de herramientas de software para Scrum (Sección 7).
Cerraremos este recorrido con mecanismo para escalar Scrum en equipos (muy)
grandes (Sección 8). En la última sección (Sección 9) enumeramos las principales
comunidades y certificaciones que pueden ser de mucha utilidad en el inicio y a lo
largo del camino de implementación de Scrum.

No es necesario leer el material en el orden, cada sección es relativamente

independiente de las otras.
 pag. 9

2 DEFINICIÓN DE LA DURACIÓN DEL SPRINT

2.1 INTRODUCCIÓN
La duración de los Sprints en Scrum es pre-definida y fija. Es la misma para todos los
Sprints. No existen excusas para extender o modificar. Como vimos previamente, el
time-boxing es una de los valores fundacionales de Scrum.

Una de las primeras definiciones a tomar cuando se implementa Scrum es justamente

elegir la duración de los Sprints. Scrum promueve Sprints de entre 1 a 4 semanas, y
elegir entre estas opciones es un paso esencial.

2.2 ELECCIÓN POR DEFAULT

Para un equipo que empieza con Scrum, suele ser difícil la elección de la duración del
Sprint por falta de contexto y elementos de decisión.

En estos casos es bastante común empezar con la duración más difundida: 2 semanas
(o 10 días hábiles).

La recomendación es ejecutar por lo menos 6 sprints con esta duración, para poder
incorporar y probar bien el marco de trabajo de Scrum, y luego reflexionar sobre si
esta duración es adecuada o si es necesario adecuarla (por ejemplo en la ceremonia de
Retrospectiva del Sprint 6).

En casos de buscar una elección de la duración del Sprint más elaborada, vamos a
ampliar algunos elementos de definición…

2.3 ASPECTOS A CONSIDERAR

Recomendamos tener en cuenta las siguientes consideraciones al elegir la duración del
Sprint:

• Presión sobre el equipo: un sprint corto deja poco margen para recuperar atrasos
en caso de problema, y eso suele generar presión en el equipo. Un sprint largo
puede generar también presión en el equipo por dejar pasar “demasiado tiempo”
sin realizar una entrega al cliente.

• Eventos del Calendario: en sprints cortos cualquier evento en el calendario tiene

un impacto significativo (días no laborales, vacaciones, licencias, enfermedades).
 pag. 10

• Esfuerzo Ceremonias: si bien las ceremonias suelen ser más cortas, el esfuerzo de
las ceremonias no es del todo proporcional a su duración. En consecuencia, en
sprints cortos, se suele dedicar más proporción del esfuerzo del Equipo a las
ceremonias.

• Trabajo en Curso: en sprints largo, se abarca más ítems de trabajo, con un mayor
riesgo que surjan problemas en alguno de ellos, y a veces con un costo adicional de
esfuerzo por pasar de un ítem a otro (switch).

• Flexibilidad al Cambio: Recordemos que no se introducen cambios o nuevos

requisitos durante el Sprint, situación por la cual en Sprints de mayor duración se
cuenta con menor flexibilidad. Por ejemplo s el sprint dura 4 semanas, el peor caso
sería tener que esperar 4 semanas para introducir un cambio.
 pag. 11

3 SPRINT 0
3.1 DEFINICIÓN
Un Sprint 0 es un sprint de preparación que ocurre antes de los Sprints “normales” en
los cuales se entrega un producto con valor al cliente. A veces se lo llama también
“Inception Sprint”, “Sprint de Incepción”, o “Iteración Cero”.

El propósito del Sprint 0 es preparar todo lo necesario para el comienzo de Scrum en

un Sprint particular donde puede no haber una entrega de un producto de valor para
el cliente. Se suele preparar el proyecto en aspectos tecnológicos, metodológicos y
organizativos.

Los objetivos de este Sprint 0 dependen mucho del contexto del proyecto, pero en
general son uno, algunos o todos de los siguientes:

• Acordar los roles y sus interacciones

• Armar un plan preliminar de entregas
• Preparar el ambiente de trabajo y sus herramientas
• Consolidar un Backlog de Producto
• Definir aspectos logísticos de los sprints (Duración, Ceremonias, etc.)
• Comunicar el inicio del proyecto (Kick-Off)
• Resolver aspectos técnicos que generan mucha incertidumbre y puedan tener
gran impacto en el proyecto
• Definir la Visión del Proyecto

3.2 ENTREGABLES/RESULTADOS TÍPICOS

Típicamente durante el Sprint 0 se suelen generar algunos de los siguientes
entregables o resultados:

• Definición de los roles y sus interacciones1

• Plan de Entregas
• Ceremonias de los Sprints futuros agendados
• Backlog de Producto refinado
• Ambiente de trabajo configurado para el equipo
• Reunión de Kick-Off (Lanzamiento) realizada
• Documentación inicial del producto/proyecto2
• Visión del producto/proyecto3

1
Ver por ejemplo la notación ScrUML: http://blog.crisp.se/2007/08/25/henrikkniberg/1187995980000
2
Ver por ejemplo la técnica de User Story Mapping: https://www.jpattonassociates.com/user-story-
mapping/
 pag. 12

• Resultados de Pruebas Técnicas

3.3 SOBRE EL USO DEL SPRINT 0

El valor de Scrum reside en gran parte en entregar valor para el negocio en cada sprint.
Un Sprint 0 no aporta valor directamente al negocio. El principal riesgo del sprint 0 es
que se haga todo un pre-proyecto largo sin entrega directa al negocio, y en
consecuencia con pocas oportunidades de aprender sobre el producto a través del
feedback de su uso.

La principal recomendación sería de intentar evitar el Sprint 0, tratando de incorporar

sus actividades a los primeros sprints “normales”, en los cuales si se debería buscar la
entrega de valor al negocio a través de un producto funcionando, aunque sea muy
limitado y de alcance reducido.

En caso de no poder evitar el Sprint 0, la recomendación es que sea lo más corto

posible, del orden de 1 a 4 semanas como gran máximo.

“Y, por supuesto, hacer que este Sprint Cero sea lo más corto posible.
En mi experiencia, este sprint puede ser tan corto como una semana,
que es lo que recomiendo.” (Dan Rawsthorne)

La necesidad de un Sprint 0 largo puede esconder algunas falencias propias de la

dificultad de implementar los principios y valores de la agilidad, como por ejemplo:

• Las decisiones importantes se deben tomar antes de iniciar el proyecto, lo cual

refleja que no se deja espacio a que ciertos aspectos del producto vayan
emergiendo y cambiando a partir del feedback y del descubrimiento que se
hace del mismo Sprint por Sprint.
• No se conoce de antemano el valor para el negocio de lo que se va a construir,
lo cual dificulta fuertemente como elegir porciones del producto con las cuales
empezar.
• Se requiere mucha burocracia y documentación para validar el inicio de un
proyecto.
• La gestión de un proyecto esta impuesta y hay que formalizarla de antemano,
no se deja espacio a los equipos auto-gestionados.

En muchos de estos casos, quizás empezar el Sprint 1 tratando de entregar algo de

valor para el negocio permita resolver algunos de estos problemas, descubriendo

3
Ver por ejemplo la técnica Impact Mapping: http://www.impactmapping.org/
 pag. 13

nuevos conocimientos sobre el producto y su arquitectura, teniendo un conocimiento

más claro sobre sus ventajas, los problemas técnicos a resolver, las herramientas de
trabajo necesarias, como organizarse, etc.
 pag. 14

4 LA 4TA PREGUNTA
A medida que el equipo avance en su implementación de las prácticas de Scrum, y en
particular de la ceremonia de Reunión Diaria, se puede aprovechar estas reuniones
para implementar algunos cambios avanzados.

Muchos autores sugieren aprovechar aún más el espacio de tiempo y comunicación de

las reuniones diarias para compartir más información entre el Equipo.

Concretamente, se sugiere agregar una cuarta pregunta a las tres preguntas clásicas de
la Reunión Diaria:

1. ¿Cuál fue mi avance desde la última Reunión Diaria?

2. ¿En cuales tareas me comprometo a trabajar hasta la próxima Reunión Diaria?

3. ¿Qué problemas tengo que me frenan o bloquean?

Algunas de las más utilizadas como cuarta pregunta son las siguientes:

• ¿Cuál es tu confianza en un nivel de 1 a 10 de que podrá el equipo completar lo

comprometido para el Sprint?
• ¿Qué noticias tienes que puedan interesar o impactar al equipo?
• ¿Qué aprendiste ayer? O sea ¿Qué aprendiste/descubriste/entendiste desde la
última reunión diaria que el equipo debería conocer?
• ¿Qué fue una sorpresa ayer?
• ¿Qué tan útil es esta reunión para vos?
• ¿Estás contento con lo que hay que hacer hoy?
• ¿Necesitas ayuda de alguien?
 pag. 15

5 SPRINT H
5.1 DEFINICIÓN
El Sprint H (H=Hardening=Endurecimiento) es un sprint particular, enfocado en
ponerse al día con deuda técnica acumulada en sprints anteriores, en robustecer y
mejorar técnicamente el producto y en el armado final de la entrega del producto
desarrollado a lo largo de varios sprints. Suele ocurrir luego de varios sprints
“normales” (típicamente luego de 4 a 10 sprints) y antes de una entrega (importante).

A veces se lo llama también “Sprint Final”, “Sprint de Entrega”, “Release Sprint”,

“Sprint de Estabilización” o “Cleaning Sprint”.

Los objetivos de este Sprint H dependen mucho del contexto del proyecto, pero en
general son uno, algunos o todos de los siguientes:

• Pruebas que no fueron ejecutadas previamente

• Corrección de defectos
• Refactoring
• Documentación para la entrega
• Capacitación/soporte a usuarios
• Armado final de la entrega

5.2 ENTREGABLES/RESULTADOS TÍPICOS

Típicamente durante el Sprint H se suelen generar algunos de los siguientes
entregables o resultados:

• Pruebas de Integración realizadas

• Pruebas de Sistema realizadas
• Pruebas de Regresión realizadas
• Pruebas de Performance realizadas
• Pruebas de Aceptación de Usuarios realizadas
• Pruebas Manuales realizadas
• Corrección de Defectos pendientes
• Refactoring, mejora y Depuración de Código y/o infraestructura
• Capacitación o soporte a usuarios finales
• Documentación Operativa de la Entrega
• Documentación de Usuarios
• Packaging de la entrega, Build Final, Scripts, etc.
• Piezas de Marketing
 pag. 16

• Comunicaciones de la Entrega

5.3 SOBRE EL USO DEL SPRINT H

El uso de un Sprint H es bastante polémico en la comunidad ágil.

Entre posibles aspectos negativos al respecto, se puede mencionar:

• Tener un Sprint H implica no terminar del todo el desarrollo de los ítems en el

Sprint “normal”, violando de alguna forma la definición de terminado de los
mismos. En consecuencia el avance que se registra en los sprints “normales” no
es un avance real, ya que se requiere las actividades del Sprint H para terminar
realmente los ítems involucrados.

• El Sprint H puede incorporar cierto ciclo cascada en el desarrollo de software,

ya que se realizan claramente ciertas actividades en bloque una vez terminadas
las otras en sprints “normales”, y por otro lado limita el feedback directo que se
recibe al final de cada sprint al no tener una versión terminada del producto.

Sin embargo se pueden destacar los siguientes argumentos a favor:

• En productos involucrando varios equipos de desarrollo, integrar y probar todo

en cada sprint “normal” puede ser imposible, o por lo menos no
rentable/beneficioso. En estos casos se recomienda integrar todo lo posible en
los sprints “normales” y usar un Sprint H para integraciones más
completas/complejas.
• A veces se acumulan muchos incidentes y se decide avanzar sin tomar el
tiempo de corregirlo en los sprints “normales” (lo cual no es una situación
óptima), es necesario tener un espacio (Sprint H) para terminar de corregir
incidentes acumulados.
• Cuando se requiere cierta documentación, que es muy volátil o podría cambiar
mucho durante la construcción en los sprints “normales”, puede resultar útil un
Sprint H donde se redacta la documentación final.
• Cuando el proceso de entrega es muy costoso (por ejemplo por temas
administrativos, técnicos, capacitaciones a muchos usuarios, etc.)se más que
recomendable juntar todas estas tareas en un Sprint H.

En conclusión, el Sprint H puede ser muy necesario en algunos contextos. Sin embargo
es importante tratar de reducir su duración cada vez más a medida que los
equipos/organizaciones puedan madurar, siendo el objetivo final entregar realmente
en cada sprint “normal”.

Más referencias:
 pag. 17

• https://www.scrum.org/Forums/aft/307
• http://www.mountaingoatsoftware.com/blog/correct-use-of-a-release-sprint
• http://www.leadingagile.com/2013/11/scrum-teams-release-sprint/
• http://swreflections.blogspot.com.ar/2013/01/hardening-sprints-what-are-
they-do-you.html
 pag. 18

6 ATERRIZAJE DE EMERGENCIA
6.1 DEFINICIÓN
¿Qué podemos hacer si en el medio del Sprint el equipo llega a la conclusión de que
no podrán entregar nada o muy poco al final del mismo?

Se requiere ejecutar el
Procedimiento de Aterrizaje
de Emergencia

Esfuerzo
Restante

El “Sprint Emergency Landing Procedure” (Procedimiento de Aterrizaje de Emergencia

de Sprint) es un procedimiento para intentar “recuperar” el Sprint lo más
tempranamente posible antes del fracaso o incluso cancelarlo si fuera necesario.

Jeff Sutherland recomienda al respecto:

1. Remover drásticamente impedimentos

Parar todo el trabajo y concentrar al equipo completo en analizar las causas raíces de
los atrasos e intentar innovar para evitar el fracaso. Sería una suerte de retrospectiva
de urgencia en el medio del sprint, con acciones de mejora drásticas a aplicar
enseguida.

2. Solicitar Ayuda
¿Es posible que alguien externo al equipo nos ayude? Pueden ser personal interno a la
empresa y/o empresas externas.

3. Reducir el alcance
 pag. 19

Re-priorizar y si es necesario quitar historias o requisitos fuera del Sprint. Intentar

terminar el Sprint en un estado “aceptable”. En todo caso es necesario acordar estas
acciones con el Dueño de Producto.

4. Cancelar el Sprint
El último recurso posible es simplemente abortar el Sprint actual e iniciar un nuevo
Sprint desde cero, tratando de ser lo más realista posible en su Planificación a la luz de
lo ocurrido.

6.2 ANTES DE CANCELAR UN SPRINT

Cancelar un Sprint es una acción que tiene un alto impacto en la motivación y moral
del equipo y puede ser un punto de cuestionamiento del proceso Scrum por parte del
equipo y/o de la organización.

Antes de tomar tan disruptiva acción, se sugiere que el equipo conteste honestamente
las siguientes preguntas (relacionadas con las acciones que vimos más arriba del
Procedimiento de Aterrizaje de Emergencia):

1. ¿Podemos cambiar algo en nuestra manera de trabajar?

2. ¿Realmente nadie externo puede ayudarnos?
3. ¿Podemos eliminar alguna historia o requisito del Sprint?

Si todas las respuestas anteriores, luego de un debido y detallado análisis, han sido
“no” entonces puede que la cancelación cobre sentido… después de todo no parece
haber otra alternativa mejor.

Más referencias:
• https://sites.google.com/a/scrumplop.org/published-patterns/product-
organization-pattern-language/emergency-procedure
 pag. 20

7 HERRAMIENTAS DE SOFTWARE PARA SCRUM

7.1 DEL USO DE LAS HERRAMIENTAS EN SCRUM

Se suele recomendar la adopción de Scrum con un Tablero de Tareas físico, por
ejemplo con un panel de corcho en la pared con post-its pegados en un lugar muy
visible. Algunas personas influyentes de la Comunidad Agile defienden fuertemente el
uso de los tableros físicos en contra de las herramientas de software4.

Si bien los tableros físicos tienen muchos beneficios para empezar la adopción de
Scrum, existen escenarios donde sus limitaciones hacen necesario el uso de una
herramienta de software, en formar combinada con el tablero físico o en forma única
cuando no hay alternativas. Es bastante típicos que un equipo empiece su camino con
Scrum usando un tablero físico, luego introduzca una planilla (Excel, o a veces Google
Docs para poder compartirla) y finalmente se decida con una herramienta más
integral. Suele ser una buena opción seguir estos pasos para que el equipo pueda
madurar en su implementación de Scrum antes de elegir una herramienta.

El uso de herramientas de software para Scrum, comparado con el uso de tableros

físicos, permite más fácilmente registrar alguna información adicional, tener backups,
trabajar con parte del equipo distribuido, contar con información histórica, integrar la
información de Backlog de Sprint con otras herramientas, sacar métricas e indicadores
de forma más automáticas, entre otros.

7.2 HERRAMIENTAS: ¿PARA QUÉ?

Esta sección está enfocada en herramientas de gestión para Scrum. Existen una
multitud de herramientas que soportan parte de las actividades de un proceso de
trabajo agile, y en particular para cubrir varios aspectos técnicos del desarrollo de
software, pero en este caso el foco está únicamente en herramienta de gestión, cuyo
alcance cubre principalmente el soporte a las ceremonias de Planificación y Reunión
Diaria, a través del manejo del Backlog de Producto y Backlog de Sprint/Tablero de
Tareas.

4
Por ejemplo Tobias Mayer en su libro “The People's Scrum: Agile Ideas for Revolutionary
Transformation”, o Daniel Markham en “Tyranny of the Tools”
 pag. 21

7.3 ALGUNAS CARACTERÍSTICAS A CONSIDERAR

Cada equipo u organización deberá elegir la herramienta a utilizar de acuerdo a sus
necesidades específicas. En este contexto algunas de las características siguientes
pueden ser decisivas en la elección:

• Licenciamiento: si la herramienta es paga o free. Varias herramientas

presentan versiones free con ciertas restricciones de uso (cantidad de usuarios,
cantidad de proyecto, plazo de uso, etc.).
• Hosting: algunas herramientas se pueden instalar en un servidor propio, otras
usan el hosting de la herramienta (cloud).
• Tipo: la mayoría de las herramientas se acceden via navegador web, pero
existen algunas herramientas desktop, y otras son plugins de otras suites de
herramientas que ofrecen otras prestaciones (como por ejemplo control de
versiones, manejo de pruebas e integración continua, en el caso de código de
software, etc.)
• Multiplicidad: algunas herramientas permiten manejar un solo proyecto y/o un
solo equipo, otras funcionan con múltiples proyectos y/o múltiples equipos.
• Tiempo Real: en caso de trabajar con equipos distribuidos, suele ser muy
importante que la herramienta se vaya actualizando en tiempo real para que se
pueda usar en un grupo distribuido y visualizar en el momento adecuado los
cambios que se estén haciendo en otra ubicación, sin restricciones graves de
performance.
• Especificidad: algunas herramientas están muy orientadas al desarrollo de
software, otras son más genéricas y se pueden usar para otras actividades.

7.4 LAS MÁS CONOCIDAS

A continuación se presenta una selección de posibles herramientas. Como no existe un
solo criterio universal de elección o evaluación de estas herramientas, es importante
aclarar que esta lista no es para nada exhaustiva, y el orden establecido es muy
subjetivo.

1. Trello (https://trello.com)
2. Ice Scrum (www.icescrum.org)
3. Target Process (www.targetprocess.com)
4. Rally (www.rallydev.com)
5. Pivotal tracker (www.pivotaltracker.com)
6. Atlassian (www.atlassian.com)
7. Version One (www.versionone.com)
8. ScrumWorks (www.collab.net/products/scrumworks)
9. ScrumDo (www.scrumdo.com)
10. Banana Scrum (http://www.bananascrum.com)
 pag. 22

8 ESCALANDO SCRUM
Existen cada vez más experiencias de implementación de Scrum en grupos de centenas
de personas, con múltiples equipos y/o distribuidos geográficamente (ver por ejemplo
la experiencia de Spotify5).

Entre los mecanismos más difundido para escalar Scrum, se puede destacar Scrum de
Scrums, y también algunos frameworks como Scaled Agile Framework (SAFe)6, Large
Scale Scrum (LeSS)7 , NEXUS8 o Scrum at Scale9.

8.1 SCRUM DE SCRUMS

Scrum de Scrums (a veces llamado Scrum of Scrums o también Meta Scrum) es una
técnica para escalar Scrum a equipos grandes (de 12 a cientos de miembros).

La manera de implementarlo puede variar, pero la idea general es dividir al equipo en

sub-equipos de menor cantidad de participantes. Cada sub-equipo cuenta con un
embajador que los representa como equipo en una Reunión Diaria llamada Scrum de
Scrums en donde se reúnen todos los embajadores. Dicha reunión debería ocurrir, si
fuera posible, luego de la reunión diaria de cada equipo.

Cabe aclarar que los embajadores pueden variar por equipo (algunos autores
sostienen que al final de la reunión diaria de cada equipo se define el embajador del
día, que es quien se encuentra en mejores condiciones de representar al equipo en la
reunión Scrum de Scrums según la situación actual). Además del embajador, los
equipos pueden decidir enviar otra persona, si lo consideran conveniente o necesario.

5
http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
6
http://scaledagileframework.com/
7
http://less.works/
8
https://www.scrum.org/resources/nexus-guide
9
http://www.scruminc.com/agile2014/
 pag. 23

La reunión Scrum de Scrums sigue la misma dinámica que una reunión diaria, es decir
que se reportan impedimentos, logros del equipo y próximos pasos, cada embajador
reporta “por su sub-equipo”. A su vez, el Scrum de Scrums mantiene su propio backlog
en donde se encuentran mayormente actividades de coordinación e integración entre
equipos (por ejemplo pruebas de integración). Se suele trabajar a un nivel de
abstracción mayor al de los sub-equipos.

8.2 DINÁMICA

Frecuencia y Duración

Scrum de Scrums (como reunión) puede o no tener una frecuencia diaria y puede o no
tener un timebox de 15 minutos. En general como regla heurística 2 o 3 veces por
semana para la reunión y no más de 45 minutos suelen ser suficientes.

Como siempre, las reuniones diarias NO deben emplearse para resolver bloqueos o
problemas, sino que ello debe tratarse en reuniones específicas de trabajo. Sin
embargo, para el caso de Scrum de Scrums y suponiendo que un inconveniente a este
nivel implica algo serio, si las personas que pueden tratar o resolver la situación están
presentes algunos autores recomiendan emplear la reunión para trabajar el problema
directamente. Esto último implica como buena práctica reservar un espacio adicional
de tiempo luego de la reunión.

Preguntas

Similarmente a una reunión diaria, las preguntas a responder en la reunión (agenda)

son las siguientes:

1. ¿Que completó tu equipo (sub equipo) desde la última vez que nos reunimos?
2. ¿Que completarán tu equipo hasta que volvamos a reunirnos?
 pag. 24

3. ¿Qué obstáculos existen para que tu equipo no pueda avanzar (en particular
que inconvenientes afectan o tienen relación con otros equipos)?
4. ¿Qué trabajo está tu equipo por enviar hacia otros equipos?

La última pregunta es realmente útil para coordinar el trabajo.

8.3 ESCALAMIENTO DE ROLES

Usar Scrum de Scrums suele requerir la implementación de nuevo roles: Dueño de
Producto General (Chief Product Owner) y Scrum Master General (Chief Scrum Master),
que con representantes de mayor jerarquía dentro de una estructura de Dueños de
Producto o Scrum Masters, respectivamente.

Dueño de Producto General

El Responsable de Dueños de Productos opera en un nivel superior a los Dueños de

Productos y es responsable de la coordinación de las definiciones finales del producto
y de la resolución de los conflictos entre Dueño de Producto.

Scrum Master General

El Responsable de Scrum Master opera en un nivel superior a los Scrum Masters, y:

• Actúa como promotor de mejora en el Scrum de Scrums

• Actúa como referente de Scrum al nivel organizacional y “desafía” el status quo
• Facilita las reuniones de Scrum de Scrums
 pag. 25

8.4 ESCALAMIENTO EN VARIOS NIVELES

Scrum de Scrums puede escalarse recursivamente. Es decir agrupando equipos
jerárquicamente con “Embajadores”. Gráficamente:

Cada Scrum de Scrums define su embajador para el nivel superior de Scrum de Scrums.

Existen infinitas variaciones del mecanismo de Scrum of Scrums, aglunas más exitosas
que otras. Recomendamos en particular las referencias siguientes:

• https://blog.crisp.se/2012/01/22/henrikkniberg/lean-from-the-trenches-managing-large-scale-projects-with-kanban
• http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

8.5 FRAMEWORKS PARA ESCALAR SCRUM

Últimamente surgieron varios farmeworks que definen patrones y mecanismos para
escalar a Scrum al nivel organizacional o en grupos grandes. En esta sección
presentamos brevemente los más conocidos/aceptados:
 pag. 26

SAFe - Scaled Agile Framework

• Resumen: SAFe define elementos de arquitectura, integración, gobierno, roles

y prácticas para escalar Agile y Lean desde el nivel de un equipo, a un nivel de
Programa o de Portafolio.
• Referente: Dean Leffingwell
• Link: http://scaledagileframework.com/

LeSS – Large Scale Scrum

• Resumen: LeSS es un conjunto de principios, experimentos y reglas que busca la

forma más simple y concreta posible de escalar los mecanismos de Scrum en
grupos grandes, respetando los mismos principios de Scrum en equipos chicos.
• Referente: Craig Larman y Bass Vodde
• Link: http://less.works/

Nexus

• Resumen: Nexus usa los mismos principios de Scrum para escalar hasta 9
equipos, con algunos roles y mecanismos específicos para integrar los equipos
alrededor de un único Backlog de Producto.
• Referente: Ken Schwaber (Scrum.org)
• Link: https://www.scrum.org/resources/nexus-guide

Scrum at Scale

• Resumen: Scrum at Scale es un enfoque modular en el cual se identifican

patrones para escalar Scrum que se pueden utilizar (o no) modularmente según
el contexto de la organización.
• Referente: Jeff Sutherland (Scrum Inc.)
• Link: http://www.scruminc.com/agile2014/

Más Referencias:
• https://vimeo.com/43956744 (James Shore - Kanban, Lean, and Large-Scale Agile)
• http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961 (Scaling Lean
& Agile Development: Thinking and Organizational Tools for Large-Scale Scrum – Craig
Larman y Bas Voode)
 pag. 27

9 COMUNIDADES Y CERTIFICACIONES
A continuación identificamos las principales comunidades que sostienen y difunden
Scrum, así como las principales certificaciones relacionadas.

9.1 COMUNIDADES

Scrum Alliance
www.scrumalliance.org

Es la organización más importante dentro del mundo de Scrum. Promueve Scrum a

través de eventos (Global Scrum Gatherings, Regional Scrum Gathernings, User Groups
Events), certificaciones (Certified Scrum Master, Certified Scrum Product Owner,
Certified Scrum Developper, Certified Scrum Coach, Certified Coach Trainner), grupos
de usuarios (por ejemplo el grupo de usuarios de Argentina10) y difusión de contenidos
relacionados con Scrum.

Scrum Manager
www.scrummanager.net

Es una Comunidad de Conocimiento Abierto para mejorar y ampliar el conocimiento

profesional de Scrum. Scrum Manager ofrece cursos, certificaciones y contenidos
relacionados con Scrum.

Comunidad Latinoamericana de Metodologías Agiles

www.agiles.org

Es una comunidad que articula las distintas comunidades latinoamericanas por país o
por ciudad. Se identifican en el sitio de la comunidad los distintos eventos según la
localidad (y algunos virtuales), y las redes disponibles (grupos de mails, redes sociales,
etc.)

9.2 CERTIFICACIONES
Destacamos a continuación las certificaciones más reconocidas en Scrum y
Metodologías Agiles:

10
http://members.Scrumalliance.org/user_groups/94
 pag. 28

• Certified Scrum Master (CSM) por la Scrum Alliance. Es una formación de dos
días provista por Certified Scrum Trainners (CST) habilitados por la Scrum
Alliance, validada a través de un examen online.

• Certified Scrum Product Owner (CSPO) por la Scrum Alliance. Es muy similar a
la CSM, pero más enfocada en el rol de Dueño de Producto.

• Professional Scrum Master (PSM) por Scrum.org. Es un examen online

bastante compleo y exigente sobre Scrum y el rol de Scrum Master.

• Agile Certified (ACP) por el Project Management Institue (PMI). Está

certificación abarca no solamente Scrum pero también la mayoría de las
metodologías agiles existentes (Lean, Kanban, XP). Define un Cuerpo de
Conocimiento compuestas de las más reconocidas practicas agiles existentes y
se valida a través de un examen formal. Existen varias formaciones disponibles
de preparación.
 pag. 29

10 CONCLUSIONES
En esta unidad se presentaron varias técnicas, prácticas y herramientas que suelen
complementar el marco de trabajo básico de Scrum, en particular en equipos con
Scrum Masters maduros.

Destacamos en esta maduración el rol específico de Scrum Master como agente de

cambio. Su rol es fundamental como acompañamiento de equipos a lo largo del
camino de la implementación de Scrum. Podemos mencionar en particular el Scrum
Master Checklist11 como fuente de inspiración para todos los Scrum Master que
realmente buscan la mejora continua para sus equipos…

11
http://www.scrummasterchecklist.org/