Formación Scrum Masters Online alumnos.pptx

Nombre Experiencia con
Agile / Scrum
Expectativas
del curso
Scrum Master
Antes de empezar...

¿Cada cuanto descansamos?
Normas

Scrum & el papel del Scrum Master
Agile
Empirismo
Roles
Eventos
Artefactos
DoD
People &
Teams
SM
&
Organización
Índice

Montemos nuestro
propio Scrum
Master
Scrum Master I

Las frases como ‘aquí no se puede’, ‘es
que este proyecto es especial ’… quedan
como excusas y se usan como escudo para
no cambiar y seguir como estamos.

En agile no existen planificaciones
Un Scrum Master debe programar
Todo equipo debe contar con un
especialista QA
Los desarrolladores no necesitan
habilidades de trato con el cliente
Los equipos Ágiles no hacen
documentación
Debemos tener a alguien que nos
diga lo que tenemos que hacer
¿Verdad o Mentira?

PRINCIPIOS
VALORES
CONFIANZA
SCRUM
XP
Pirámide Ágil

Manifiesto Ágil
Individuos y sus interacciones Procesos y Herramientas
Software funcionando Documentación exhaustiva
Colaboración con el cliente Negociación contractual
Respuesta ante el cambio Seguir un plan

Trabajo juntos
12 Principios Ágiles
Satisfacer al cliente Bienvenida al Cambio Entrega frecuente
Individuos motivados Conversación cara a cara Software Funcionando Desarrollo Sostenible
Atención a la excelencia Mantener la simplicidad Equipos auto-organizados Reflexionar para
mejorar

Arreglemos la
temperatura
Agile

Sois el nuevo Scrum Master para un equipo que quiere solucionar un
problema con la temperatura de la Satélite
Jose, facilitador, necesita programar la bomba de calor, el aire acondicionado,
ventilación y persianas para todos los días.
Reúnes al equipo para para desarrollar un listado de las variables que influyen
en la temperatura de la satélite.
Durante el día no se pueden aplicar ajustes y queremos una temperatura
constante de 22ºC
Arreglemos la temperatura

Materiales de construcción del
edificio
Número de personas
Actividad de cada
persona
Metabolismo de cada
persona
El tiempo exterior (sol, lluvia, etc)
Horarios de comida
Temperatura de otras
oficinas
Puertas abiertas o
cerradas
Temperatura de la
comida
Otras
Algunas variables

Podemos ignorar las variables con un proceso EMPÍRICO
INSPECCIONAR la temperatura adecuada
ADAPTAR el sistema que controla la temperatura (frío - calor) poníendonos de
acuerdo
TRANSPARENCIA es necesaria que la temperatura sea inspeccionada
Solución empírica

Predictivo Empírico
El trabajo y los resultados son entendidos
antes que la ejecución
A medida que se trabaja se realizan
frecuentes inspecciones y adaptaciones
Dado un conjunto de entradas bien definidas,
se generan las mismas salidas.
Siguiendo unos pasos predeterminados se
obtienen los resultados conocidos
Se acepta que los procesos estén
imperfectamente definidos.
Los resultados a veces son impredecibles e
irrepetibles.
Ej: fábrica, trabajo de construcción Ej: ventas, marketing, teatro o
escritura creativa.
El proceso adecuado para el problema adecuado

Fomentar el incremento de
los niveles de interacción y
comunicación
Acotar el ambiente de
acción
Liderazgo sirviente
Ayudar a probar, sentir y
responder
Promover la generación
de ideas
El trabajo del líder

Transparencia Inspección
Proceso empírico
Adaptación

Definición de Agilidad
La habilidad para
responder rápidamente
y deliberadamente a los
cambios demandados,
controlando los riesgos.
Flexibilidad, la
capacidad para
adaptarse rápida y
eficientemente.
La habilidad para
innovar.

Scrum implementa los 3 pilares de un proceso empírico
Transparencia
Inspección
Adaptación
Todos sabemos lo
que está pasando
Revisión del trabajo
realizado
Ok al cambio de
dirección

Iterativo e incremental
Waterfall
Scrum
Tiempo Tiempo
Tiempo Tiempo
Habilidad
para el
cambio
Valor de
negocio
Visibilidad
Riesgo

Waterfall
Scrum
Riesgo
Tiempo Tiempo
Tiempo Tiempo
Habilidad
para el
cambio
Valor de
negocio
Visibilidad
Iterativo e incremental (solución)

Investigar e identificar
mercados viables,
tecnologías y
capacidades de
productos
Liberar
productos y
mejoras tantas
veces como sea
posible durante
el día
Mantener y
renovar
productos.
Desarrollar
productos y
mejoras
Desarrollar y mantener
ambientes en la Nube (en
línea, seguros, bajo
demanda) y otros
entornos operacionales
para el uso de productos;
Propósito de Scrum

Roles Artefactos
Eventos
PRODUCT OWNER
DEVELOPMENT TEAM
SCRUM MASTER
PRODUCT BACKLOG
SPRINT BACKLOG
INCREMENTO
SPRINT
SPRINT PLANNING
DAILY SCRUM
REVIEW
RETROSPECTIVE
Scrum es un framework
PRODUCT
GOAL
SPRINT
GOAL
DoD

Estás facilitando una retrospectiva y de pronto uno de los desarrolladores se queja de que
sus ideas no se están teniendo en cuenta.
¿Qué valores de Scrum se están manifestando aquí?

The Scrum
Team
User Community
Customers &
Stakeholders
Management
Product Owner
Scrum Master
Development Team
Resumen de Roles

Rebecca es la nueva Product Owner del equipo. Es su primera experiencia en Scrum y no
tiene claro a qué se dedica un Product Owner.
Ella ha leído que el Product Owner es el analista del equipo pero la ves discutiendo con un
compañero que asegura que el Product Owner es un priorizador de tareas.
¿Cómo definirías a un Product Owner?

Labores de un PO
Maximizar el valor del Producto
&
del Trabajo del Equipo
Gestionar el Product Backlog

Labores de un PO en la Scrum Guide
Puede delegar, pero sigue
siendo el responsable
Expresar los Items con
claridad
Optimizar el valor del
trabajo
Priorizar los items
Asegurarse que el equipo de
desarrollo entiende los items
No debe ser un equipo, debe actuar
como una sola voz
Centralizar todas las peticiones
(stakeholders)
Asegurarse que el Product
Backlog es visible, claro y
transparente

¿Qué es un Development Team?

Labores y Características del Development Team
Crear incrementos de producto
“terminados” que puedan subir
a producción
Autoorganizarse
Multifuncionales
Todos son desarrolladores
(no hay etiquetas)
No hay subequipos
Puede haber especialistas, pero la
responsabilidad es compartida
Tamaño 3 a 9 personas
(recomendado)

