Scrum Master

Fabian Schwartz - CST

Scrum Master

Introducción El Manifiesto Ágil

Reuniones de
Las Bases de Scrum
Scrum

Artefactos de
Los Roles de Scrum
Scrum

2
Introducción y Equipos

3
 Ac#vidad

Check In
§ Hola, soy …

§ De la empresa …

§ Estoy feliz, mo4vado, expectante, animado, etc.

4
Protocolo del Entrenamiento
Scrum
§ Reglas para el Equipo:
§ Respetar el 4empo
§ Manejar una conversación a la vez
§ Apagar sus celulares/apps durante la sesión NO
Scrum

§ Reglas de comunicación en línea:

§ … micrófono en mute
§ … mover la mano encima delante de la cámara cuando quiera Ac#vidad

intervenir
§ … cámara ac4vada (cámara desac4vada significa: no estoy
presente)
§ … uso de chat para hacer preguntas rápidas
Caso

5
 NO
Scrum
Obje6vos de Aprendizaje
• Entender los fundamentos de Scrum
• Roles
• Artefactos de Scrum
• Eventos de Scrum
• Aprender como manejar estos elementos de forma remota
• Estar listo para presentar el examen Certified ScrumMaster-CSM

• Fuera del alcance:

• Como aplicar Scrum en un contexto particular
• Resolver preguntas de coaching

6
 NO
Scrum
Nuestro Product Backlog

Introducción y Burndown Los orígenes de Manifiesto Ágil Proceso Valores de

equipos Charts Scrum 3-5-3
Empírico y Scrum
4 4 2 2
8 Definido 1 2

Visión general Product Owner Scrum Master Product

Developers EsJmación Sprint
Scrum Team Backlog
6 4 2
4 6 6 2

Sprint
Sprint Planning Sprint Backlog Daily Scrum Refinamiento Increment Sprint Review
RetrospecJve
2 1 8 1 2 4
4

Evidencia Cultura y
Próximos pasos Finalizar
Empírica Contratos
4 1
8 2

7
 Ac#vidad

2 x 2min:
¿Cual es tu experiencia haciendo Scrum remoto?

8
 Ac#vidad

Equipos que se auto-organizan

§ Definan un Nombre Poderoso para su Equipo
§ Elijan un Product Owner (estará encargado de administrar el “Product Backlog de
Aprendizaje” en Trello)
§ Elijan un Scrum Master (estará encargado de la administración del tablero del Scrum
Team en Trello) PorDo
Hacer Haciendo Terminado

§ Crear las siguientes listas: ObjeJvo de

Product Backlog de Aprendizaje, aprendizaje 1

Por Hacer, Haciendo y Terminado

§ En Product Backlog de ObjeJvo de
aprendizaje 2
Aprendizaje agregar tantos
obje4vos como quieran!
ObjeJvo de
aprendizaje 3

Tiempo: 10 min.
9
 Ac#vidad

www.trello.com
Nombre del Equipo

PorDo
Hacer Haciendo Terminado

ObjeJvo de
aprendizaje 1

ObjeJvo de
aprendizaje 2
Obje4vos de
Aprendizaje
ObjeJvo de
aprendizaje 3

10 Listas
Quienes somos?

11
Burndown Charts
 NO
Scrum

Standish Group – Chaos Report

Fracaso completo: Los proyectos
se han cancelado 19% Proyectos exitosos: dentro del
6empo, presupuesto y alcance

29%

Proyectos parcialmente exitosos

52%
• Arriba del presupuesto y/o
• Arriba del 6empo y/o
• Alcance no logrado totalmente
Fuente: Standish Group – Chaos Report 2015

13
 NO
Scrum

2/3 de la funcionalidad no son u6lizados

frecuentemente
Solamente 1/5 es
u<lizado
Siempre frecuentemente
7%

Frecuentemente
13%
Nunca
45%
Algunas veces
16%

2/3 de la
funcionalidad no
son usados nunca Casi Nunca
o casi nunca 19%

Fuente: Standish Group – Chaos Report 2002 14

 NO
Scrum

Los requerimientos cambian en un año

36%
Fuente: Schwaber and Sutherland 2012 15
 NO
Scrum

Cambiar la perspec6va
Tradicional Ágil

Fijo Alcance Costo Tiempo

Valor en
marcha

Opelt A. et al; Agile Contracts 2013

Plan en
marcha
Es<mado
Costo Tiempo Alcance

16
 NO
Scrum

Diagramas de GanP

17
 NO
Scrum
Aterrizar el Proyecto

Un diagrama de Gan3 no
sirve para aterrizar un avión.

Para aterrizar en la pista

