Curso:

SCRUM GRAND MASTER

pag. 2

Presentacin:
En esta unidad exploraremos tcnicas, prcticas 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:

Entendern herramientas, prcticas y tcnicas avanzadas
que complementan al Marco de Trabajo de Scrum.
Contarn con referencias para profundizar problemticas
avanzadas relacionadas con Scrum.
Contarn con elementos de ayuda y guas para el
crecimiento como Scrum Master y la implementacin de
Scrum.

pag. 5

Temario:

1. Introduccin
2. Duracin 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

Introduccin ............................................................................................................. 8

Definicin de la Duracin del Sprint ......................................................................... 9

2.1

Introduccin ....................................................................................................... 9

2.2

Eleccin por default ........................................................................................... 9

2.3

Aspectos a Considerar ....................................................................................... 9

2.4

Una Formula Posible ........................................................................................ 10

Sprint 0.................................................................................................................... 12
3.1

Definicin ......................................................................................................... 12

3.2

Entregables/Resultados Tpicos ....................................................................... 12

3.3

Sobre el Uso del Sprint 0 .................................................................................. 13

La 4ta Pregunta ....................................................................................................... 15

Sprint H ................................................................................................................... 16

5.1

Definicin ......................................................................................................... 16

5.2

Entregables/Resultados Tpicos ....................................................................... 16

5.3

Sobre el Uso del Sprint H ................................................................................. 17

Aterrizaje de Emergencia ....................................................................................... 19

6.1

Definicin ......................................................................................................... 19

6.2

Antes de cancelar un Sprint ............................................................................. 20

Herramientas de Software para Scrum .................................................................. 21

7.1

Del Uso de las Herramientas en Scrum ........................................................... 21

7.2

Herramientas: para Qu?............................................................................... 21

7.3

Algunas caractersticas a Considerar ............................................................... 21

7.4

Las ms conocidas............................................................................................ 22

Escalando Scrum ..................................................................................................... 23

8.1

Scrum de Scrums.............................................................................................. 23

8.2

Dinmica .......................................................................................................... 24

Frecuencia y Duracin ............................................................................................ 24

Preguntas ................................................................................................................ 24
8.3

Escalamiento de Roles ..................................................................................... 25

Dueo de Producto General ................................................................................... 25

Scrum Master General ............................................................................................ 25

pag. 7
8.4

Escalamiento en Varios Niveles ....................................................................... 26

8.5

Frameworks para Escalar Scrum ...................................................................... 26

SAFe - Scaled Agile Framework .............................................................................. 27

LeSS Large Scale Scrum ........................................................................................ 27
Scrum at Scale......................................................................................................... 27
9

Comunidades y Certificaciones .............................................................................. 28

9.1

Comunidades ................................................................................................... 28

Scrum Alliance ........................................................................................................ 28

Scrum Manager ...................................................................................................... 28
Comunidad Latinoamericana de Metodologas Agiles ........................................... 28
9.2

Certificaciones.................................................................................................. 28

10 Conclusiones ........................................................................................................... 30

pag. 8

1 INTRODUCCIN
En esta unidad presentamos algunas tcnicas, prcticas y herramientas que suelen
complementar el marco de trabajo bsico de Scrum, en particular en equipos con
Scrum Masters maduros. Cabe aclarar que seleccionamos las tcnicas, prcticas y
herramientas ms relevantes/difundidas, ya que la lista podra ser muy larga y/o con
elementos de poco uso, poca calidad o poca relevancia.
En las distintas secciones recorremos estas tcnicas, prcticas y herramientas en el
orden que suele seguir un proyecto. Este recorrido empieza por la definicin inicial de
la duracin del Sprint (Seccin 2). Repasaremos algunos Sprints especiales: Sprint 0 y
Sprint H (Secciones Sprint 03 y 5). Introduciremos una tcnica adicional para
mejorar la ceremonia de Reunin Diaria (Seccin 4). Veremos los casos extremos de
cancelacin de Sprint (Seccin 6), y el uso de herramientas de software para Scrum
(Seccin 7). Cerraremos este recorrido con mecanismo para escalar Scrum en equipos
(muy) grandes (Seccin 8). En la ltima seccin (Seccin 9) enumeramos las principales
comunidades y certificaciones que pueden ser de mucha utilidad en el inicio y a lo
largo del camino de implementacin de Scrum.
No es necesario leer el material en el orden, cada seccin es relativamente
independiente de las otras.

