Agile: Scrum, Kanban y Scrumban

Agile:
Scrum, Kanban y Scrumban

Madrid, Mayo 2011

© 2011 Proyectalis Gestión de Proyectos S.L. – Presentaciones en http://slideshare.net/proyectalis

ngel M edinilla!
Á @proye
c talis.co
m
edinilla
angel.m l_m
@ange


¡Un placer!


Ejercicio: Scrum Ball


Ground
Rules


**
*

Tomad notas

Mmmmm…
Almuerzo…


Suficiente para empezar


Agile


Valores

Principios

Procesos Prácticas

Roles Artefactos

Herramientas


Historia de dos estados

 Statewide Automated Child
Welfare Information System
(SACWIS)
 Florida: comienza 1990,
plan a 8 años, $32M
 2002: $170M, estiman
terminar en 2005, coste
acumulado de $230M

Source: Jim Johnson, Standish Group President, as quoted in “Lean Software Development,” , Mary&Tom Poppendieck

Standish
68% proyectos
Group fallidos o problemáticos

59¢ valor por
cada $ de software

64%
funcionalidades no
usadas


Los desarrolladores en todo el
mundo sufren terriblemente

Círculos viciosos

Retrasos Prisa

Baja
productividad Mala
calidad
Interrupciones

Errores


Círculos viciosos

Retrasos Prisa

Baja
productividad Mala
calidad
Interrupciones

Errores Cliente
Aumento de insatisfecho
costes
Reducción de
beneficios

Círculos viciosos
Sin formación

Presión
Falta de
Retrasos Prisa
competencia

Baja Desmotivación
productividad Mala
calidad
Interrupciones

Errores Cliente
Aumento de insatisfecho
costes
Reducción de
beneficios

Meanwhile, in Minessota
 Esenciamente el mismo sistema, con la misma
funcionalidad, comienzan en 1999
 Terminan a principios de 2000, coste $1.1M

Source: Jim Johnson, Standish Group President, as quoted in “Lean Software Development,” , Mary&Tom Poppendieck

¿Cuestión de suerte?

Suerte
No emplees a gente sin suerte. Tira la mitad de los CV a la basura sin leerlos.


Principios:
 Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
 Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
 Entregamos software funcional frecuentemente, entre dos semanas y dos
meses, con preferencia al periodo de tiempo más corto posible.


Principios:
 Los responsables de negocio y los desarrolladores trabajamos juntos de
forma cotidiana durante todo el proyecto.
 Los proyectos se desarrollan en torno a individuos motivados. Hay que
darles el entorno y el apoyo que necesitan, y confiarles la ejecución del
trabajo.
 El método más eficiente y efectivo de comunicar información al equipo de
desarrollo y entre sus miembros es la conversación cara a cara.


Principios:
 El software funcionando es la medida principal de progreso.
 Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,
desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
 La atención continua a la excelencia técnica y al buen diseño mejora la
Agilidad.


Principios:
 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.
 Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-
organizados.
 A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para
a continuación ajustar y perfeccionar su comportamiento en consecuencia.


Agile101
Estimate

Ouch!
R1.0 ¿R2.0?
Estimate BV

Replan R1.0 ¿R2.0? t

Agile101
- quipo auto-organizado y motivado
E
Estimate - rabajando a paso sostenible
T
- olaborando con cliente y personal de
C
negocio de forma cotidiana
- omunicándose cara a cara
C
- ersiguiendo la excelencia técnica
P
- eflexionando sobre como mejorar y
R
Ouch! eliminar el desperdicio

R1.0 ¿R2.0?
Estimate BV

Replan R1.0 ¿R2.0? t

Ideas simples…


Pero Valores
recordad:
Principios

Procesos Prácticas

Roles Artefactos

Herramientas


Reglas


Primera regla

Tiempo Alcance

?
Recursos

Bueno, bonito, barato… ¡Elije dos!


Buffers de proyecto
60% proyecto consumido

80% proyecto consumido

Buffer

Min T Max T

 Monitorizar velocidad de consumo del buffer
 Aprendemos sobre el “global” del proyecto
 Los “paddings” no quedan ocultos

Tradicional vs. Ágil

Fijar: Alcance Coste Tiempo

Orientación
a Valor

Orientación
a Plan

Estimar: Coste Tiempo Alcance


Segunda regla

El cambio es la única constante

Cono de Incertidumbre

(Pista: estimar aquí )