debemos inspeccionar y
adaptarnos con?nuamente.

18
 Scrum

Burndown Chart del Sprint

Puntos

Propósito: Mostrar el trabajo restante

1 sobre el ?empo (usado por el Equipo
para su propia ges?ón).

Responsabilidad: Equipo de Desarrollo

2 (incen?vado por el Scrum Master).

El Burndown Chart es actualizado

3 normalmente después de cada reunión
diaria. Días
Junto con los tableros Scrum, los Burndown Charts son
herramientas muy ú9les para iden9ficar tendencias
 Scrum

Burndown Chart de lanzamiento (Release)

Puntos

Propósito: Para que el PO ges?one el

1 plan de lanzamiento.

2 Responsabilidad: Product Owner.

Frecuencia actualizada: Al final de cada

3 Sprint.
Sprints

20
 Scrum

Burnup Chart de lanzamiento (Release)

Puntos

Sprints

21
Orígenes de Scrum
 NO
Scrum

La idea detrás de Scrum

“The New New Product Development Game“ - Harvard Business Review 1986

Ikujirō Nonaka Hirotaka Takeuchi

23
 NO
Scrum

Los Cocreadores de Scrum

Jeff Sutherland Ken Schwaber

24
 Las Reglas del Juego no te enseñan a ganar
Para ganar necesitas: Las Estrategias del Juego

25
Si te gustó el libro, recomiéndanos en Amazon
https://www.amazon.com/-/es/Fabian-Schwartz-ebook/dp/B086HWY5KM/
Scrum Master

Introducción
El Manifiesto Ágil

Eventos de
Las Bases de Scrum
Scrum

Artefactos de
Los Roles de Scrum
Scrum
 NO
Scrum

Lean, Ágil y Scrum

Lean

La idea de maximizar valor para el

cliente mientras se reduce
Ágil desperdicio.

Mentalidad con valores y principios

Scrum

Marco para manejar tareas

complejas

28
 NO

The Secret History of Agile Innova<on

Scrum

|
The New New Product
Development Game
1. Inestabilidad
incorporada
2. Equipos de proyectos
autoorganizados
3. Fases de desarrollo
superpuestas
4. Mul=aprendizaje
5. Control su=l
6. Transferencia
organizacional del
aprendizaje

29 29
 NO
Scrum
El manifiesto ágil - 2001
Estamos descubriendo mejores maneras para el desarrollo de soYware,
haciéndolo y ayudando a otros a que lo hagan. Mediante este trabajo hemos llegado a
valorar:

• Las personas y las interacciones sobre los procesos y herramientas.

http://agilemanifesto.org/
• Un soYware funcional sobre documentación comprensible.
• La colaboración del cliente sobre negociaciones en el contrato.
• Responder al cambio sobre seguir un plan.

Esto es, mientras hay valor en las variables de la derecha, valoramos aún más las de la
izquierda.

30
30
 NO
Scrum

Manifiesto Ágil para Equipos Remotos

Individuos e interacciones En Equipos remotos

esas
Sobre
Interacciones
procesos y herramientas
son facilitadas por
herramientas
Fuente: Tobias Windbreak, Nureva

31
 NO
Scrum

Manifiesto Ágil para Equipos Remotos

No sobrevivas al cambio,
actúa ante él
Respuesta ante el cambio
Scrum nos provee herramientas para
sobre seguir un plan fluir de forma más natural con el
cambio mismo. La adversidad es la
El cambio es lo único que no materia prima de los equipos
cambia. Scrum más fuertes.

“Si no nos mantenemos abiertos al cambio,

vida.
no nos mantenemos abiertos a la

-Baba Ram Dass बाबा राम दास

32
 NO
Scrum

Principios del Manifiesto Ágil

1. Nuestra mayor prioridad es sa.sfacer al
cliente mediante la entrega temprana y
con.nua de so4ware con valor.
2. Aceptamos que los requisitos cambien, incluso
en etapas tardías del desarrollo. Los procesos
Ágiles aprovechan el cambio para proporcionar
ventaja compe??va al cliente.
3. Entregamos soAware funcional frecuentemente,
entre dos semanas y dos meses, con preferencia
al periodo de ?empo más corto posible.
4. Los responsables de negocio y los
desarrolladores trabajamos juntos de forma
co?diana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a
individuos mo?vados. Hay que darles el entorno
y el apoyo que necesitan, y confiarles la
ejecución del trabajo.
6. El método más eficiente y efec?vo de comunicar
información al equipo de desarrollo y entre sus miembros
es la conversación cara a cara.
7. El soXware funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser
capaces de mantener un ritmo constante de forma
indefinida.
9. La atención con?nua a la excelencia técnica y al buen
diseño mejora la Agilidad.
10.La simplicidad, o el arte de maximizar la can?dad de trabajo
no realizado, es esencial.
11.Las mejores arquitecturas, requisitos y diseños emergen de
equipos auto-organizados.
12.A intervalos regulares el equipo reflexiona sobre cómo ser
más efec?vo para a con?nuación ajustar y perfeccionar su
comportamiento en consecuencia.