pag. 9

2 DEFINICIN DE LA DURACIN DEL SPRINT

2.1 INTRODUCCIN
La duracin 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 duracin de los Sprints. Scrum promueve Sprints de entre 1 a 4 semanas, y
elegir entre estas opciones es un paso esencial.

2.2 ELECCIN POR DEFAULT

Para un equipo que empieza con Scrum, suele ser difcil la eleccin de la duracin del
Sprint por falta de contexto y elementos de decisin.
En estos casos es bastante comn empezar con la duracin ms difundida: 2 semanas
(o 10 das hbiles).
La recomendacin es ejecutar por lo menos 6 sprints con esta duracin, para poder
incorporar y probar bien el marco de trabajo de Scrum, y luego reflexionar sobre si
esta duracin es adecuada o si es necesario adecuarla (por ejemplo en la ceremonia de
Retrospectiva del Sprint 6).
En casos de buscar una eleccin de la duracin del Sprint ms elaborada, vamos a
ampliar algunos elementos de definicin

2.3 ASPECTOS A CONSIDERAR

Recomendamos tener en cuenta las siguientes consideraciones al elegir la duracin del
Sprint:

Presin sobre el equipo: un sprint corto deja poco margen para recuperar atrasos
en caso de problema, y eso suele generar presin en el equipo. Un sprint largo
puede generar tambin presin 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 (das no laborales, vacaciones, licencias, enfermedades).

pag. 10

Esfuerzo Ceremonias: si bien las ceremonias suelen ser ms cortas, el esfuerzo de

las ceremonias no es del todo proporcional a su duracin. En consecuencia, en
sprints cortos, se suele dedicar ms proporcin del esfuerzo del Equipo a las
ceremonias.

Trabajo en Curso: en sprints largo, se abarca ms 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, situacin por la cual en Sprints de mayor duracin se
cuenta con menor flexibilidad. Por ejemplo s el sprint dura 4 semanas, el peor caso
sera tener que esperar 4 semanas para introducir un cambio.

2.4 UNA FORMULA POSIBLE

A nivel ms cuantitativo la siguiente es una frmula matemtica propuesta por Erik
Verheu para calcular la duracin ptima de un Sprint:
Q: Duracin del Sprint (Calculada en das)
D: Duracin del proyecto estipulada (en das)
S: Costo fijo por Sprint (sprint planning + retrospective + review + tests, en das)
h: Riesgo del Proyecto calculado por cantidad Sprints que pueden fallar (en cantidad
de Sprints)
f: Costo variable del proyecto por da (costo por da)
p: Costo del proyecto (prdida) como consecuencia de no entregar a tiempo

Dnde:
Ejemplo:
D = 200 dias
S = 3 dias
h = 1 Sprint
f = $ 10000
p = $ 5000
Q= 20 das, sera la duracin optima del Sprint.
De todo modo, si bien esta frmula puede ser til para calcular la duracin inicial del
sprint, como decamos previamente, se recomienda probar por lo menos 6 sprints con
esta duracin calculada, y luego revisar (por ejemplo en la Retrospectiva) si es

pag. 11
conveniente o si es necesario probar otra duracin. Repetir este proceso hasta
encontrar la duracin ptima.

pag. 12