Cono de incertidumbre


Precisión vs tiempo

Suficientemente
buena


Incertidumbre


Gedanken: el P.O. perfecto

…..


Histograma


Histograma
Norma


Histograma
Norma

95% SLA
80% SLA


Proyectos dispares

 Con tallas de camiseta (para
tamaño de peticiones)
 Distintos histogramas:
 XS – 3 días
 S – 40 días
 M – 90días
 L – 150 días
 XL – 220 días


Tercera regla
Requisitos

Tecnología
Es complejo (quizás imposible) caracterizar
perfectamente a priori un sistema software

Software
no es
ESTO:


Software
es ESTO:


Ejercicio: círculo humano


El proceso empírico

© 2006-2007 Jeff Patton, www.agileproductdesgin.com

Walking Skeleton:
1 2 3

1 2 3

© 2006-2008 Jeff Patton, www.agileproductdesgin.com

“Empirico” no quiere decir…

Un sistema empírico


Scrum


Una herencia aciaga
Politicas
Procedimientos
ISO Procesos Trabajadores
CMMI Control insatisfechos
TQM
Inspección
EFQM
Supervisión
ITIL
PMBOK Burocracia
PRINCE2 Papeles
… Más papeles
Todavía más
papeles…


Thin is In


El nombre:


Qué usan los equipos Ágiles:

5thAnnual ”State of
Agile Development”
Survey, 2010


Algunas empresas haciendo Scrum:


Que NO es Scrum


Scrum 101


Scrum 101
Previsión

Ouch!
R1.0 ¿R2.0?
Previsión BV

Replanificación R1.0 ¿R2.0? t

Scrum 101
Stakeholders
Dueño de Equipo
Producto
?

Pila
Sprint
Scrum
Master

Pila de Producto

El framework:


Estructura Scrum / Multiproducto

?

? ?

? ?


Mountain Goat: 243 personas


“Scrum de Scrums”

Team Team Team
A B C
Team
A
Team
B
Team
C


Comunidades de práctica

?

? ?

? ?


Ejercicio:
burning man project


“El énfasis está en conducir el proyecto – que es bastante
sencillo- en lugar de obtener una predicción exacta de
qué hará falta y cuánto durará – lo cuál es muy dificil”
Ron Jeffries, XP co-founder


Velocidad

Min. V Esto seguro que lo hacemos

Probablemente acabemos en
algún sitio por aquí
Max. V

¿Te estás quedando conmigo o qué?


Campana de Gauss
Peor caso: mínimo
alcance (o máximo
tiempo)

Min. V

Predicción / estimación

Max. V

Mejor caso: máximo
alcance (mínimo
tiempo)


Capacidad
105
100
100
+5 -5 -25 -32 -46 -46 -59 -70 -70

93
90 90

86 86
80
80
¡¡900 puntos en 9
semanas!!


Capacidad
105
100
100
+15 +5 +5 -5 -2 -6 +4 +0 +0 +10

93
90 90

86 86
80
80
¡¡Entre 700 y 900
¡¡900 puntos entre puntos en 9
9 y 11 semanas!!
semanas!!


Nuestras 10 reglas de Scrum:
1. Individuos
2. No es una bala de plata
3. Retrospectivas, retrospectivas,
retrospectivas
4. Scrum diario, control diario
5. El producto funcional es la medida
de progreso.
6. Equipos auto-organizados, auto-
gestionados y comprometidos:
Scrum Master no es un jefe, sino un
sirviente del equipo
7. Desarrollo iterativo e incremental


8) “Terminado,
terminado”


9) “Orcos a las puertas”

?


10) “El horno de las
magdalenas”

?


“El horno de las magdalenas”

+3 !!
!!

?


Las opciones del horno
 Poner el bizcocho en cola
(puede afectar al valor)
 Retrasar las magdalenas
rojas y poner el bizcocho en
su lugar (clientes iguales)
 Poner el bizcocho al principio
(cliente prioritario, retrasa
todo el portfolio)
?
 Reservar una capacidad extra
para imprevistos (Scrumban)
 Cambios de contexto, exigir
esfuerzos, tirar calidad (no
Agile)


Estos diez mandamientos se cierran
en uno:

¡Time Boxing!


Scrum Framework

Pila de Producto Pila de Sprint Dueño de Producto

Scrum Master
Tablón Scrum Artefactos Roles
Equipo
Pila de impedimentos