Dinámica online – El bolígrafo
Se tienen 4 iteraciones
Todos tienen 1 bolígrafo
visible
Pantalla encendida tengo
el bolígrafo
Se pasa el bólígrafo en un
orden
Pantalla apagada no tengo
el bolígrafo
Debe de dar una vuelta completa
con un bolígrafo a la vez
Todos son parte de un
equipo
2 minutos de planificación
ESTIMACIÓN
¿Cuántos bolis pasaremos?
SPRINT
Duración de 1 minuto
RETROSPECTIVA
Duración de 1 minuto

The Scrum Master is responsible for
promoting and supporting Scrum as
defined in the Scrum Guide. Scrum
Masters do this by helping everyone
understand Scrum theory, practices,
rules, and values.”

Funciones Generales del Scrum Master
Scrum sea entendido y
adoptado ajustándose a la
teoría, prácticas y reglas
de Scrum
Líder al servicio del Equipo
Scrum
Gestión para superar los
impedimentos
¿Cuál falta?

El SM al servicio del PO
Encontrar técnicas para gestionar la Lista de Producto de
manera efectiva
Entender la planificación del producto en un entorno empírico;
Ayudar al Equipo Scrum a entender la necesidad de contar con
elementos de Lista de Producto claros y concisos
Asegurar que el Dueño de Producto conozca cómo ordenar la
Lista de Producto para maximizar el valor
Entender y practicar la agilidad y facilitar los eventos de
Scrum según se requiera o necesite.

El SM al servicio del Dev. Team
Guiar al Equipo de Desarrollo en ser
autoorganizado y multifuncional
Gestionar para solventar impedimentos para el
progreso del Equipo de Desarrollo
Ayudar al Equipo de Desarrollo a crear productos
de alto valor
Facilitar los eventos de Scrum según se requiera o
necesite
Guiar al Equipo de Desarrollo en el entorno de organizaciones
en las que Scrum aún no ha sido adoptado y entendido por
completo

Actualmente estás trabajando como Scrum Master para un producto de Grandes Cuentas
de un banco inversor, al llegar a la oficina ves problemas de comunicación entre el Product
Owner y el Development Team.
El Product Owner no entiende la parte técnica ya que hay microservicios y no sabe bien que
son. El Development Team nunca ha trabajado con bancos de inversión y se lían con los
términos funcionales y piden que hables tú con él.
¿Debería el Product Owner aprender tecnología? ¿Debería el Development Team aprender
sobre el negocio? ¿Qué acción debes tomar?

Durante la formación del equipo y el inicio, descubres que el Scrum Team tiene que mantenerse
trabajando en otros proyectos para que lleguen a tiempo.
La presión de la organización y la sabiduría nos dicen que el equipo podrá trabajar en todos los
proyectos a la vez
¿Qué podría ocurrir?
Tu eres el Scrum Master
Múltiples proyectos con un equipo

Una empresa decide que un
equipo pase de 8 a 12 horas
de trabajo
Cuando trabajamos 12 horas
la tasa de incidencias se
dispara un 60%
El tiempo para arreglar eso
es de 4 horas diarias
No hemos mejorado nada…
¿Aumentamos las horas de
trabajo?
Se trabaja 8 horas al día máximo

Liderar y guiar a la organización en la adopción de
Scrum
Ayudar a los empleados e interesados a entender y llevar a
cabo Scrum y el desarrollo empírico de producto
Planificar las implementaciones de Scrum en la
organización
Motivar cambios que incrementen la productividad
del Equipo Scrum
Trabajar con otros Scrum Masters para incrementar la
efectividad de la aplicación de Scrum en la organización
El SM al servicio de la Organización

Development
Team
Scrum Master
Product Owner
Sprint
planning
Sprint
backlog
Daily scrum
Sprint
review
Sprint
Retrospective
Product
backlog Sprint Increment
Idea
< 30 días

La Scrum Master está trabajando en un equipo que va a comenzar pronto. Su jefe le ha
planteado que van a trabajar 10 Sprints, siendo el 10º el Sprint de Release, para a
continuación tener el Hardening Sprint donde mantendrán la aplicación.
¿Está entendido su jefe lo que es un Sprint?

Sprint
planning
Sprint backlog
Daily scrum
Sprint
review
Desarrollo terminado
listo para release
Sprint
Retrospective
Sprint
Goal
Time-boxed
events
Duración
constante
(<30 días)
No es
una fase
Estable, sin
cambios en lo
posible

No llegamos a tiempo
El equipo de desarrollo está trabajando bien durante el Sprint actual...
Sin embargo, 3 días antes del fin del Sprint, el equipo pide más tiempo
¿Extenderías el Sprint? .
1 o 2 días podrían ser suficientes y con ello tener los tests completados

Tarea del Product Owner
El objetivo del Sprint queda
obsoleto
Cambio de dirección de la
compañía
Cambio del mercado
Condiciones Tecnológicas
Hacer un nuevo planning
Se acepta el trabajo “done”
Cancelar un Sprint

El mes que viene vais a comenzar un nuevo Producto Software y estáis estudiando cómo
organizar los próximos Sprints. El Development Team habla contigo porque quiere que el
primer Sprint se dedique a construir una arquitectura completa.
¿Qué les dirías?

Estimación y velocidad
¿Qué opináis?

Eres el Scrum Master de un nuevo equipo que está desarrollando una aplicación muy
innovadora a nivel tecnológico en el mercado. El equipo de desarrollo tiene que tomar una
decisión tecnológica en mitad del Sprint que marcará el mismo.
El Product Owner insiste en que quiere saber todo lo que se va a entregar y cuantos puntos
se van a comprometer en este Sprint.
¿Por qué hay que tener todo el Sprint completo? ¿Qué les recomiendas?

Product Backlog
Velocidad & Capacidad
Definition of Done
Tareas Retrospectiva
Sprint Backlog
Objetivo para este Sprint
Previsión
Resumen
Analizar, evaluar y seleccionar
“Product Backlog to Sprint”
¿Qué?
Descomponer en un plan de
acción
¿Cómo?

Alcance Objetivo
Backlog
fuera del
Sprint
Es un
pronóstico
Se actualiza
con el avance
Se puede renegociar a
medida que avanza el Sprint
Es una
guía
Se actualiza en todo
momento
Aporta flexibilidad
en el cómo se
implementa
No se puede
cambiar
Objetivo del Sprint y alcance

¿Qué vamos a hacer y cómo?
Product Owner
Expone la idea de objetivo para este Sprint & Alcance esperado
Development
Team
Realizan preguntas para aclarar las tareas.
Determinan el alcance realista que podrán abarcar
Product Owner Development
Team
Acuerdan el objetivo final para este Sprint
Development
Team
Descomponen el alcance en elementos pequeños (técnicos)
Crear un plan para garantizar que consiguen el objetivo
Presentar dicho plan al PO y al SM