3 SPRINT 0
3.1 DEFINICIN
Un Sprint 0 es un sprint de preparacin que ocurre antes de los Sprints normales en
los cuales se entrega un producto con valor al cliente. A veces se lo llama tambin
Inception Sprint, Sprint de Incepcin, o Iteracin Cero.
El propsito 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 tecnolgicos, metodolgicos 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 logsticos de los sprints (Duracin, Ceremonias, etc.)
Comunicar el inicio del proyecto (Kick-Off)
Resolver aspectos tcnicos que generan mucha incertidumbre y puedan tener
gran impacto en el proyecto
Definir la Visin del Proyecto

3.2 ENTREGABLES/RESULTADOS TPICOS

Tpicamente durante el Sprint 0 se suelen generar algunos de los siguientes
entregables o resultados:

Definicin 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
Reunin de Kick-Off (Lanzamiento) realizada
Documentacin inicial del producto/proyecto2
Visin del producto/proyecto3

Ver por ejemplo la notacin ScrUML: http://blog.crisp.se/2007/08/25/henrikkniberg/1187995980000

Ver por ejemplo la tcnica de Visual Story Mapping:
http://agileproductdesign.com/presentations/user_story_mapping/index.html
2

pag. 13

Resultados de Pruebas Tcnicas

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 travs del
feedback de su uso.
La principal recomendacin sera de intentar evitar el Sprint 0, tratando de incorporar
sus actividades a los primeros sprints normales, en los cuales si se debera buscar la
entrega de valor al negocio a travs de un producto funcionando, aunque sea muy
limitado y de alcance reducido.
En caso de no poder evitar el Sprint 0, la recomendacin es que sea lo ms corto
posible, del orden de 1 a 4 semanas como gran mximo.
Y, por supuesto, hacer que este Sprint Cero sea lo ms 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 documentacin para validar el inicio de un
proyecto.
La gestin 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, quizs 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 tcnica Impact Mapping: http://www.impactmapping.org/

pag. 14
nuevos conocimientos sobre el producto y su arquitectura, teniendo un conocimiento
ms claro sobre sus ventajas, los problemas tcnicos a resolver, las herramientas de
trabajo necesarias, como organizarse, etc.

pag. 15

4 LA 4TA PREGUNTA
A medida que el equipo avance en su implementacin de las prcticas de Scrum, y en
particular de la ceremonia de Reunin Diaria, se puede aprovechar estas reuniones
para implementar algunos cambios avanzados.
Muchos autores sugieren aprovechar an ms el espacio de tiempo y comunicacin de
las reuniones diarias para compartir ms informacin entre el Equipo.
Concretamente, se sugiere agregar una cuarta pregunta a las tres preguntas clsicas de
la Reunin Diaria:
1. Cul fue mi avance desde la ltima Reunin Diaria?
2. En cuales tareas me comprometo a trabajar hasta la prxima Reunin Diaria?
3. Qu problemas tengo que me frenan o bloquean?
Algunas de las ms utilizadas como cuarta pregunta son las siguientes:

Cul 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 reunin diaria que el equipo debera conocer?
Qu fue una sorpresa ayer?
Qu tan til es esta reunin para vos?
Ests contento con lo que hay que hacer hoy?
Necesitas ayuda de alguien?

pag. 16

5 SPRINT H
5.1 DEFINICIN
El Sprint H (H=Hardening=Endurecimiento) es un sprint particular, enfocado en
ponerse al da con deuda tcnica acumulada en sprints anteriores, en robustecer y
mejorar tcnicamente 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 (tpicamente luego de 4 a 10 sprints) y antes de una entrega (importante).
A veces se lo llama tambin Sprint Final, Sprint de Entrega, Release Sprint,
Sprint de Estabilizacin 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

Correccin de defectos
Refactoring
Documentacin para la entrega
Capacitacin/soporte a usuarios
Armado final de la entrega

5.2 ENTREGABLES/RESULTADOS TPICOS

Tpicamente durante el Sprint H se suelen generar algunos de los siguientes
entregables o resultados:

Pruebas de Integracin realizadas

