u3.herramientas avanzadas para scrum

7/23/2019 U3.Herramientas Avanzadas Para Scrum

http://slidepdf.com/reader/full/u3herramientas-avanzadas-para-scrum 1/30

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 avanzadasque 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 elcrecimiento como Scrum Master y la implementación deScrum.



pag. 5

Temario:

1. Introducción2. Duración del Sprint3. Sprint 0

4. La 4ta Pregunta5. Sprint H6. Aterrizaje de Emergencia7. Herramientas de Software para Scrum8. Escalando Scrum9. Comunidades y Certificaciones10. 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

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

3 Sprint 0.................................................................................................................... 12

3.1 Definición ......................................................................................................... 12

3.2 Entregables/Resultados Típicos ....................................................................... 12

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

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

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

5.1 Definición ......................................................................................................... 16

5.2 Entregables/Resultados Típicos ....................................................................... 16

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

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

6.1 Definición ......................................................................................................... 19 6.2 Antes de cancelar un Sprint ............................................................................. 20

7 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 características a Considerar ............................................................... 21

7.4 Las más conocidas ............................................................................................ 22

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

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

8.2 Dinámica .......................................................................................................... 24

Frecuencia y Duración ............................................................................................ 24

Preguntas ................................................................................................................ 24

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

Dueño 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 Metodologías Agiles ........................................... 28

9.2 Certificaciones .................................................................................................. 28

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



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 conScrum Masters maduros. Cabe aclarar que seleccionamos las técnicas, prácticas yherramientas más relevantes/difundidas, ya que la lista podría ser muy larga y/o conelementos de poco uso, poca calidad o poca relevancia.

En las distintas secciones recorremos estas técnicas, prácticas y herramientas en elorden que suele seguir un proyecto. Este recorrido empieza por la definición inicial dela duración del Sprint (Sección 2). Repasaremos algunos Sprints especiales: Sprint 0 y

Sprint H (Secciones Sprint 03 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 principalescomunidades y certificaciones que pueden ser de mucha utilidad en el inicio y a lolargo del camino de implementación de Scrum.

No es necesario leer el material en el orden, cada sección es relativamenteindependiente 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 losSprints. No existen excusas para extender o modificar. Como vimos previamente, eltime-boxing es una de los valores fundacionales de Scrum.

Una de las primeras definiciones a tomar cuando se implementa Scrum es justamenteelegir la duración de los Sprints. Scrum promueve Sprints de entre 1 a 4 semanas, yelegir 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 delSprint 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 poderincorporar 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 deRetrospectiva del Sprint 6).

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

2.3 ASPECTOS A CONSIDERAR

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

Presión sobre el equipo: un sprint corto deja poco margen para recuperar atrasosen caso de problema, y eso suele generar presión en el equipo. Un sprint largopuede 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 tieneun impacto significativo (días no laborales, vacaciones, licencias, enfermedades).



pag. 10

Esfuerzo Ceremonias: si bien las ceremonias suelen ser más cortas, el esfuerzo delas ceremonias no es del todo proporcional a su duración. En consecuencia, ensprints 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 mayorriesgo que surjan problemas en alguno de ellos, y a veces con un costo adicional deesfuerzo por pasar de un ítem a otro (switch).

Flexibilidad al Cambio: Recordemos que no se introducen cambios o nuevosrequisitos durante el Sprint, situación por la cual en Sprints de mayor duración secuenta con menor flexibilidad. Por ejemplo s el sprint dura 4 semanas, el peor casosería tener que esperar 4 semanas para introducir un cambio.

2.4 UNA FORMULA POSIBLE A nivel más cuantitativo la siguiente es una fórmula matemática propuesta por Erik

Verheu para calcular la duración óptima de un Sprint:

Q: Duración del Sprint (Calculada en días)D: Duración del proyecto estipulada (en días)S: Costo “fijo” por Sprint (sprint planning + retrospective + review + tests, en días) h: Riesgo del Proyecto calculado por cantidad Sprints que pueden fallar (en cantidad

de Sprints)f: Costo “variable” del proyecto por día (costo por día) p: Costo del proyecto (pérdida) como consecuencia de no entregar a tiempo

Dónde:

Ejemplo:D = 200 dias