33
 Ac#vidad

Ac6vidad
• Piensa cuál es el principio que más necesitan en tu cultura empresarial para
favorecer el trabajo remoto de alto-rendimiento.

• Piensa en ¿cómo lo harías operaAvo en tu empresa o en un equipo de trabajo

remoto?

• Prepárate para comparAr tu idea!

Tiempo: 10 min.

34
Scrum Master

Introducción El Manifiesto Ágil

Eventos de Las Bases de

Scrum
Scrum

Artefactos de
Los Roles de Scrum
Scrum

35
Proceso empírico y definido

36
 Scrum

Los Pilares de Scrum

Transparencia Inspección Adaptación

Inspeccionar artefactos y Adaptar cuando la desviación
Lenguaje común y definición de
progreso hacia el obje?vo del esta afuera de los limites
terminado en común
Sprint

37
Valores de Scrum

38
 Scrum

Encuentra los 5 valores de Scrum

E M P A T I A L U I S F
V A L O R E S P E T O A
A M O R F O C O O K R B
F E R Z C O R A J E D I
L A P E R T U R A X E A
C O M P R O M I S O N N
A M I S T A D B I E N S
A G I L R F U E R Z A X
Tiempo: 3 min.
39
 Scrum
Scrum

Encuentra los 5 valores de Scrum

E M P A T I A L U I S F
V A L O R E S P E T O A
A M O R F O C O O K R B
F E R Z C O R A J E D I
L A P E R T U R A X E A
C O M P R O M I S O N N
A M I S T A D B I E N S
A G I L R F U E R Z A X

40
40
3-5-3

41
 Scrum

Tiempo: 7 min 42
43
43
Scrum Master

Introducción El Manifiesto Ágil

Eventos de
Las Bases de Scrum
Scrum

Artefactos de Los Roles de

Scrum
Scrum
44
El Scrum Master asigna las tareas a los Developers

45
El Scrum Master resuelve Impedimentos.

46
El Product Owner es responsable del ROI.

47
El Product Owner refina la visión del
producto con6nuamente.

48
Los Developers son responsables de entregar
un producto con calidad.

49
El Scrum Team depende de otros equipos.

50
 NO
Scrum
Las 4C´s

51
Scrum Team

52
 Scrum

El Scrum Team

Product Scrum
Developers
Owner Master

• Definir y priorizar los

elementos del Product • Facilita el proceso de Scrum • Multifuncional, todas las
Backlog. • Elimina amenazas y facilita el competencias para lograr el
• Tomar decisiones acerca de los intercambio de información objetivo del producto
contenidos y fecha de • Responsable de la efectividad • Autogestionado
lanzamiento del producto. del Scrum Team • Diseñado para aumentar
• Responsable de la rentabilidad flexibilidad, creatividad y
de los productos (ROI) productividad
53
Product Owner

54
 NO
Scrum

Prerrogativas del Product Owner

Autoridad
Autoridad para decidir sobre QUÉ
hay que hacer.

Definir Alcance Definir fecha de lanzamiento

Conocimiento del producto y de las
El Product Owner decide cuando
necesidades del cliente para definir
entregar al cliente.
el alcance para los Developers

55
 Scrum

Responsabilidades del Product Owner

Maximizar el valor del trabajo de los

1 Determinar Presupuesto 4 Developers

Crea la visión del producto Maximizar el valor del producto del

2 (Continuadamente)
5 Scrum Team

Crear, mantener y ordenar el Product

3 Backlog
6 Definir fechas de lanzamiento

56
 Scrum

El Product Owner es dueño de QUÉ

Tener una visión atrac5va

Pasar la mitad de su tiempo del producto que se pueda
trabajando de cerca ejecutar.
con los Developers

Construir un mapa para

desarrollar su visión.

Pasar la mitad de su Construir el Product Backlog

5empo con el cliente

57
 Scrum

La autoridad del PO sobre el Backlog

Claramente Visible y
Ordenado Valor opDmizado Entendido
expresada transparente