Eres el Scrum Master para un equipo que lleva varios Sprints trabajando en nuevo producto.
En este Sprint el Product Owner ha pedido una gran cantidad de items porque quiere lanzar
una buena imagen a los stakeholders.
El Development Team se ha venido arriba y está incluyendo una cantidad muy grande de
items que posiblemente no puedan abordar durante el Sprint.
¿Qué deberían hacer?

Hay que hacer 3
preguntas
Asiste PO, SM y
DT
Tiempo en
función de las
personas
Se hace todos
los días (es la
daily!)
Lugar lo
determinamos
cada día
La hora se
determina cada
día
¿Qué hice ayer?
¿Qué voy a hacer hoy?
¿Tengo algún impedimento?
De pié
Es de reporte
Sprint Backlog
opcional
Es de
coordinación
Se decide qué
días hacerla
Misma hora
Mismo Lugar
Sentado o de pié,
no hay regla
Asiste DT, el
resto
observadores
Formato libre
enfocado al
Sprint Goal
Reunión para fomentar la comunicación y autogestión con el
objetivo puesto en el sprint goal
Sprint Backlog
obligatorio
Discusiones
detalladas son
buenas
Discusiones
detalladas
después
15 minutos
Mito vs Realidad

Daily Scrum y el Scrum Master
Dirigida por el equipo de
Desarrollo
SM enseña para que
dure 15 minutos

Un SM está trabajando con su equipo cuando de repente su equipo les
dice que si pueden hacer la Daily sólo los martes y jueves ya que no necesitan hacerlo
diariamente.
¿Cómo debería actuar el SM si el equipo es autoorganizado y el evento es del Development
Team?

Sprint Review exitosa
Durante el Sprint Review, el CEO y el Project Manager animan al equipo de
desarrollo durante toda la reunión
Al finalizar, incluso realizan un aplauso al equipo de desarrollo.
¿Qué les aconsejarías?
Tú como Scrum Master...

Review vs Retrospectiva
Sprint
Retrospective
Sprint
Review
Inspeccionar el
incremento
Ninguno
El PO informa de la velocidad
requerida para el siguiente Sprint
Descubrir cómo hacer el siguiente
Sprint más agradable
El equipo Scrum se
inspecciona a sí mismo
Se actualiza el DoD para
incrementar la calidad del
producto
Inspeccionar el Product
Backlog y las fechas
probables de entrega
Una demo para enseñar el
producto a los interesados
Inspeccionar cómo fue el Sprint con
respecto a personas y relaciones
Inspeccionar los cambios del mercado y
potencial uso del producto
Actualizar el Product
Backlog
Reunión del estado para
el “steering committee”
Inspeccionar el
incremento
El PO informa de la velocidad
requerida para el siguiente Sprint
Descubrir cómo hacer el siguiente
Sprint más agradable
El equipo Scrum se
inspecciona a sí mismo
Se actualiza el DoD para
incrementar la calidad del
producto
Inspeccionar el Product
Backlog y las fechas
probables de entrega
Una demo para enseñar el
producto a los interesados
Inspeccionar cómo fue el Sprint con
respecto a personas y relaciones
Inspeccionar los cambios del mercado y
potencial uso del producto
Actualizar el Product
Backlog
Reunión del estado para
el “steering committee”

Equipo Scrum +
Interesados invitados
por el PO
Máximo 4 horas para
Sprints de 1 mes
Debatir cómo dar
más valor
No es una
demostración
Es una sesión de
colaboración
Sprint Review: Características
Características de Sprint Review

El PO invita a los stakeholder que considere clave para la
sesión
Product Backlog
Incremento
Estado del Mercado
El PO habla sobre estado del Product Backlog
Product Backlog
Actualizado
El PO Expone qué elementos terminados y qué elementos no.
El DT Habla sobre que estuvo bien en el Sprint, qué problemas
se dieron y cómo se resolvieron.
A continuación, se enseña el trabajo finalizado y responde
dudas sobre el incremento.
(Opcional) el PO podrá hacer proyecciones de posibles fechas
de entrega en función de la velocidad del DT.
El grupo colabora sobre qué hacer a continuación.
Revisión del mercado o el uso potencial del producto para
saber qué es lo más valioso
Revisión de la línea de tiempo, presupuestos, capacidades
potenciales y mercado para la próxima entrega

Eres el Scrum Master de un equipo que tiene Sprints de 3 semanas. Durante la Sprint
Review el Product Owner decide que el incremento va a subir a producción al inicio del
siguiente Sprint.
Los stakeholders sugieren que ya no se hagan más Sprints para poder reaccionar más
rápido al feedback del usuario (y las incidencias) que se producirán al subir a producción. El
Product Owner prefiere seguir haciendo Sprints para progresar hacia la siguiente Release.
Tu facilitas la discusión.
¿Qué resultados aceptables podrían salir de la discusión?

Eres Scrum Master para un nuevo cliente que es nuevo en Scrum. Es la retrospectiva del 4º
Sprint y la Product Owner no ha venido a ninguna.
Hablas con ella y afirma que solo debe ir si la invitan y que por eso no ha ido nunca.
¿Qué topics saldrán en la retrospectiva?
¿Debe ir un Product Owner a la Retrospectiva?

Inspeccionarse a sí mismo
Scrum Master es un miembro más
Plan de mejoras para el siguiente
Sprint
3 horas por Sprint de un mes
Sprint Retrospective: Características

Propósitos
Inspeccionar:
personas
relaciones
procesos
herramientas
Adaptar la
Definition of Done
para mejorar la
calidad
Enfocado para
inspección y
adaptación
Crear un plan de
mejoras
Sprint Retrospective: Propósitos

Roles Artefactos
Eventos
Scrum es un framework

Te acaban de asignar como Scrum Master para un producto en el que hay 2 equipos Scrums.
Pides acceder al Product Backlog para estudiar el producto y la respuesta del equipo te
sorprende ¡Tenemos dos Product Backlog!
¿Qué problema se podría presentar? ¿Cómo son las prioridades en este equipo?

Compuesto por items:
características, funcionalidades,
requisitos y mejoras
Backlog existe mientras exista el
producto
Dueño es el Product Owner
Dinámico: evoluciona con lo que
necesita el producto
Puede haber varios equipos pero
solo 1 backlog
Incompleto: refleja los requisitos
conocidos y mejor entendidos
Product Backlog

Product backlog
Sprint 1
Sprint 2+3
Sprint 4 +
Requisitos más claros y
mejor entendidos
Continuamente “refinado”
Product Backlog

Estás trabajando como Scrum Master para un nuevo portal web. Has enseñado a tu Product
Owner el Product Backlog y le has ayudado a definir los items.
Sin embargo, descubres que no tiene claro cómo priorizar y observas que está teniendo
problemas.
¿Qué acción debes tomar?

Product backlog
5
20
High
Low
Priority
Eliminar
Insertar item
Estimar & Ajustar
Repriorizar
Dividir
Refinement

Sprint backlog
Sprint Backlog
Artefactos