Pruebas de Sistema realizadas
Pruebas de Regresin realizadas
Pruebas de Performance realizadas
Pruebas de Aceptacin de Usuarios realizadas
Pruebas Manuales realizadas
Correccin de Defectos pendientes
Refactoring, mejora y Depuracin de Cdigo y/o infraestructura
Capacitacin o soporte a usuarios finales
Documentacin Operativa de la Entrega
Documentacin de Usuarios
Packaging de la entrega, Build Final, Scripts, etc.
Piezas de Marketing

pag. 17

Comunicaciones de la Entrega

5.3 SOBRE EL USO DEL SPRINT H

El uso de un Sprint H es bastante polmico 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 definicin 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 versin 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 ms
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 situacin
ptima), es necesario tener un espacio (Sprint H) para terminar de corregir
incidentes acumulados.
Cuando se requiere cierta documentacin, que es muy voltil o podra cambiar
mucho durante la construccin en los sprints normales, puede resultar til un
Sprint H donde se redacta la documentacin final.
Cuando el proceso de entrega es muy costoso (por ejemplo por temas
administrativos, tcnicos, capacitaciones a muchos usuarios, etc.)se ms que
recomendable juntar todas estas tareas en un Sprint H.

En conclusin, el Sprint H puede ser muy necesario en algunos contextos. Sin embargo
es importante tratar de reducir su duracin cada vez ms a medida que los
equipos/organizaciones puedan madurar, siendo el objetivo final entregar realmente
en cada sprint normal.
Ms referencias:

pag. 18

http://www.agilerecord.com/hardening-sprints/
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-arethey-do-you.html

pag. 19

6 ATERRIZAJE DE EMERGENCIA
6.1 DEFINICIN
Qu podemos hacer si en el medio del Sprint el equipo llega a la conclusin de que
no podrn 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 ms
tempranamente posible antes del fracaso o incluso cancelarlo si fuera necesario.
Jeff Sutherland recomienda al respecto:
1. Remover drsticamente impedimentos
Parar todo el trabajo y concentrar al equipo completo en analizar las causas races de
los atrasos e intentar innovar para evitar el fracaso. Sera una suerte de retrospectiva
de urgencia en el medio del sprint, con acciones de mejora drsticas 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. 20
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 Dueo 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 ms realista posible en su Planificacin a la luz de
lo ocurrido.

6.2 ANTES DE CANCELAR UN SPRINT

Cancelar un Sprint es una accin que tiene un alto impacto en la motivacin y moral
del equipo y puede ser un punto de cuestionamiento del proceso Scrum por parte del
equipo y/o de la organizacin.
Antes de tomar tan disruptiva accin, se sugiere que el equipo conteste honestamente
las siguientes preguntas (relacionadas con las acciones que vimos ms 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 anlisis, han sido
no entonces puede que la cancelacin cobre sentido despus de todo no parece
haber otra alternativa mejor.
Ms referencias:
https://sites.google.com/a/scrumplop.org/published-patterns/productorganization-pattern-language/emergency-procedure

pag. 21

7 HERRAMIENTAS DE SOFTWARE PARA SCRUM

7.1 DEL USO DE LAS HERRAMIENTAS EN SCRUM
Se suele recomendar la adopcin de Scrum con un Tablero de Tareas fsico, 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 fsicos en contra de las herramientas de software4.
Si bien los tableros fsicos tienen muchos beneficios para empezar la adopcin de
Scrum, existen escenarios donde sus limitaciones hacen necesario el uso de una
herramienta de software, en formar combinada con el tablero fsico o en forma nica
cuando no hay alternativas. Es bastante tpicos que un equipo empiece su camino con
Scrum usando un tablero fsico, luego introduzca una planilla (Excel, o a veces Google
Docs para poder compartirla) y finalmente se decida con una herramienta ms
integral. Suele ser una buena opcin seguir estos pasos para que el equipo pueda
madurar en su implementacin de Scrum antes de elegir una herramienta.
El uso de herramientas de software para Scrum, comparado con el uso de tableros
fsicos, permite ms fcilmente registrar alguna informacin adicional, tener backups,
trabajar con parte del equipo distribuido, contar con informacin histrica, integrar la
informacin de Backlog de Sprint con otras herramientas, sacar mtricas e indicadores
de forma ms automticas, entre otros.

7.2 HERRAMIENTAS: PARA QU?

Esta seccin est enfocada en herramientas de gestin 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 tcnicos del desarrollo de
software, pero en este caso el foco est nicamente en herramienta de gestin, cuyo
alcance cubre principalmente el soporte a las ceremonias de Planificacin y Reunin
Diaria, a travs del manejo del Backlog de Producto y Backlog de Sprint/Tablero de
Tareas.

7.3 ALGUNAS CARACTERSTICAS A CONSIDERAR

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
http://www.whattofix.com/blog/archives/2011/12/tyranny-of-the-1.php

pag. 22
Cada equipo u organizacin deber elegir la herramienta a utilizar de acuerdo a sus
necesidades especficas. En este contexto algunas de las caractersticas siguientes
pueden ser decisivas en la eleccin:

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 mayora 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 integracin continua, en el caso de cdigo de
software, etc.)
Multiplicidad: algunas herramientas permiten manejar un solo proyecto y/o un
solo equipo, otras funcionan con mltiples proyectos y/o mltiples 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 estn haciendo en otra ubicacin, sin restricciones graves de
performance.
Especificidad: algunas herramientas estn muy orientadas al desarrollo de
software, otras son ms genricas y se pueden usar para otras actividades.