S = 3 diash = 1 Sprintf = $ 10000p = $ 5000Q= 20 días, sería la duración optima del Sprint.

De todo modo, si bien esta fórmula puede ser útil para calcular la duración inicial delsprint, como decíamos previamente, se recomienda probar por lo menos 6 sprints conesta duración calculada, y luego revisar (por ejemplo en la Retrospectiva) si es



pag. 11

conveniente o si es necesario probar otra duración. Repetir este proceso hastaencontrar la duración óptima.



pag. 12

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 enun Sprint particular donde puede no haber una entrega de un producto de valor parael cliente. Se suele preparar el proyecto en aspectos tecnológicos, metodológicos yorganizativos.

Los objetivos de este Sprint 0 dependen mucho del contexto del proyecto, pero engeneral 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 tenergran impacto en el proyecto

Definir la Visión del Proyecto

3.2 ENTREGABLES/RESULTADOS TÍPICOSTípicamente durante el Sprint 0 se suelen generar algunos de los siguientesentregables 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 Visual Story Mapping:

http://agileproductdesign.com/presentations/user_story_mapping/index.html

http://blog.crisp.se/2007/08/25/henrikkniberg/1187995980000









pag. 13

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 esque se haga todo un pre-proyecto largo sin entrega directa al negocio, y enconsecuencia con pocas oportunidades de aprender sobre el producto a través delfeedback de su uso.

La principal recomendación sería de intentar evitar el Sprint 0, tratando de incorporarsus 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 cortoposible, 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 ladificultad de implementar los principios y valores de la agilidad, como por ejemplo:

Las decisiones importantes se deben tomar antes de iniciar el proyecto, lo cualrefleja que no se deja espacio a que ciertos aspectos del producto vayanemergiendo y cambiando a partir del feedback y del descubrimiento que sehace 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 cualesempezar.

Se requiere mucha burocracia y documentación para validar el inicio de unproyecto.

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 devalor para el negocio permita resolver algunos de estos problemas, descubriendo

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

http://www.impactmapping.org/






pag. 14

nuevos conocimientos sobre el producto y su arquitectura, teniendo un conocimientomás claro sobre sus ventajas, los problemas técnicos a resolver, las herramientas detrabajo necesarias, como organizarse, etc.



pag. 15

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 reunionespara implementar algunos cambios avanzados.

Muchos autores sugieren aprovechar aún más el espacio de tiempo y comunicación delas reuniones diarias para compartir más información entre el Equipo.

Concretamente, se sugiere agregar una cuarta pregunta a las tres preguntas clásicas dela 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 locomprometido 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. 16

5

SPRINT H

5.1 DEFINICIÓN

El Sprint H (H=Hardening=Endurecimiento) es un sprint particular, enfocado enponerse al día con deuda técnica acumulada en sprints anteriores, en robustecer ymejorar técnicamente el producto y en el armado final de la entrega del productodesarrollado 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 engeneral 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 siguientesentregables 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. 17

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 elSprint “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 terminarrealmente 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 terminadaslas 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 todoen cada sprint “normal” puede ser imposible, o por lo menos no

rentable/beneficioso. En estos casos se recomienda integrar todo lo posible enlos sprints “normales” y usar un Sprint H para integraciones máscompletas/complejas.

A veces se acumulan muchos incidentes y se decide avanzar sin tomar eltiempo de corregirlo en los sprints “normales” (lo cual no es una situación

óptima), es necesario tener un espacio (Sprint H) para terminar de corregirincidentes acumulados.

Cuando se requiere cierta documentación, que es muy volátil o podría cambiarmucho 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 temasadministrativos, técnicos, capacitaciones a muchos usuarios, etc.)se más querecomendable juntar todas estas tareas en un Sprint H.

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

Más 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-are-they-do-you.html



https://www.scrum.org/Forums/aft/307


http://www.mountaingoatsoftware.com/blog/correct-use-of-a-release-sprint

















pag. 19

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?

El “Sprint Emergency Landing Procedure” (Procedimiento de Aterrizaje de Emergenciade Sprint) es un procedimiento para intentar “recuperar” el Sprint lo mástempranamente posible antes del fracaso o incluso cancelarlo si fuera necesario.