Eres el Scrum Master de un nuevo equipo en Scrum. Durante el Sprint detectas que el
Development Team no está actualizando el Sprint Backlog. Cuando hablamos con el equipo
ellos dicen que no es su trabajo.
¿Quién es el responsable del seguimiento del Sprint?

Product backlog
Dueño:
equipo de
desarrollo
Predicción del
próximo
incremento
“terminado”
Nivel de detalle
suficiente para el
Dev. Team
Muestra el
progreso y se
actualiza a medida
que tenemos más
conocimientos
Sprint Backlog, el Cómo
Plan sobre
CÓMO se
conseguirá el
objetivo del
Sprint
Sprint Board
Product
Backlog TODO DOING DONE
ITEM 1
ITEM 2
ITEM 3
ITEM 4
Mejora de proceso
de alta prioridad de
la retrospectiva
anterior

Billy es miembro de un Development Team y está discutiendo con un compañero. Él asegura
que cuando un miembro del equipo mueve una tarea a Doing en el “Jira” entonces se asigna
la tarea y pasa a ser responsable de la misma. Su compañero asegura que el reparto de
tareas se debería hacer en la Daily Scrum.
¿Cuando los miembros del Development Team son propietarios de una tarea del Sprint
Backlog?

Estás en mitad de un Sprint conversando con un miembro del Development Team. Esta
compañera te indica que ha detectado un nuevo trabajo que habrá que realizar para alcanzar
el Sprint Goal.
Tu le preguntas el motivo de porqué aún no lo ha añadido al Sprint Backlog a lo que contesta
“Mañana en la Daily Scrum cuando mis compañeros lo aprueben”
¿Es correcto este comportamiento?

Suma de todos los
elementos del Backlog
completados
Suma del VALOR de los
elementos del backlog
completados
El incremento es sobre
elementos “terminados”
(cumplen la DoD)
El incremento debe estar
en condiciones de ser
usable (aunque el PO
decida no subirlo)
El incremento

Durante el Sprint Review, el equipo de desarrollo discute una nueva feature. La feature funciona
bien, pero no pasó los criterios de rendimiento fijados en la Definition of Done.
El equipo considera que puede realizar este reto técnico durante el siguiente Sprint, y confía en que
el Sistema soportará la carga durante los próximos 2 Sprints.
¿Qué harías?
Dado que es una feature por la que nuestros clientes están dispuestos a pagar, el Product Owner
decide liberarla.
Principios

Trabajo sin terminar es deuda técnica
Tiempo para
realizar nuevas
“features”
Tiempo
destinado a la
deuda técnica y a
la complejidad

Deuda técnica es un problema grave
Clientes demandan y esperan
que esté en fecha
Desarrolladores consciente o
inconscientemente recortar la
calidad
Clientes y desarrolladores se
resienten de la profesión
Fallan los productos y fallan las
compañías

Defectos
Falta de tests unitarios
Pocos tests de
aceptación
Falta de automatización
en la construcción y
despliegue
Código muy dependiente
Código duplicado
Código muy complejo
Lógica de negocio en mal
sitio
Errores en la
nomenclatura
Ejemplos de Deuda Técnica

La empresa XYZ está construyendo productos para salvar la vida de sus usuarios.
Tu equipo Scrum está trabajando en una versión del firmware de un producto
¿Qué contendría tu definition of done? ¿Es suficiente?
Hacéis 2 semanas de Sprint. El equipo tiene todas las skills para desarrollar incrementos de producto
terminados.
Definiendo “hecho”

Pruebas de Rendimiento
Test de respuesta
inmunológica
Pruebas de Estabilidad Refactorización
Notas de la versión
Internacionalizado en seis
culturas donde el producto
podría ser vendido
Test de Regresión
Test de aceptación de
usuarios
Documentación de Usuario
Revisión de código
¿Contenía tu DoD estos casos?

DoD = Listo para Subida
DoD completo:
- Sostenibilidad
- Cohesión
- Mantenibilidad
Incremento en cada
Sprint & evitar
sorpresas
Done para todo el
producto (no solo el
incremento)
Definition of Done proporciona transparencia

El Product Owner de un nuevo producto que se va a desarrollar durante la primera Sprint
Planning comenta que le gustaría que la aplicación funcionara rápidamente.
El Development Team responde que lo construirán lo mejor posible para que vaya lo más
rápido posible. Además, proponen que el último Sprint antes de la entrega acometerán las
pruebas.
¿Qué problema se podrían encontrar? ¿Cómo gestionamos los requisitos no funcionales?

No tendremos una
velocidad estable sobre la
que estimar
El Product Backlog
probablemente no estará
en buena forma
Nuestro burn-down será
incorrecto
Nuestro PO no conocerá el
progreso o el estado
El equipo de desarrollo no
sabrá cuanto alcance
seleccionar
En la review el PO no sabe
que está siendo
inspeccionado
Sin Definition of Done

Estás trabajando en un Scrum Team al que le queda poco para subir a Producción. El PO dice
que cuando acabe el presente Sprint le gustaría subir porque su jefe le está presionando.
Durante la planning el PO manifiesta que necesita 30 PBIs pero el Dev Team asegura que
cumpliendo la DoD solo podrán alcanzar unos 15.
El Product Owner les pide que no cumplan la DoD, ya lo arreglarán más adelante.
¿Qué podría ocasionar esta decisión?

El Sprint actual termina mañana. Estás ayudando al Product Owner a preparar la Sprint
Review cuando un miembro del equipo te llama. Ha estado trabajando en una Historia de
Usuario muy grande (40 puntos). Él dice que ya está terminada aunque no cumpla los test y
que considera que se debe presentar la funcionalidad y contabilizar los puntos en la
velocidad, de lo contrario habría un trabajo invisible que se ha realizado que no se estaría
teniendo en cuenta.
¿Qué hacemos con los PBIs que no cumplen la DoD?
¿Cómo afectan estos PBIs a la velocidad?

Cierto Falso
Un equipo debe estar sentados juntos
Un equipo de desarrollo no puede ser menor de 3 personas
Un equipo de desarrollo no puede ser mayor de 9 personas
Cada miembro del equipo de desarrollo debe ser capaz de abordar cualquier tipo de
tarea
Si un equipo Scrum consulta a personas externas o recursos, entonces ellos no están
autoorganizados
Todos los miembros del equipo de desarrollo necesitan estar presentes en el equipo
“full time”
Un equipo Scrum debe tener claro los subroles (coder, tester, analyst, etc) y rendir
cuentas
Un equipo de componentes (back, front, etc) no es Scrum
Cierto o Falso

Algunas ideas para
motivar
¿Cómo conseguir motivar?

El dinero es importante pero es un
“carrot and stick”
solo funciona para trabajos mecánicos
No funciona para trabajos complejos o
creativos...
¿Cómo conseguir motivar de verdad?
¿Cómo conseguir motivar?