7.4 LAS MS CONOCIDAS

A continuacin se presenta una seleccin de posibles herramientas. Como no existe un
solo criterio universal de eleccin o evaluacin 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. 23

8 ESCALANDO SCRUM
Existen cada vez ms experiencias de implementacin de Scrum en grupos de centenas
de personas, con mltiples equipos y/o distribuidos geogrficamente (ver por ejemplo
las experiencias de Spotify5, Yahoo6).
Entre los mecanismos ms difundido para escalar Scrum, se puede destacar Scrum de
Scrums, y tambin algunos frameworks como Scaled Agile Framework (SAFe)7, Large
Scale Scrum (LeSS)8 o Scrum at Scale9.

8.1 SCRUM DE SCRUMS

Scrum de Scrums (a veces llamado Scrum of Scrums o tambin Meta Scrum) es una
tcnica 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 Reunin Diaria llamada Scrum de
Scrums en donde se renen todos los embajadores. Dicha reunin debera ocurrir, si
fuera posible, luego de la reunin diaria de cada equipo.
Cabe aclarar que los embajadores pueden variar por equipo (algunos autores
sostienen que al final de la reunin diaria de cada equipo se define el embajador del
da, que es quien se encuentra en mejores condiciones de representar al equipo en la
reunin Scrum de Scrums segn la situacin actual). Adems del embajador, los
equipos pueden decidir enviar otra persona, si lo consideran conveniente o necesario.

http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
http://www.computer.org/csdl/proceedings/hicss/2008/3075/00/30750461.pdf
7
http://scaledagileframework.com/
8
http://less.works/
9
http://www.scruminc.com/agile2014/
6

pag. 24

La reunin Scrum de Scrums sigue la misma dinmica que una reunin diaria, es decir
que se reportan impedimentos, logros del equipo y prximos 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 coordinacin e integracin entre
equipos (por ejemplo pruebas de integracin). Se suele trabajar a un nivel de
abstraccin mayor al de los sub-equipos.

8.2 DINMICA
Frecuencia y Duracin
Scrum de Scrums (como reunin) puede o no tener una frecuencia diaria y puede o no
tener un timebox de 15 minutos. En general como regla heurstica 2 o 3 veces por
semana para la reunin y no ms 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 especficas 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 situacin estn
presentes algunos autores recomiendan emplear la reunin para trabajar el problema
directamente. Esto ltimo implica como buena prctica reservar un espacio adicional
de tiempo luego de la reunin.