Jeff Sutherland recomienda al respecto:

1. Remover drásticamente impedimentosParar todo el trabajo y concentrar al equipo completo en analizar las causas raíces delos 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 aplicarenseguida.

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

3. Reducir el alcance

EsfuerzoRestante

Se requiere ejecutar elProcedimiento de Aterrizajede Emergencia



pag. 20

Re-priorizar y si es necesario quitar historias o requisitos fuera del Sprint. Intentarterminar el Sprint en un estado “aceptable”. En todo caso es necesario acordar estasacciones con el Dueño de Producto.

4.

Cancelar el SprintEl último recurso posible es simplemente abortar el Sprint actual e iniciar un nuevoSprint desde cero, tratando de ser lo más realista posible en su Planificación a la luz delo 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 moraldel 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 honestamentelas siguientes preguntas (relacionadas con las acciones que vimos más arriba delProcedimiento 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. 21

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, porejemplo con un panel de corcho en la pared con post-its pegados en un lugar muyvisible. Algunas personas influyentes de la Comunidad Agile defienden fuertemente eluso 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 deScrum, 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 únicacuando no hay alternativas. Es bastante típicos que un equipo empiece su camino conScrum usando un tablero físico, luego introduzca una planilla (Excel, o a veces GoogleDocs para poder compartirla) y finalmente se decida con una herramienta másintegral. Suele ser una buena opción seguir estos pasos para que el equipo puedamadurar en su implementación de Scrum antes de elegir una herramienta.

El uso de herramientas de software para Scrum, comparado con el uso de tablerosfí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 lainformación de Backlog de Sprint con otras herramientas, sacar métricas e indicadoresde forma más automáticas, entre otros.

7.2 HERRAMIENTAS: ¿PARA Q UÉ?

Esta sección está enfocada en herramientas de gestión para Scrum. Existen unamultitud de herramientas que soportan parte de las actividades de un proceso detrabajo agile, y en particular para cubrir varios aspectos técnicos del desarrollo desoftware, 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ónDiaria, a través del manejo del Backlog de Producto y Backlog de Sprint/Tablero deTareas.

7.3 ALGUNAS CARACTERÍSTICAS 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 organización deberá elegir la herramienta a utilizar de acuerdo a susnecesidades específicas. En este contexto algunas de las características siguientespueden ser decisivas en la elección:

Licenciamiento: si la herramienta es paga o free. Varias herramientaspresentan 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, otrasusan el hosting de la herramienta (cloud).

Tipo: la mayoría de las herramientas se acceden via navegador web, peroexisten algunas herramientas desktop, y otras son plugins de otras suites deherramientas que ofrecen otras prestaciones (como por ejemplo control deversiones, manejo de pruebas e integración continua, en el caso de código desoftware, etc.)

Multiplicidad: algunas herramientas permiten manejar un solo proyecto y/o unsolo equipo, otras funcionan con múltiples proyectos y/o múltiples equipos.

Tiempo Real: en caso de trabajar con equipos distribuidos, suele ser muyimportante que la herramienta se vaya actualizando en tiempo real para que sepueda usar en un grupo distribuido y visualizar en el momento adecuado loscambios que se estén haciendo en otra ubicación, sin restricciones graves deperformance.

Especificidad: algunas herramientas están muy orientadas al desarrollo desoftware, 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 unsolo criterio universal de elección o evaluación de estas herramientas, es importanteaclarar que esta lista no es para nada exhaustiva, y el orden establecido es muysubjetivo.

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)

https://trello.com/

https://trello.com/

https://trello.com/

http://www.icescrum.org/



http://www.targetprocess.com/



http://www.rallydev.com/



http://www.pivotaltracker.com/



http://www.atlassian.com/



http://www.versionone.com/



http://www.collab.net/products/scrumworks



http://www.scrumdo.com/



http://www.bananascrum.com/












https://trello.com/



pag. 23

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 ejemplolas experiencias de Spotify

5, Yahoo6).

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)7 , Large

Scale Scrum (LeSS)8 o Scrum at Scale

9.

8.1 SCRUM DE SCRUMS

Scrum de Scrums (a veces llamado Scrum of Scrums o también Meta Scrum) es unaté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 ensub-equipos de menor cantidad de participantes. Cada sub-equipo cuenta con unembajador 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, sifuera posible, luego de la reunión diaria de cada equipo.