Maestría
ser cada vez mejor en mi trabajo
Autonomía
0rganizar mi propio trabajo
Propósito
ser trascendente

Casos de éxito: El desfile militar:
Trascendencia

WestPointg 1963
Westpoint 1963

24 compañías desfilaban
cada dos semanas
Al finalizar los
responsables de cada
grupo se votaban entre
ellos
Había cierto “pique” tras 2
siglos de desfiles
La compañía L2 llevaba 1
siglo quedando la última
Características

Poner en sitios visibles los
errores cometidos
No había culpa, no había
castigo. Solo información
sacada de las evaluaciones
“Charlie lleva la espada
arrastrando”
“Jim no se giró en sincronía”
“El saludo de Dave fue
bastante chapucero”
El plan

“ ustedes son la levadura que une todo
tejido de nuestro sistema nacional de
defensa. De entre sus filas han salido los
grandes capitanes que tienen en sus manos
el destino de la nación cuando suenan las
campanas de la guerra
La larga línea gris nunca nos ha fallado. Si
ustedes lo hicieran, un millón de espectros
de color verde olivo, caqui pardo, azul y gris,
se levantarían de sus blancas tumbas,
haciendo resonar aquellas palabras mágicas:
Deber, honor y patria
La trascendencia

Eres el Scrum Master de 3 equipos. Los 3 equipos tienen el mismo Product Backlog, tiene el
mismo Product Owner y comparten el código.
Los equipos de desarrollo comentan que en los próximos 3 Sprints quieren trabajar en el mismo
área de la Base de Datos
¿Qué sugerirías?
Sólo hay una persona DBA que conoce ese subesquema bien. Los 3 equipos necesitan a Cindy Full-
Time.
Problema

El equipo sigue órdenes
El equipo decide sobre su trabajo diario y gestiona su
progreso
El equipo gestiona su entorno de trabajo
El equipo decide sobre producto, visión y requisitos
El equipo decide en qué productos trabajar
El equipo decide sobre su composición
El equipo decide sobre incentivos y recompensas
El equipo decide sobre su misión, objetivos y dirección.
El equipo decide sobre maneras de conseguir sus objetivos
Company
Team
Product
Work
None
Algunas áreas de autoorganización

Te acaban de asignar a un gran producto que está desarrollando la empresa XYZ. Es
producto va a contener unos 100 desarrolladores que van a ser agrupados en equipos. El
Manager de contratación te convoca a una reunión llamada “Organización de equipos”.
En la reunión un manager propone hacer una matriz de habilidades entre todo el mundo
para cuadrar a las personas. Otra persona propone que se hagan rotaciones entre equipos.
El tercero propone estudiar quienes han trabajado antes y tratar de agruparlos.
¿Cómo deberían gestionarse el reparto de personas en los equipos?

No se queda trabajo sin acabar y
sin saber
Un equipo de desarrollo debe tener todas las skill
(habilidades) para llevar al Product Backlog en un
incremento de trabajo
Con una visión vertical el trabajo se
orienta a completar funcionalidad Cada Sprint se entrega
incremento (no hay que
esperar)
Composición de equipos

Comportamientos que promueven el
trabajo en equipo y la cohesión entre
los miembros
Comportamientos contraproducentes
para el trabajo en equipo y la cohesión
Green Zone Red Zone
Comportamientos de Equipo

Green Zone Red Zone
- Escuchar, responder
- Habla no defensiva
- Abierto, sin amenazar
- Firme, pero no rígido
- Da la bienvenida al feedback
- Éxito compartido
- Colaboración
- Transmiten, no reciben
- Responden defensivamente
- Sensación de agravio
- Batallas y antagonismos
- Toman todo a lo personal
- Perspectiva de un enemigo
- Auto promoción
Pensamiento compartido

Forming Storming Norming Performing
● Construir rutinas
● Centrados en las
formalidades
● Observación
● Evitar el conflicto
● Aparecen las
diferencias
● Crece la
interdependencia
● Conflictos
● Objetivos de equipo
● Planes en común
● Estándares
● Compromiso
● Autónomos
● No necesitan
supervisión
● Se puede disentir
para mejorar
Las 4 etapas de un grupo de desarrollo (Bruce Tuckman)

Eres el Scrum Master de un equipo que lleva 10 Sprints. Casi todo el Development Team
está quejándose del trabajo de un miembro de equipo. Parece que no colabora con el grupo,
se salta los eventos de Scrum y tiene poco interés por el equipo.
¿Quién debe sacar a personas del Development Team?

War
Contienda
Fortificación
Disentimiento Productivo
Armonía total
¿En qué nivel estamos?
Niveles de conflicto

Modos de respuesta ante el conflicto (Thomas Killman)

Ausencia de confianza
Miedo al Conflicto
Evitar rendir cuentas
Falta de atención a los
resultados
Equipo
Falta de compromiso
Las 5 disfunciones de un equipo (Jossey-Bass)

Te encuentras en el Sprint 7 de un producto de medios de pago. Un desarrollador te busca
para contarte que ha encontrado una incidencia grave que afecta a la seguridad de la
aplicación.
¿Qué haces a continuación?

Scrum Master influye de
manera indirecta

Scrum Master
Líder desde el Ejemplo

Crear un entorno seguro
para el debate:
mantenerlo y hacerlo
productivo mediante el
coaching

Mantener la claridad en las decisiones en las
reuniones de equipo

Aprender a leer la sala,
estar conectado sin estar presente.

Recordad al equipo que el conflicto puede ser
sano y beneficioso

Muestra paciencia y silencio, deja que el
equipo entre en acción.

No resuelvas, deja que el equipo aprenda
y enseñarles a aprender y desarrollar
positivamente conflictos.

Siéntete confortable con el resultado de
una decisión (no anticipes sus efectos)

Scrum Master
Muéstrate poco tolerante
con los impedimentos de la
organización.

Estás trabajando para un cliente que es nuevo en Scrum. Este cliente no entiende la
dedicación que tiene que tener el Scrum Master y el Product Owner ya que piensa que están
duplicadas la funciones.
Además, uno de los miembros dice que ha leído que los equipos más avanzados pueden
trabajar sin Scrum Master
¿Qué % de dedicación tienen que tener el Product Owner y el Scrum Mäster?
¿Podemos prescindir del Scrum Master?

Scrum & el papel del Scrum Master
Agile
Empirismo
Roles
Eventos
Artefactos
DoD
People &
Teams
SM
&
Organizaci
ón
Índice

SM y Managers: Cómo
educarlos

Eres el Scrum Master de un equipo y el Product Owner se reúne contigo porque cree que el
Development Team no va a entregar los puntos comprometidos en este Sprint y te pide
ayuda. Ella sugiere añadir recursos al proyecto cuanto antes.
¿Cómo deberías actuar?

Scrum Master
Asumir compromisos
de la cantidad de
trabajo que el equipo
hará en una fecha
concreta

Tratar de convencer al equipo que los compromisos adquiridos en
su nombre son posibles.