Expresar claramente los Ordenar los ítems del Op:mizar el valor del Asegurarse de que el Asegurar que los
puntos del Backlog Product Backlog para trabajo que realizarán Product Backlog sea Developers en:enden los
alcanzar las metas de una los Developers del visible, transparente y ítems del Product Backlog
mejor manera. producto. claro para todos, y al nivel necesario.
mostrar el siguiente
trabajo a los Developers

58
Scrum Master

59
 NO
Scrum

Prerrogativas del Scrum Master

Tener acceso a stakeholders y

altos ejecuDvos

Experimentar con
nuevas ideas Cuestionar abiertamente

60
 Scrum

Responsabilidades del Scrum Master

1 Actuar como un agente de cambio 4 Liderar a través de influencia

Asegurar que Scrum es entendido y

2 adoptado
5 Aumentar la visibilidad

Entrenar (coach) al Scrum Team y a la

3 organización

61
 Scrum

El Servicio del Scrum Master al PO

Facilitar la colaboración Ayudar al Scrum Team a

de los interesados según entender la necesidad de
se solicite o necesite contar con elementos del
Product Backlog claros y
concisos

Ayudar a encontrar técnicas

para una definición efectiva de
Entender la planificación del
Objetivos del Producto y la
producto en un entorno empírico
gestión del Product Backlog

62

El Servicio del Scrum Master a los Developers
Guiar a los miembros del
equipo en ser autogestionados
y multifuncionales
Procurar la eliminación de
impedimentos para el
progreso del Scrum Team
63
Scrum
Ayudar al Scrum Team a
enfocarse en crear Increments de
alto valor que cumplan con la
Definición de Terminado
Asegurarse de que todos los
eventos de Scrum se lleven a
cabo y sean positivos,
productivos y se mantengan
dentro de los límites de tiempo
recomendados en Guía Scrum
 Rol

El Scrum Master sirve a la Organización Scrum

de varias formas:
Planificar y asesorar
implementaciones de Scrum
Liderar, capacitar y guiar a la dentro de la organización
organización en su adopción
de Scrum

Ayudar a los empleados y los

interesados a comprender y
aplicar un enfoque empírico Eliminar las barreras entre los
para el interesados y los Scrum Teams
trabajo complejo

64
Developers

65
 Scrum

Prerroga6vas de los Developers

Producir resultados de calidad

Elegir el trabajar en lugar

de ser asignado Proveer sus propias
esDmaciones

66
 Scrum

Responsabilidades de los Developers

Entregar un Increment del producto de Asis?r al Product Owner a mantener el

1 acuerdo al la “Definición de Terminado” 4 Product Backlog

2 Mejorar sus prác?cas profesionales 5 Implementer Items del Product Backlog

3 Es?mar

67
 Scrum

Caracterís6cas de los Developers

Responsable como equipo

Mul5funcional

Máx 8 profesionales Autoges5onado

Sin silos de especialistas Sin Htulos. Todos son

Developers

68
 NO
Scrum

Agregar 4 personas a un equipo de 6 va a

alargar el proyecto por 6 meses
Tiempo Costos 6 canales de
4 Personas
25 comunicación

20

15 5 Personas 10 canales de
comunicación

10

5
6 Personas 15 canales de
comunicación
0
2 4 6 10 17

69 Source: h>p://www.qsm.com/process_improvement_01.html
 NO
Scrum

Retos para un Scrum Team

remoto

70
 NO
Scrum

Equipos de alto desempeño con Scrum remoto

El Modelo de Compromiso de Alto Rendimiento(HPCM)
Foco Propósito

Seguridad
Confianza
Psicológica

Conciencia
Mul3funcional
compar3da

Modelo de Fabian Schwartz

71
 NO
Scrum

Scrum Teams
remotos
necesitan más
comunicación

72
 NO
Scrum

Efec%vidad en la
Comunicación
El énfasis está en el cambio de la
Documentación hacia la Conversación

73
 NO
Scrum

El video es tu amigo
• Man7ene una conexión más profunda
• Está conectado con el cerebro
humano
• Los bebés recién nacidos pueden
reconocer rostros
• Cuando las personas se miran sienten
que están juntas y presentes
• Los rostros son muy importantes para
detectar el estado de ánimo

74
Scrum Master

Introducción El manifiesto Ágil

Eventos de
Las bases de Scrum
Scrum

Artefactos de Los roles de Scrum

Scrum
75
Product Backlog

76
 Scrum

Product Backlog
• Lista emergente y ordenada de los
ítems conocidos del producto
Producto
(Product Backlog Items)
• Esta equipado con un Compromiso:
El Objetivo del Producto

77
El Product Backlog es
Scrum
Mayor Mayor
una lista ordenada de Orden Detalle

los PBIs conocidos