Preguntas
Similarmente a una reunin diaria, las preguntas a responder en la reunin (agenda)
son las siguientes:
1. Que complet tu equipo (sub equipo) desde la ltima vez que nos reunimos?
2. Que completarn tu equipo hasta que volvamos a reunirnos?

pag. 25
3. Qu obstculos existen para que tu equipo no pueda avanzar (en particular
que inconvenientes afectan o tienen relacin 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 implementacin de nuevo roles: Dueo de
Producto General (Chief Product Owner) y Scrum Master General (Chief Scrum Master),
que con representantes de mayor jerarqua dentro de una estructura de Dueos de
Producto o Scrum Masters, respectivamente.

Dueo de Producto General

El Responsable de Dueos de Productos opera en un nivel superior a los Dueos de
Productos y es responsable de la coordinacin de las definiciones finales del producto
y de la resolucin de los conflictos entre Dueo de Producto.

Scrum Master General

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

Acta como promotor de mejora en el Scrum de Scrums

Acta como referente de Scrum al nivel organizacional y desafia el status quo
Facilita las reuniones de Scrum de Scrums

pag. 26

8.4 ESCALAMIENTO EN VARIOS NIVELES

Scrum de Scrums puede escalarse recursivamente. Es decir agrupando equipos
jerrquicamente con Embajadores. Grficamente:

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 ms exitosas

que otras. Recomendamos en particular las referencias siguientes:

https://www.crisp.se/file-uploads/Lean-from-the-trenches.pdf
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 seccin
presentamos brevemente los ms conocidos/aceptados:

pag. 27

SAFe - Scaled Agile Framework

Resumen: SAFe define elementos de arquitectura, integracin, gobierno, roles

y prcticas 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 ms 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/

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 segn
el contexto de la organizacin.
Referente: Jeff Sutherland (Scrum Inc.)
Link: http://www.scruminc.com/agile2014/

Ms 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. 28

9 COMUNIDADES Y CERTIFICACIONES
A continuacin 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 organizacin ms importante dentro del mundo de Scrum. Promueve Scrum a

travs 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 difusin 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 Metodologas Agiles

www.agiles.org

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

9.2 CERTIFICACIONES
Destacamos a continuacin las certificaciones ms reconocidas en Scrum y
Metodologas Agiles:

10

http://members.Scrumalliance.org/user_groups/94

pag. 29

11

Certified Scrum Master (CSM) por la Scrum Alliance. Es una formacin de dos
das provista por Certified Scrum Trainners (CST) habilitados por la Scrum
Alliance, validada a travs de un examen online.

Certified Scrum Product Owner (CSPO) por la Scrum Alliance. Es muy similar a
la CSM, pero ms enfocada en el rol de Dueo de Producto.

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

certificacin abarca no solamente Scrum pero tambin la mayora de las
metodologas agiles existentes (Lean, Kanban, XP). Define un Cuerpo de
Conocimiento compuestas de las ms reconocidas practicas agiles existentes y
se valida a travs de un examen formal. Existen varias formaciones disponibles
de preparacin11.

Por
ejemplo:
http://www.sceu.frba.utn.edu.ar/e-learning/cursos-a-distancia/ProjectManagement/Curso-de-Gestion-Agil-de-Proyectos-%28PMI-ACP%29/temario.html

pag. 30

10 CONCLUSIONES
En esta unidad se presentaron varias tcnicas, prcticas y herramientas que suelen
complementar el marco de trabajo bsico de Scrum, en particular en equipos con
Scrum Masters maduros.
Destacamos en esta maduracin el rol especfico de Scrum Master como agente de
cambio. Su rol es fundamental como acompaamiento de equipos a lo largo del
camino de la implementacin de Scrum. Podemos mencionar en particular el Scrum
Master Checklist12 como fuente de inspiracin para todos los Scrum Master que
realmente buscan la mejora continua para sus equipos

12

http://www.scrummasterchecklist.org/