Darle dirección al equipo de cómo
implementar los compromisos

Monitorizar el progreso del equipo y
mantenerlo en una planificación

Intervenir y solucionar
problemas si el equipo se
atrasa o encuentra problemas

Actualizaciones semanales de estado

Reuniones 1 a 1 para ver problemas y marcar una
dirección por parte del manager

Dar motivación a base de zanahoria/látigo para
que trabajen duro

Asignar el trabajo y controlar el trabajo que ellos debían
tener hecho

La compañía acaba de contratar a un Manager para una compañía que utiliza Scrum. Dicho
Manager está discutiendo con su jefe sobre sus labores como manager respecto a los
equipos. El manager propone encargarse de medir la productividad del equipo, darle
indicaciones al Product Owner sobre las partes más importantes del producto, gestionar el
personal de los equipos y encargarse de despedir a las personas con bajo rendimiento.
¿Qué te parecen las funciones del Manager? ¿Qué otras funciones podrían ser más
interesantes?

El proyecto donde el equipo Scrum está trabajando lleva retraso.
La presión por parte de la organización, sobre todo el CIO, se incrementa exponencialmente.
Con el objetivo de ganar tiempo y ganar productividad el equipo decide parar de realizar la
retrospectiva.
¿Qué les aconsejarías?
Eliminando residuos para ganar tiempo

Rindiendo cuentas como Scrum Master

Asegurar que Scrum es
entendido y promulgado

Facilitar los eventos de Scrum si son
necesitados o requeridos

Ayudar a todo el mundo a interiorizar la
teoría, prácticas y reglas de Scrum

Líder servicial para el Equipo Scrum

Provoca el cambio que
genera calidad o
productividad

Personifica la agilidad para la organización
ayudando a que cambie

El nuevo Scrum Master de un equipo que es nuevo en Scrum con una organización bastante
tradicional, tras varios Sprint tiene una cantidad muy elevada de impedimentos sin resolver.
¿Cómo le recomendarías que gestione los impedimentos cuando son demasiados?

Acercarse a ...
Coordinar individuos y
sus contribuciones
Proveer respuestas como
experto en la materia
Entrenar a personas en Scrum y en
comportamientos positivos que gradualmente
adquieren los valores de Scrum.
Permitir la autoorganización
dentro de los equipos Scrum
Alejarse de...
Invertir tiempo en resultados
concretos (presupuesto o alcance)
Ayudar a los Product Owners a gestionar
el Product Backlog y a trabajar con los
Stakeholders
Plazos
Preescribir soluciones técnicas
Resolver problemas
Centrarse en generar valor constante para
el Product Owner
Ayudar al Equipo de Desarrollo a entender y
expandir la Definición de Hecho
Guiar al equipo de desarrollo a descubrir
maneras mejores de trabajar para ellos.
Desde el controlador hacia el habilitador

Eres el Scrum Master de un Development Team que ha decidido usar Pair Programming
como técnica de desarrollo. Todos los días los miembros se quejan sobre Frank. Al parecer
cada persona que le toca trabajar con él acaba en discusiones interminables sobre la
arquitectura que habían acordado entre todos. Frank siempre reabre el debate con su par y
vuelve a la misma discusión
¿Cómo actuarías?

Un nuevo equipo Scrum están reunidos para decidir el tamaño del Sprint que van a utilizar
cuando te invitan a la reunión. Unos dicen que quieren Sprints de una semana para poder ir
rápido mientras que otros quieren Sprints de 4 semanas porque así seguro que cumplen la
DoD y les sobrará tiempo de colchón.
¿Qué criterio(s) se debe(n) seguir para determinar el tamaño del Sprint?

¿Hay un equipo Scrum con un Product Owner reconocido, un
Equipo de desarrollo de 3 a 9 personas y un Scrum Master?
Móntalo
Continúa

¿Hay un Product Backlog ordenado?
Enseña a ordenar
Continúa

¿Hay un Sprint backlog que muestra el
trabajo restante en el Sprint?
Enseña a crearlo
Continúa
Prod
uct
backl
og

¿Cada Sprint dura 1 mes o menos?
Enseña a ser
constante
Continúa
Prod
uct
backl
og

¿Hay un entregable con un incremento del
producto cada Sprint?
Enseña la
importancia de la
entrega
Continúa
Prod
uct
backl
og

¿Crea el equipo de Scrum un plan para el
Sprint en la Sprint Planning meeting?
Enseña a
planificar
Continúa
Prod
uct
backl
og

¿El Equipo de desarrollo replanifica cada día en la Daily?
Enseña a hacer
seguimiento
Continúa
Prod
uct
backl
og

¿El incremento es presentado a los
stakeholders en la Sprint Review?
Enseña a
presentar
Continúa
Prod
uct
backl
og

¿El equipo Scrum realiza la Sprint
Retrospective cada Sprint?
Enseña a
hacerlas
Continúa
Prod
uct
backl
og

Scrum con multiequipos
Cuando múltiples equipos construyen un producto,
¿Qué elementos de Scrum podrían compartirse?
¿Qué elementos podrían ser diferentes por equipo?
¿Qué añadirías?

Roles Artefactos Eventos
Product
Owner
Development
Team
Scrum
Master
Product
Backlog
Sprint
Backlog
Incremento
Sprint
Sprint
Planning
Daily
Meeting
Review
Retrospective
Scrum con multiequipos ¿Igual o diferente?

Actualmente trabajas en un equipo de 5 personas que están construyendo un nuevo
producto. Tu Development Team te pregunta cómo les vas a ayudar a coordinar su trabajo
con el otro Development Team. Ellos proponen que compongas un tablero común entre
todas las tareas del equipo, o que visites lo que están haciendo sus compañeros y los
mantengas informados. El Product Owner te pide que se nombre un Lead en cada equipo
para trabajar con él en la coordinación de las tareas de cada equipo.
¿Qué deberías hacer como Scrum Master?

Actualmente trabajas con 3 equipos Scrum que desarrollan el mismo producto con un solo
Product Owner. Ellos proponen que cada equipo presente su parte en una rama distinta del
repositorio.
¿Qué está ocurriendo?

Eres el Scrum Master de un equipo que lleva 5 Sprints trabajando bien. Detectáis que el
Product Owner está empezando a no colaborar con el Development Team. No les dedica
tiempo, no les ayudar a definir bien y cuando hay problema no se lo transmite al
Development Team.
¿Cómo deberías actuar?

Preparando la
Planning
Proporcionar una Estructura Asegurarse que el PO tiene listo el PB