♠
🏷 💰
menor menor
orden detalle
78
 Scrum
Mayor
ℱ(Valor) = Orden Valor
Conocido

menor
Valor
79
conocido
 NO
Scrum

Product Mindset
Fijo Costo Tiempo

¿Dónde está el mayor

valor?

q Al inicio de la lista
q En algún lugar de la lista
q Al final de la lista

Es'mado
Alcance
80
 Ac#vidad

¿Cuál de estos es un buen Product Backlog?

81
 NO

Visión del Producto:

Scrum

Experiencia Gastronómica

Producto:
Experiencia Gastronómica Paisa
Típica

82
 NO
Scrum

Elementos para el Product Backlog

Experiencia Gastronómica Paisa Típica
Plato Postre “Pasante” Show Merchan.
Fuerte

83
83
 NO
Scrum

Product Backlog
Experiencia Gastronómica Paisa Típica
Bandeja
Paisa

Mazamorr
a
Dulce

“Pasante”

Show

Merchan.

84
 Ac#vidad

Ac#vidad – Diseña tu propia experiencia gastronómica

• Diseña un Product Backlog en Trello para tu propia “experiencia gastronómica”
• Debe contener, mínimo, 7 elementos

Tiempo: 20 min.
85
EsPmación

86
 Ac#vidad

Ac6vidad

Lavar los platos Hacer la cama Lavar el carro Planear vacaciones Aprender 200 palabras en
alemán

Revisar y Cocinar pasta Ir al gimnasio Lavarse los Mudanza

responder correos dientes
Tiempo: 10 min
88
 NO
Scrum

Es<memos PBIs
Experiencia Gastronómica Paisa Típica
Mazamorra
Dulce
?

Bandeja
Paisa
?

Merchan.
Show ?
?
“Pasante”
?
89 Tiempo: 10 min
Sprint

90
 Bloque de )empo, de un mes o menos, durante el cual
se crea un increment de producto “terminado” u)lizable y potencialmente desplegable.

91
El Sprint con6ene todos los eventos de Scrum

92
 NO
Scrum
Duración del Sprint
Duración promedio del Sprint de acuerdo con el reporte State of Scrum de 2016

66%
1 semana 2 semanas

4%
4%
26%

Otros
3-4 semanas

93
 Scrum

El Sprint es más importante para Equipos remotos

• El corazón del Scrum

• Define el 'empo
• Define el progreso
• Es el ritmo

94
94
Scrum Master

Introducción El Manifiesto Ágil

Eventos de Las Bases de Scrum

Scrum

Artefactos de
Los Roles de Scrum
Scrum

95
Sprint Planning

96
 Scrum

Sprint Planning

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• Scrum Team • Al inicio de cada Sprint • Product Backlog Sprint Backlog

• Duración: 8 horas para
un Sprint de 1 mes
97
• El úl?mo increment del • ¿Por Qué? Obje?vo del
producto Sprint
• Capacidad proyectada de • ¿Qué? PBIs seleccionados
los Developers para el • ¿Cómo? Plan de trabajo por
Sprint cada PBI
• Velocidad anterior de los
Developers
 Scrum
Capacidad de los Developers
5 días = 40 horas
Daily Scrum Daily Scrum Daily Scrum Daily Scrum

Planning

oApP
Review

Ref. Retrospective

Día 1 Día 2 Día 3 Día 4 Día 5

98
 Scrum
Capacidad Proyectada de los
Developers

40h
- Planning 2h
- DS (15 min * 4 = 1h)
- Review (1h)
- Retrospec#ve (45 min)
- otras Ac#vidades
- Refinamiento
Capacidad Proyectada
99
 Scrum

Velocidad de los Developers

Rendimiento pasado de
los Developers
(Promedio úl4mos tres
Sprints).

100
 Scrum
Sprint Planning en Scrum Teams remotos

ObjeAvo: Crear el plan del Sprint - Sprint Backlog

• La meta otorga PROPÓSITO

• Debe ser alcanzable de forma realista durante la

duración del Sprint

101
Sprint Backlog

102
 Scrum

Sprint Backlog
Product Backlog Sprint Backlog

Obje;vo del Sprint (Por qué)

PBIs(Qué)

Ítems seleccionados
de la Lista de Producto Desglose de tareas (Cómo)

Esta equipado con un Compromiso:

El Objetivo del Sprint

103
 NO
Scrum

Product Backlog
Experiencia Gastronómica Paisa Típica
Bandeja
Paisa
8
SP 1
Mazamorr
a
Dulce
4 SP 1
“Pasante”
4

Show
?

Merchan.
?

104
 NO
Freir Scrum