Retrospectivas Procesos Demo

Plan de Producto Plan de Sprint Scrum diario


Los roles:


Dueño de  Gestiona la visión y el
Producto Roadmap
 Recopila requisitos, escribe
historias de usuario
 Gestiona la Pila de Producto:
decide alcance y prioridad
 Define criterios de aceptación
para cada historia y valida
 Responsable de satisfacción del
cliente y éxito financiero
 Interfaz de negocio con Scrum
 “Cerdo con plumas”


Dueño de 1. ESCRIBIR HISTORIAS
Producto 2. PRIORIZAR HISTORIAS
3. VALIDAR HISTORIAS


 Realiza estimaciones, reporta progreso
 Comprometidos con la entrega de
software funcional al final del sprint
Equipo
 Cross-funcional, auto-gestionado
 Responsable de calidad y velocidad
 7±2 personas (“feed them two pizzas”)


1. ESTIMAR HISTORIAS
2. CONSTRUIR HISTORIAS
Equipo 3. REPORTAR PROGRESO


 “Perro pastor”, siervo lider,
Coach
Scrum  Cercano al equipo
 Mantiene el proceso
Master
 Gestiona pila de
impedimentos
 Hace mejorar al equipo
 Mejora la vida del equipo
 Moderador - facilitador
 Si es necesario, actua como
interfaz del Dueño de
Producto


1. MEJORAR RENDIMIENTO
2. MEJORAR CALIDAD DE VIDA
Scrum 3. MANTENET Y MEJORAR EL
PROCESO
Master


Evolución del Scrum Master
“El tío del
Scrum”
ScrumButt Scrum Agile Nirvana

- onvocar
C
reuniones
- istar
L
problemas


“El tío del “Mama
Scrum” Scrum”

- onvocar
C - Ya me encargo yo”
“
reuniones - oderador
M
- istar
L - iagnostica y decide
D
problemas - limina
E
impedimentos
- nterfaz del equipo
I
- vitar el conflicto
E
(armonía artificial)
- oordinación,
C
cooperación
- o confía del todo en
N
el equipo, aun algo
“Jefe”

“El tío del “Mama Auténtico Scrum
Scrum” Scrum” Master

- onvocar
“ - Formador, mentor
M - acilitador
F
- istar
D - otivador
M
problemas - limina
E - ardinero del equipo
J
impedimentos - mplica a todos
I
I - elegación progresica
D
E - olaboración
C
(armonía artificial) - Innovación
- oordinación,
C - rata el conflicto
T
cooperación
- gente del cambio
A
N
- vangelista Ágil
E
el equipo, aun algo
“Jefe” - ider
L

“El tío del “Mama Auténtico Scrum Scrum Sensei –
Scrum” Scrum” Master Agile Coach

- onvocar
“ - Formador, mentor - Escucha
M - acilitador
F - omina el silencio
D
- istar
D - otivador
M - regunta
P
problemas - limina
E - ardinero del equipo
J - s un espejo
E
impedimentos - mplica a todos
I
I - elegación progresica
D
E - olaboración
C
(armonía artificial) - Innovación
- oordinación,
C - rata el conflicto
T
cooperación
- gente del cambio
A
N
- vangelista Ágil
E
el equipo, aun algo
“Jefe” - ider
L

“El tío del Scrum Sensei –
Scrum” Agile Coach

- onvocar
C - Escucha
reuniones - omina el silencio
D
- istar
L - regunta
P
problemas - s un espejo
E



Decide Vende Consulta Participa Aconseja Pregunta Delega



Estimar
historias
Duración
Sprint
Definition
of done
Miembros de
equipo
Estrategia de
negocio



Estimar
TEAM
historias
Duración SM
Sprint
Definition PO
of done
Miembros de Manager
equipo
Estrategia de
Manager
negocio


Coach (leader?)
C&C
Estimar
TEAM
historias
Duración SM
Sprint
Definition PO
of done
Miembros de Manager
equipo
Estrategia de
Manager
negocio


Procesos


Planificación de producto


La Pila Iceberg

Sprint

Producto

Version


Planificación de Sprint


Scrum diario

Demo


Retrospectiva


Artefactos


Tablón scrum
Historia Pendiente Desarrollo Test Terminado
Proyecto:

Equipo: Scrum, Demo:

Burn-down::

Release Plan:

Impedimentos:


“Olores”