Si el Sprint
Goal fuera un
titular ¿Cuál
sería?
Ejemplo
Estructura
¿Cuál es la
composición
del equipo en
este Sprint?
¿Cuál es la
capacidad del
equipo?
¿Cuáles son
los PBIs de
más valor?
¿Cuáles son los
riesgos de los PBIs?
(técnicos, políticos,
culturales)
¿Qué otras
preocupaciones
tenéis?
¿Cuáles son las historias, condiciones de satisfacción, tareas y
estimaciones de los items que conformarán el Sprint Backlog?
Preparamos un flip chart con
las siguientes preguntas….
Una vez que tenemos todo esto...
Una vez que tenemos todo esto...
¿Han cambiado alguna historia? ¿Alguna ha vuelto al Product
Backlog?
¿Cuál es el compromiso final del Development Team? ¿Esta el
Sprint Goal bien identificado?

Ayudar al
PO
Compromiso del PO Trabajo duro
Sabrás que has terminado cuando los
PBIs de más valor estén en el top
El PO ha hecho todo el trabajo
relacionado con los items
Los items tienen el tamaño bueno
para entrar en un Sprint

Facilitando la
Planning La presión del time-box debería
ayudar a que funcione. Una vez se
arranca la sesión déjales que hablen.
Limítate a observar.
Estate quieto, estás haciendo una
cosa importante, estar callado.
Escucha, mira y mira momentos
donde puedas enseñarles.
Haz preguntas ¿Cuántas de estas
preguntas (del checklist) sabrías decir
la respuesta?
Presiona con el tiempo, “quedan 2
horas”, “queda 1 hora”.

Historia de Usuario
204
Características Historia Usuario:
I Independent – Independiente.
N Negotiable - Negociable.
V Valuable – Valioso.
E Estimable – Estimable.
S Sized appropriately - Tamaño apropiado.
T Testable – Testeable.
<Rol> Quien realiza la acción o recibe el valor de la acción. Persona /
Sistema.
<Funcionalidad> Funcionalidad o actividad que representa la acción a
realizar por el sistema.
<Beneficio> Representa el valor de negocio que se espera generar.
Visualización del consumo diario
Como consumidor, (<rol>) quiero poder ver mi uso diario de energía
(<funcionalidad>)
de modo que pueda comenzar a entender cómo bajar mis costes con el
tiempo (<beneficio>).

Ejemplos de Tareas de una Historia de Usuario
205
- Diseño de la historia de usuario
- Implementación de la historia de usuario
- Pruebas unitarias asociadas a la historia de
usuario
- Pruebas de aceptación asociadas a la historia
de usuario
- Requisitos no funcionales
- Revisión de código
- Refactorización de código
- Mocks y emulaciones de código
- Pruebas exploratorias
- Corrección de errores
- Verificación de errores
- Demostración interna de la historia de usuario
- Actualización de la wiki o info de la US
- Documentación asociada
Buenas prácticas:
- El tamaño de las tareas ha de ser de
entre medio día y 3 días de trabajo
de 1 persona.
- Crear tareas que una vez
completadas generen un producto
entregable (historia narrativa).
- No dedicar excesivo tiempo a estudiar
los detalles de cada tarea (no se
estiman tareas!)
Características Tareas:
S Specific – Específico.
M Measurable – Medible.
A Achievable – Realizable.
R Relevant – Relevante.
T Time-boxed – Limitada.

Estimar todo lo que entra en el Sprint Backlog

El valor de las estimaciones en el Sprint Backlog
El equipo trabaja 8 horas al día = 8 * 10 = 80 horas per/ Sprint.
El total de horas = 10 * 9 * 8 = 720 horas por Sprint.
70 puntos de historia de media en los últimos 5 sprints
¿Cuál es el coste del punto de historia?

Teachable
Moments
¿La US está bien construída?
¿Quién es el usuario real? etc…
Estudiar las mejores historias.
“Qué bonita es esta US… pero ¿Qué valor
aporta? ¿Qué gana un usuario FINAL de
esto?”
Promociona la figura del Product Owner:
uno es dueño del Qué otro del Cómo, crea
límites
A veces los roles se volverán borrosos: el
PO exigirá al DT o el SM se meterá en
mucho detalle técnico. En ese caso pídele
al equipo que quieres volver a tu rol.
El equipo a veces desea entrar ya a dividir
en tareas. Cuidado!, hay que asegurarse
que tienen el conocimiento de negocio.
Usa un Mind-Map para asegurarse los
conocimientos

Facilitando Sprint
Review
Tu papel en la Review es
secundario. Deja que el PO y el DT
muestren el producto a los
stakeholders
Cuidado con perder mucho tiempo
maquillando las presentaciones.
Es mejor invertir tiempo en hacer
producto y no en mostrar el
producto mejor de lo que es.

Recordar el
propósito Hubo un compromiso por parte
del DT, ¿Qué hemos cumplido?
¡Enseña el producto! No uses
PPTs.
Obtén feedback directo ¿Cómo de útil es el
producto? ¿Cumple su propósito? Pregunta a
stakeholders, customers y users.
Ofrece ideas: dales a los stakeholders una
ventana en la que dar ideas sobre cómo el
equipo se organiza y actúa en la organización
(úsalo de entrada para la retrospectiva)
Pide ayuda: Muestra los
problemas que el PO y el SM no
pueden resolver y que los
stakeholders ayuden.

El papel del SM
Durante la reunión tu papel es
insignificante.
Lo hagan bien o mal, no es bueno
intervenir, en vez de eso, observa
y toma notas sobre...
¿Cómo están interactuando?
¿Cuándo alguien habla los demás
observan? ¿Qué efecto provoca?
¿Cómo interactúa el DT y el PO?
¿Y los
Customer/Stakeholders/Users?
¿Hacen peticiones?
¿El PO está usando el PB para
anotar las peticiones? ¿Está
mirando el valor?
¿Alguien fue intimidado? ¿La
gente se pudo expresar?
¿Aparecieron problemas de Agile
en la conversación?
Consejo: Anota las palabras
exactas para después!

Hacer Observaciones
Ejemplos de observaciones que se
pueden hacer después.
“El Sponsor ha venido, ella está aquí,
motivada y receptiva, ¡Esto es
fantástico!”
He notado un gran silencio cuando el
Sponsor ha preguntado ¿Cómo hemos
hecho Agile? ¿Qué pensasteis cada uno
de vosotros?
Un Stakeholders nos pedía más
información. ¿Cuál creéis que es el
origen de esa petición? ¿Qué
preocupación tiene?
He visto que nadie ha mandado emails o
whatsapp durante la review. ¡Eso es
fantástico! Seguro que esto ayudó a los
stakeholders a que vieran lo mucho que os
importa.
PO han habido muchas peticiones de cambio.
¿Cómo gestionaremos el PB ahora para dar el
máximo valor posible?

+ Observaciones
¿Alguién se despistó durante la
reunión? ¿Alguno se evadió mientras
hablaba alguien? ¿Qué hacéis cuando
eso ocurre?
Se habla de meter a alguien en el
equipo ¿Qué opina el equipo sobre esto
y sobre quién debería ser? ¿Quién
tomará la decisión?
Hubo mucho silencio cuando se
empezó a hablar sobre los pasos de la
siguiente release ¿Es correcto?
Había dos stakeholders que siempre
hablaban del mismo topic. ¿Cómo
reaccionasteis?
He visto al Sponsor muy activo
lanzando diferentes mensajes, he oído
“tomate tiempo para que salga bien”,
“hay que estar cerca del customer”.
¿Qué habéis oído vosotros?