Sprint Backlog del SP1 Cocción

Frijoles
Huevos

Experiencia Gastronómica Paisa Típica Cocción

Arroz Arepas

Bandeja Freir
Paisa Chorizos
8
Asar
Preparar Maduros
Freir
Chicharro Carne
n Molida

Cocinar
Maíz Trocear
Mazamorr Bocadillo
a
Dulce
4 Hervir ParDr
Leche Panela
105
1

106
 Ac#vidad

Ac#vidad – Diseña tu Sprint Backlog

• Diseña tu Lista de Pendientes del Sprint

• Escoge los primeros tres ítems de tu Product Backlog y desglósalos en sus
tareas

Tiempo: 10 min.

107
Daily Scrum

108
 Scrum

Daily Scrum

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto 3empo?

• Developers • A la misma hora todos • Sprint Backlog • Un entendimiento

• Si PO y/o SM están los días, es definida por común del trabajo más
trabajando acMvamente el equipo importante para
en PBIs parMcipan • Duración: Máximo 15 avanzar hacia la meta.
como Developers minutos • Un Backlog actualizado
de los impedimentos.

109
 Caso

James Coplien – Saturación de comunicación

120

% de saturación de comunicación
100 52 veces más rápido

80
Saturación de comunicación
60 Bell Labs Pasteur Project
82 empresas
40

20
Como resultado quitaron todos los
9tulos. 0

52x
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80
Número de roles
Más rápido

110
 NO
Scrum
El tablero Scrum es sencillo
Do
Hacer Haciendo Terminado

PBI 1

PBI 2

PBI 3

• El Sprint Backlog debe mostrar todo el <empo qué ítem están siendo trabajado y por quién
• El Sprint Backlog es actualizado por lo menos una vez al día

111
 NO
Scrum
El tablero Scrum puede incluir columnas
adicionales
Do
Hacer Haciendo En Espera Terminado

PBI 1

PBI 2

PBI 3

112
 NO
Scrum
Un Buffer para tareas impredecibles puede
ser incluido
Do
Hacer Haciendo Terminado

Buffer

PBI 1

PBI 2

113
 NO
Scrum
Señales de alarma
Puntos

Do
Hacer Haciendo Terminado

Buffer
10

PBI 1

Dias

PBI 2

114
 NO
Scrum
Señales de alarma (2)
Puntos

Do
Hacer Haciendo Terminado

Buffer
2

PBI 1

Dias

PBI 2

115
 NO
Scrum
Señales de alarma (3)
Puntos

Do
Hacer Haciendo Terminado

Buffer
10

PBI 1

Dias

PBI 2

116
 Ac#vidad

Experimento

1 I A
Estrategia 1
No dejamos al
Cliente 2. II. B.
esperando . . .
. . .

10 X J
117
 Ac#vidad

Experimento

1 I A
Estrategia 2
Minimizar
trabajo en 2 II B
progreso
. . .
. . .
. . .

10 X J
118
 NO

La Mul&tarea resulta en &empo de Scrum

administración pobre

Sin Mul'tareas Prep

Prep

Prep
Tarea A Tarea B Tarea C Pérdida de <empo
debido al mal
trabajo en
mul<tareas

Con Mul'tareas Tarea Tarea Tare Tare Tarea Tare Tarea Tare Tare
Prep

Prep

Prep

Prep

Prep

Prep

Prep

Prep

Prep

Prep
Tarea B
A A aC aA B aC B aC aB

119
 NO
Scrum

Mul6tarea entre proyectos

Proyectos simultáneos Disponibilidad por proyecto Deficiencias causadas por cambio de contexto

1 100% 0%

2 40% 20%

3 20% 40%

4 10% 60%

5 5% 75%

Fuente: Gerald Weinberg: Quality Software Management

120
 NO
Scrum
Daily Scrum remoto
El parqueadero
Ayúdame a entender el patrón
de pruebas que usaste la
semana pasada para ver si lo
Nos podemos reunir con puedo usar aquí…
Juan a las 10:30 para
definir cual es la mejor
forma de diseñar esto

121 121
Product Backlog Refinement

122
 Scrum

Product Backlog Refinement

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• Developers • Cuando sea necesario • ObjeMvo del producto • Product Backlog

• Product Owner (proceso conMnuo) • Product Backlog refinado

123
 NO
Scrum
Definición de Listo
• Significa que los PBIs deben poderse trabajar
inmediatamente
• Los Developers deben ser capaz de determinar lo que
hay que hacer y la can'dad de trabajo necesario para
completar el PBI.
• Con ese entendimiento, los Developers deben es'mar
los puntos de esfuerzo del PBI
• Los PBIs en la parte superior del Product Backlog que
los Developers llevarán al Sprint Planning, deben estar
listos. 124
 NO