Historia Pendiente Desarrollo Test Terminado
Proyecto:

Equipo: Scrum, Demo:

Burn-down::

Release Plan:

Impedimentos:


Burn-down
Trabajo

KO!

OK!

Tiempo


Release Plan


Trabajo

Tiempo


Trabajo

Historias

Tiempo


Proyecto Rodriguez
 Lavar platos
 Pasear al perro
 Cortar el cesped
 Regar las plantas
 Hacer las camas
 Colada
 Planchar
 Limpiar el horno
 Compra del mes
 Compra frutería
 Limpiar los suelos
 Limpiar ventanas
 Pintar dormitorio

Planning Poker


Kanban

Ejercicio: serie o
paralelo


Kanban
 Comienza donde estés
 Visualiza el flujo de valor
 Limita el WIP (ajusta carga
a capacidad)
 Mide y mejora el tiempo de
entrega / tiempo de ciclo
 Haz las reglas explícitas
(definición de terminado,
WIP limits, estándar de
código, bloqueos…)


Kanban
 Empezar menos cosas
 Acabar más cosas
 Reducir el número de
cosas en curso para
reducir el tiempo de
entrega
 En caso de bloqueos o
ralentizaciones, liberar
recursos para resolver el
problema


Kanban
 No construimos
funcionalidades que nadie
necesita ahora mismo
 No escribimos más
especificaciones de las que
podemos construir
(backlogs interminables)
 No escribimos mas código
del que podemos testear
 No testamos más código
del que podemos
implementar

(Corey Ladas)


Capacidad
50l/sg
20/sg

10l/sg

100/sg

30/sg


Capacidad
- Antiguo troughput: 10
50l/sg - Nuevo troughput: 11 (10% ok)
- Coste: 16
22/sg

11l/sg

¡¡+10%!! 110/sg

33/sg


Capacidad
- Antiguo troughput: 10
50 23l/sg - Nuevo troughput: 23 (130%)
- Ajusta carga a capacidad
23/sg
- Coste: 16

- I+D+i
23l/sg - Deuda técnica
- Desacople
¡Kaizen! 100l/sg

33l/sg


Colas
Design Code
Selected Test
Backlog Done!
On Rdy On Rdy


WIP limits
Design -4 Code -4
Selected - 2 Test - 2
Backlog Done!
On Rdy On Rdy


Colas + WIP limits
Design -4 Code
Selected - 2 Test - 2
Backlog Done!
On Rdy On -2 Rdy -6


Cuellos de botella
 Cuidado con pedir “mas recursos” como primea
opción (elevar)
 Explotar:
 Asegúrate que el cuello de botella opera al
máximo de capacidad (elimina tareas
superfluas / waste)
 Asegura que la entrada a tu cuello de botella es
de buena calidad
 Asegura que tu cuello de botella no pasa tiempo
detenido / bloqueado
 Asegura que existe una priorización correcta
 Subordinar:
 Asegura que el sistema opera al ritmo del cuello
de botella
 Utiliza el “slack” en torno al cuello para reducir
el cuello

“Stop the line”
 Política de cero defectos
 Reducción del gasto
 Pensamiento a largo plazo
 Foco en calidad


Kanban

Scrumban

The 40 hour week fallacy:

Programming (value adding tasks, focus
100% (40
factor, sprint dedication, project
hours a
advance…)
week)


A more realistic approach:

Programming ( value adding tasks, focus
factor, sprint dedication, project 50%
advance…)

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework,
15%
context switching, other forms of waste…
Reports, e-mail, internal meetings, hiring interviews, 10%
admininistrative stuff, bureaucracy…

Slack 10%
Research, Development, training, innovation 5%

Naked truth:

Programming ( value adding tasks, focus
factor, sprint dedication, project 35%
advance…)

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework, 30%


Slack 10%

Naked truth:

Scrum (measured & known)
35%

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework, 30%


Slack 10%

Naked truth:

Scrum (measured & known)
35%

65%


Scrumbam
Burn-down::

Pending Selected. Dev. Valid. Integration Done!

Release Plan:


Scrumbam
Burn-down::


Release Plan:

! ! ! !


Velocity

?
?


Scrumbam
Pending Selected. Dev. Valid. Integration Done! Burn-down::

Release Plan:



Scrumbam
Burn-down::

Release Plan:


5

1

Esto ha sido un
tres…


Scrumbam

V Scrum


V Buffer