Cabe aclarar que los embajadores pueden variar por equipo (algunos autoressostienen que al final de la reunión diaria de cada equipo se define el embajador deldía, que es quien se encuentra en mejores condiciones de representar al equipo en lareunión Scrum de Scrums según la situación actual). Además del embajador, losequipos 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://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/

http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify



http://www.computer.org/csdl/proceedings/hicss/2008/3075/00/30750461.pdf



http://scaledagileframework.com/



http://less.works/

http://less.works/

http://less.works/

http://www.scruminc.com/agile2014/




http://less.works/






pag. 24

La reunión Scrum de Scrums sigue la misma dinámica que una reunión diaria, es decirque se reportan impedimentos, logros del equipo y próximos pasos, cada embajadorreporta “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 entreequipos (por ejemplo pruebas de integración). Se suele trabajar a un nivel deabstracció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 notener un timebox de 15 minutos. En general como regla heurística 2 o 3 veces porsemana 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 oproblemas, sino que ello debe tratarse en reuniones específicas de trabajo. Sinembargo, para el caso de Scrum de Scrums y suponiendo que un inconveniente a estenivel implica algo serio, si las personas que pueden tratar o resolver la situación estánpresentes algunos autores recomiendan emplear la reunión para trabajar el problema

directamente. Esto último implica como buena práctica reservar un espacio adicionalde 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. 25

3. ¿Qué obstáculos existen para que tu equipo no pueda avanzar (en particularque 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 deProducto 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 deProducto 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 deProductos y es responsable de la coordinación de las definiciones finales del productoy 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 “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 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 exitosasque 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 paraescalar a Scrum al nivel organizacional o en grupos grandes. En esta secciónpresentamos brevemente los más conocidos/aceptados:

https://www.crisp.se/file-uploads/Lean-from-the-trenches.pdf








pag. 27

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 dePrograma 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 engrupos 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 segúnel 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 –

CraigLarman y Bas Voode)




http://less.works/

http://less.works/

http://less.works/

https://vimeo.com/43956744


http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961




http://less.works/




pag. 28

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 Alliancewww.scrumalliance.org

Es la organización más importante dentro del mundo de Scrum. Promueve Scrum atravé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), gruposde usuarios (por ejemplo el grupo de usuarios de Argentina10) y difusión de contenidosrelacionados con Scrum.

Scrum Managerwww.scrummanager.net

Es una Comunidad de Conocimiento Abierto para mejorar y ampliar el conocimientoprofesional 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 opor ciudad. Se identifican en el sitio de la comunidad los distintos eventos según lalocalidad (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 yMetodologías Agiles:

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

http://www.scrumalliance.org/

http://www.scrummanager.net/

http://www.agiles.org/


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





http://www.scrummanager.net/

http://www.scrumalliance.org/



pag. 29

Certified Scrum Master (CSM) por la Scrum Alliance. Es una formación de dosdí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 ala CSM, pero más enfocada en el rol de Dueño de Producto.

Agile Certified (ACP) por el Project Management Institue (PMI). Estácertificación abarca no solamente Scrum pero también la mayoría de lasmetodologías agiles existentes (Lean, Kanban, XP). Define un Cuerpo deConocimiento compuestas de las más reconocidas practicas agiles existentes yse valida a través de un examen formal. Existen varias formaciones disponiblesde preparación11.

11 Por ejemplo: http://www.sceu.frba.utn.edu.ar/e-learning/cursos-a-distancia/Project-

Management/Curso-de-Gestion-Agil-de-Proyectos-%28PMI-ACP%29/temario.html

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







pag. 30

10

CONCLUSIONES

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

Destacamos en esta maduración el rol específico de Scrum Master como agente decambio. Su rol es fundamental como acompañamiento de equipos a lo largo delcamino de la implementación de Scrum. Podemos mencionar en particular el Scrum

Master Checklist 12 como fuente de inspiración para todos los Scrum Master que

realmente buscan la mejora continua para sus equipos…

12 http://www.scrummasterchecklist.org/

http://www.scrummasterchecklist.org/




u3.herramientas avanzadas para scrum

Documents