Scrum
¿Cuál será la Definición de Listo?

125
 NO
Scrum

Refinamiento del Product Backlog

Experiencia Gastronómica Paisa Típica
¿Que 5 Hits
interprete
cuantas?

¿Con Foto? Si!

Show
Show
? ¿Qué cuente
un chiste? No 33
¿Con
autógrafo? No

126
126
 NO
Scrum
Refinamiento Remoto
Obligatorio para Scrum Teams remotos:

• Los PBI´s son el inicio de una conversación

• Todos 4enen el mismo acceso estén remotos o no
• Se busca favorecer la colaboración entre los miembros del
Scrum Team al visibilizar los PBIs
• Los Scrum Teams distribuidos requieren más disciplina y se
deben comprometer
• No permi4r que la Definición de Listo se tome a la ligera
• El simple hecho de tener sus PBIs listos tendrá un impacto
inmediato y dramá4co en la produc4vidad del Scrum Team
127
Increment

128
 Scrum

Definición de Terminado vs
Criterios de Aceptación
Definición de Terminado Criterios de Aceptación

Lista de chequeo Condición de saDsfacción

Cada PBI debe cumplir estas Es individual para cada PBI
condiciones

Ejemplo Ejemplo
• Desarrollado Compra con tarjeta de
• Probado crédito funciona con:
• Cumple criterios de • Visa
aceptación • Master Card
• Integrado • American Express
• Documentado

129
 Ac#vidad

¿Cuáles son los criterios de aceptación de…?

¿Qué 6enen en común?

130
Sprint Review

131
 Scrum

Sprint Review

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• Scrum Team • Al final de cada Sprint • Increment • Increment del producto

• Stakeholders • Duración: 4 horas para • ObjeMvo del Producto para potencial envío
un Sprint de 1 mes • Product Backlog • Velocidad (¿Qué está
terminado?)
• Actualización del
pronósMco de
lanzamiento
132
 NO
Scrum
Plan de lanzamiento (Release) – Alcance fijo
Puntos del
PB
1000

¿Cuándo está
terminado mi
MVP?

650

+100
Mitad de marzo
+100

150

Sprints
Ene Feb Mzo
133
 NO
Scrum
Plan de lanzamiento (Release) – Fecha fija
Puntos del
PB
1000

Algo de esto

+100

Todo esto ¿Qué vamos a tener

+100 listo el 1ero de Marzo?
150

Sprints
Ene Feb Mzo
134
 NO
Scrum
Sprint Review Remoto

135
Sprint RetrospecPve

136
 Scrum

Retrospec6va del Sprint

¿Cuándo?
¿Quién? Entrada Salida
¿Cuánto?

• Scrum Team • ÚlMmo día del Sprint, • Información del Scrum • ¿Qué salió bien?
después del Sprint Team acerca del úlMmo • Mejora potencial
Review Sprint • Interacciones, Procesos,
• Duración: máx. 3 horas Herramientas &
para Sprint de 1 mes Definición de
Terminado ajustados

137
 NO
Scrum
Sprint Retrospec6ve

Velocidad

1 2 3 4 5 6 7 8 9 10
Sprint
Velocidad efecCva Velocidad efecCva sobre
sobre Cempo Cempo
(sin retrospecCvas) (con retrospecCvas) Fuente: Henrik Kniberg

138
 Herramientas On-Line para hacer
NO
Scrum