Facilitando
Retrospectives
Objetivo es inspección &
adaptación para tomar aire.
Mirar hacia el cómo y no el qué.
Hacer mejor las cosas la próxima
vez.

¿Cómo preparamos
las retrospectivas?

Preparar la
Retrospectiva El mejor consejo es observar el
comportamiento del Scrum Team
¿Está usando el equipo alguna
estructura de Agile?
¿Qué tolera el equipo?
¿Qué funciona bien?
¿Dónde se rompe la
comunicación, la colaboración o la
coordinación?
¿Dónde ocurren los momentos
brillantes?
¿Cómo cambia el nivel de
ansiedad del equipo durante el
Sprint?
¿Están las personas presentes
físicamente, mentalmente y
emocionalmente?

Después de la
retrospectiva
Al finalizar la retrospectiva salen
acciones.
Si ves que se olvidan de las
acciones, recuerdalas durante el
Sprint varias veces.
Si alguien realiza una acción
relacionado con un acuerdo de la
retro, felicitalo.
Si alguien realiza una acción
contraria a un acuerdo de la retro,
no lo dejes pasar. Lanza la
pregunta ¿Qué pasa con este
acuerdo al que llegamos?

Estás trabajando como Scrum Master con un equipo que se encuentra en mitad del Sprint
desarrollando un nuevo producto. El Development Team descubre que no entienden bien un
requisito funcional que pone en peligro la entrega de valor.
El equipo propone hacer solo lo que han entendido, dejar la parte que no entienden para
debatir en la Review y desarrollarlo en el siguiente Sprint.
¿Qué les podrías recomendar?

Conflictos
productivos.
El conflicto existe en los equipos.
Hay varios niveles.
El conflicto puede ser productivo y sano.

Detectar el nivel de
conflicto.
Para detectarlo necesitas pasar mucho
tiempo con el equipo.
No es algo científico
Escuchar las
quejas del
equipo
Sentir la energía
del ambiente
Poniendo foco
en el lenguaje

Nivel 1: Problema
para resolver
Este nivel es el guay, cuando aparecen
problemas los resolvemos rápidamente.
El equipo toma el conflicto de manera abierta
y constructiva
“Ok, te he escuchado pero yo creo que que se
te ha olvidado este detalle…”
“¡Parad! Ya discutimos esto, ¿Qué nueva
información ha aparecido para que lo
volvamos a debatir?
“Ok, ya veo lo que dices ahora, Ok, yo sigo sin
estar de acuerdo contigo porque…”

Nivel 2:
Desacuerdo
En este nivel el equipo se auto-protege.
Las personas hablan en individual y no en
equipo. No actúan de manera agresiva
“Estás haciendo lo mismo que probamos la
semana pasada y no funcionó”
“Sabías que el equipo de soporte no nos
ayudó cuando dijeron que lo harían. ¿Por qué
no nos lo dijiste?”
“Sí, yo rompí la subida, pero deberíamos de
ver los fallos del equipo que son más
importantes que una simple subida”

Nivel 3: Contienda
El ánimo es de vencer, los problemas no se
resuelven, aparecen conflictos políticos.
Aparecen las generalizaciones “él SIEMPRE
se olvida de …”.
“Ella siempre evitar las conversaciones”
“Hoy viene muy amable. ¿Me querrá pedir
algo?”
“Ya ni sé por qué estamos peleando.
Simplemente no nos llevamos bien”

Nivel 4: Cruzada
Resolver la situación no será suficiente. Las
personas piensan que los demás no van a
cambiar. Solo ven como solución sacar a
personas del equipo.
Se crean facciones la gente se ataca entre
ellas en vez de hablar de ideas.
“Él está equivocado, así de claro y simple”
“Necesitamos a más personas en nuestro
lado”
“Nosotros estamos en lo correcto”

Nivel 5: Guerra
No se trata de ganar, se trata de que el otro
pierda.
Aquí la única solución es separar a los
combatientes para que no se hagan daño.
“Tenemos que ganar, no hay otra opción”
“O nosotros o ellos”
“El mundo debe estar prevenido así esto
nunca volverá a pasar”

¿Cómo lo
arreglamos?
Primero… no hagas nada. Los equipos ágiles
deben estar entre el nivel 1 y 3 y ser capaces
de gestionarse.
Analizar y Responder
Usar Estructuras
Revelación
Mejor opción

Analizar
Realiza las siguientes
preguntas
¿Cuál es el
nivel de
conflicto?
¿Cuáles son
los
problemas?
¿Cómo
responderías
como lado
A?
¿Cómo
responderías
como lado
B?
¿Que debería
hacer?
¿Qué
opciones de
resolución
están
abiertos?

Buscar la colaboración (win-win), buscar el consenso
en las decisiones.
Crear un entorno seguro en el equipo para poder
resolver los conflictos.
Dar soporte, empoderizar al equipo para que
resuelvan los problemas.
Negociar: hablar con ambas partes para tratar de
resolverlos.
Accomodar: hacer entender que es más importante la
relación que resolver el problema.
Establece una estructura de seguridad hasta que el
conflicto desescale. Tendrás que usar la diplomacia
entre un grupo y otro.
Haz lo que haga falta para que no se hagan más daño
N5: Guerra
N4 : Cruzada
N3: Contienda
N2: Desacuerdo
N1: Problema para
Resolver
Respuesta

Eres el nuevo Scrum Master para un equipo que desarrolla un importante producto para un
banco inversor. Cuando llegas a la oficina, descubres al CEO hablando con el Development
Team para solicitarles un item urgente que quiere que se haga en el Sprint.
¿Cómo debería reaccionar éste Development Team?

Te acaban de asignar como Scrum Master para un nuevo equipo que comenzará pronto. El
Product Owner es Mark. Mark comenta el utilizar el Inception pero te pide ayuda porque no
sabe cuál debe ser su papel en dicho Inception. Mark propone estudiar la viabilidad
económica de todo el proyecto, construir un Product Backlog completo que vayamos a
construir o estudiar la capacidad de los recursos que van a participar en cada Sprint para
detallar un plan de recursos.
¿Qué papel juega un Product Owner en el Inception?

Motivación del equipo: Técnicas
de visualización y mejoras

Introducción a Scrum
Repaso de expectativas...

Formación Scrum Masters Online alumnos.pptx

Formación Scrum Masters Online alumnos.pptx

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Formación Scrum Masters Online alumnos.pptx

Semelhante a Formación Scrum Masters Online alumnos.pptx (20)

Último

Último (6)

Formación Scrum Masters Online alumnos.pptx