V Scrum V Buffer
80 20
85 20
75 30
70 35
75 25
80 25
? ?

¿Vuestra predicción?


V Scrum V Buffer
80 20 Uuuh… Buenos, de
media hacemos algo así
85 20 como 75 scrum points
75 30 por sprint. Supongo que
70 35 nos podemos
comprometer a eso
75 25 mientras mantengas el
80 25 Buffer bajo control…
? ? Eso significa no
pasar de 25 Buffer
points


V Scrum V Buffer
80 20
85 20
75 30
70 35
75 25
! 80 25
60 50

Yaaargh!
¡Habéis faltado
a vuestra
promesa!


V Scrum V Buffer
80 20 No, de hecho hemos
85 20 hecho 110 puntos de
velocidad agregada,
75 30 que no está nada mal.
70 35 TÚ nos priorizaste 50
puntos Buffer durante el
75 25
! 80 25
Sprint y nos hiciste fallar
el objetivo
60 50


Scrumbam

V Scrum


V Buffer +

V Buffer -


Scrumbam

Vavg Buffer+ Velocity
Vavg Scrum

Vavg Buffer-


Scrumbam
Burn-down::

Release Plan:


? ?? ?


Scrumbam
Burn-down::
COMMITTED

Release Plan:

Fire!
PRIO
ASAP


Scrumbam
Burn-down::
COMMITTED

Release Plan:

Fire!
PRIO

¿¿Eso ha sido
ASAP

un fuego??

Para nada…
oh-oh… Hora de hacer
coaching al
P.O.


Burn-down::

COMMITTED

Release Plan:

Fire!
Prio
ASAP


Dev. Done! Sprint Burn-down:
Pending Selected. Valid. Integration

COMMITTED

Fire!
Buffer Burn-down:
Prio
ASAP

Mmm…Supongo Uh-oh, parad el
que tampoco buffer, tíos!!
estaría mal hacer
algo de Scrum…


Dev. Done! Sprint Burn-down:
Pending Selected. Valid. Integration

COMMITTED

Fire!
Buffer Burn-up:
Prio
ASAP

Mmm…Supongo Uh-oh, parad el
que tampoco buffer, tíos!!
estaría mal hacer
algo de Scrum…


V Scrum V Buffer
80 7500 Uuuh… Buenos, de
media hacemos algo así
85 7000 como 75 scrum points
75 8000 por sprint. Supongo que
70 8500 nos podemos
comprometer a eso
75 7500 mientras mantengas el
80 7000 Buffer bajo control…
? ? Eso significa no
pasar de 7500
¿vuestra predicción? Buffer points


V Scrum V Kanban
80 7500 No, en realidad hemos
85 7000 hecho over-buffering
(50% más de lo
75 8000 habitual). TÚ nos
70 8500 priorizaste 11.200
puntos Buffer durante el
75 7500
! 80 7000
Sprint y nos hiciste fallar
el objetivo
60 11.200

Yaaargh!
Habéis fallado
a vuestra
promesa!


Añade colas y WIP limits!
Design Code Test
Backlog Selected - 3 Done!
On- 3 Rdy On -2 Rdy On - 2 Rdy
SPRINT

FIRE!

PRIO

ASAP


Epílogo


No hay camino…

Conocer el
camino, andar
el camino


¡Aprendamos a nadar!


Read this books!


Retrospectiva
del curso

angel.medinilla@proyectalis.com

¡¡¡¡ Blog It !!!!


http://creativecommons.org/
licenses/by-nc-nd/3.0/

This presentation is based upon
the ideas and work of many
people. And while I’ve tried to
recognize copyrights and give
credit and attribution where
possible, I cannot possibly list
them all, so if you feel like
there’s something that should be
added, changed or removed
from this presentation, please
drop me an e-mail at

Special thanks to Henrik Kniberg, Mike Cohn,
Lyssa Adkyns, Jurgen Appelo, David J.
Anderson, Mary Poppendieck and Jeff Patton.
I owe you so much I’ll have to buy you some
drinks if you ever happen to come to Spain ;).


Agile: Scrum, Kanban y Scrumban

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Agile: Scrum, Kanban y Scrumban

Semelhante a Agile: Scrum, Kanban y Scrumban (20)

Mais de Proyectalis / Improvement21

Mais de Proyectalis / Improvement21 (20)

Último

Último (20)

Agile: Scrum, Kanban y Scrumban