Retrospectivas
•Funretro (https://funretro.io/) Gratis. Hasta 3 tableros de
retrospectiva.
•GoReflect (https://www.goreflect.com/) Gratis durante 100 días.
•Reetro (https://reetro.io/) Gratis.
•Retrium (https://www.retrium.com/) Paga. Opciones de retro
online, permite la opción de comentarios anónimos.
•ScatterSpoke (https://www.scatterspoke.com/) Gratis (pago sobre
opciones premium)
•TeamRetro (https://www.teamretro.com/) Periodo de prueba
•Sensei (https://www.senseitool.com/) Gratis
139
140
Evidencia empírica

141
 Caso

Excediendo Expectativas
Credits:
Cristian Sparacino – Jefe Departamento Operaciones TI
José Luís Bernal Quimbay – Jefe Servicios TI
Jefersson Gordillo Lopez – Coordinador Soporte TI
Guillermo Rodriguez – Scrum Master

Colsubsidio: Excediendo Expectativas, by LUÍS FERNANDO SENDOYA

142
 Caso

Backstage
• Colsubsidio pertenece al Sistema del Subsidio Familiar y al Sistema
de Protección y Seguridad Social colombiano

• La prestación de servicios sociales contempla los programas que

desarrolla la Caja de Compensación a través de sus unidades:
Afiliaciones y Subsidios, Educación y Cultura, Recreación y Turismo,
Vivienda y Subsidio de Vivienda, Crédito Social, Alimentos y
Bebidas, Salud y Mercadeo Social

143
 Caso

Equipo Aprovisionamiento
Debe entregar valor a la ver6cal de Salud y Mercadeo Social

Históricamente, este equipo tradicional En el tercer trimestre de 2018, el nuevo equipo

de 5 personas abría 5 #endas por Scrum (PO, SM, DTx3) logró la marca de 27
6endas
540% de
trimestre

Valor

144
Contratación y Cultura

145
 NO
Scrum
Contratación ágil
Añadir disposiciones contractuales:
• Cualquier requisito que aún no se haya trabajado se puede
cambiar por otro de igual tamaño
• Se puede cambiar el orden de los requisitos.
• El cliente puede solicitar lanzamientos adicionales en cualquier
momento cuando prevalezca tarifas de tiempo y material
• El cliente puede rescindir el contrato antes de tiempo si se ha
satisfecho el valor del 20% del valor restante del contrato no
facturado

146
 NO
Scrum
Cultura: un factor clave para tener en cuenta
Latinoamericanos
Distanica de Poder 35 70 Alemanes

Individualismo 21 67

Evasión de la 65 85
incertidumbre

Masculinidad 49 65

Contexto Muy bajo Alto

0 25 50 75 100

147
 NO
Scrum
Contexto

alto
• Directo, explicito
• Apela a las ventas fuertes Japonés
• Competitivo
• Publicidad comparativa Árabe
• Solución de problemas • Llamada indirecta (menso hard sell
appeals)
• Muy poca información Latinoamericano
• Precio, garantía, servicio • Comunicación indirecta e implícita
• Referir a la tradición
Italiano
Contenido
• Valorar gente mayor
• La publicidad tiene poca relación con el
Ingles producto (formar imagen, crear
confianza)
Frances • Resultados de investigación pagado por
• Factual, mucha
la empresa
información
Norteamericano
• Poco humor
• Francia e Italia
Scandinavo • Mensaje relativamente implícita
• Fantasía, escapar de la realidad, soñar
Aleman • Elementos de películas de acción
(Francia)
bajo

Suizo (de la suiza alemana)

Explicito Información Implícito

Fuente: M. Rösch: Communication with Japanese

148
 NO
Scrum
Contexto
Si de Si, Si,
Si, con No tanto mala de pronto Si, Mas En
Significado Si, OK
gusto pero si gana tal vez improbable realidad no

Palabra

Si

Alemán

Si

América Latina

Congruencia Diferencia entre

entre lo que se
Rango significado lo que se dice y
dice y lo que
lo que significa
significa

149
 NO
Scrum
Cuando se combinan diferentes dimensiones de
culturas, las agrupaciones se pueden iden&ficar
Bajo

Individualismo

Alto

Bajo Distancia de poder Alto

150
 NO
Scrum
La habilidad No.1 de un buen Scrum Master
en LATAM
75th % Distancia de Poder
• Países con Distancia de poder alto
como Colombia
Desempeño como líder

25th % Distancia de Poder

• Países con Distancia de poder bajo
como Alemania

Empatía

Fuente: Golnaz Sadri, Todd J. Weber William A. Gentry, Empathic emotion and leadership performance: An empirical analysis across 38 countries (2011)

151
Próximos pasos

152
Recibe un 20% de dto en los proximos cursos
Product Owner para la Scrum@Scale para varios
persona del negocio equipos
24-25 de Julio 13-14 de Agosto
Fuentes
• Libros
• EssenMal Scrum by Kenny Rubin • Guía de Scrum
• Scrum: The Art of doing twice the work in half the Mme by Jeff & JJ Sutherland http://www.scrumguides.org
• Agile EsMmaMng and Planning by Mike Cohn
• Agile RetrospecMves by Esther Derby & Diana Larson
• Patrónes
http://www.scrumplop.org
• Blogs
• ArMculos hjp://scrumcolombia.org
• The New New Product Development Game by Takeuchi & Nonaka, HBR 1986
https://hbr.org/1986/01/the-new-new-product-development-game
• Embracing Agile by Rigby, Sutherland & Takeuchi
hjps://hbr.org/2016/05/embracing-agile
• Agile at Scale by Rigby, Sutherland & Noble
hjps://hbr.org/2018/05/agile-at-scale
154