110928 kanban 4.0

Kanban & Scrumban

Madrid, Mayo 2012

© 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

www.slideshare.net/proyectalis
www.linkedin.com/in/angelm
www.presionblogosferica.com
www.proyectalis.com/en/blog


World Agile Conference


¡Un placer!


**
*

Mmmmm…
Almuerzo…


Suficiente para empezar


Ejercicio: serie o
paralelo


Debriefing…


Lean Thinking
“Una manera de pensar que permite a las organizaciones
especificar el valor, alinear las actividades que añaden
valor en la mejor secuencia posible, desarrollar estas
actividades sin interrupción cuando alguien las solicita y
desempeñarlas más y más eficientemente”


Lean Thinking
“Una manera de pensar que permite a las organizaciones
especificar el valor, alinear las actividades que añaden
valor en la mejor secuencia posible, desarrollar estas
actividades sin interrupción cuando alguien las solicita y
desempeñarlas más y más eficientemente”

 Valor máximo al cliente (eliminar desperdicios)
 Optimizar la cadena de valor
 Flow (flujo productivo)
 Pull Systems (producir cuando se necesita)
 Mejora continua

Kanban!
“Los dos pilares del sistema de
producción de Toyota son la
producción Just-in-Time y la
‘automatización con un toque
humano’. La herramienta para
operar este sistema es Kanban.”


Kanban!


kanban

14 Principios Toyota
1. Pensamiento a largo plazo
2. Flujo de proceso que saque problemas a superficie
3. Sistema Pull
4. Heijunka (balanceo de carga)
5. Cultura “stop the line” (Andon / Jidoka)
6. Estandarización y mejora continua (Kaizen)
7. Control visual
8. Tecnologías fiables y probadas
9. Forma líderes
10. Desarrolla personas excepcionales
11. Respeta a suminstradores y colaboradores
12. VE y comprueba por ti mismo (Genchi Genbutsu / Gemba Kaizen)
13. Difiere el compromiso, decide lo más tarde posible
14. Reflexión constante (Hansei) y mejora continua (Kaizen)


Kanban!
1. Pensamiento a largo plazo
2. Flujo de proceso que saque problemas a superficie
3. Sistema Pull
4. Heijunka (balanceo de carga)
5. Cultura “stop the line” (Andon / Jidoka)
6. Estandarización y mejora continua (Kaizen)
7. Control visual
8. Tecnologías fiables y probadas
9. Forma líderes
10. Desarrolla personas excepcionales
11. Respeta a suminstradores y colaboradores
12. Ve y comprueba por ti mismo (Genchi Genbutsu / Gemba Kaizen)
13. Difiere el compromiso, decide lo más tarde posible
14. Reflexión constante (Hansei) y mejora continua (Kaizen)


Kanban


Panel Kanban
Selected Test
Backlog Design Code Done!


¿Por qué funciona?


Una historia sobre los principios


5 principios
 Valor máximo al cliente (eliminar desperdicios)
 Optimizar la cadena de valor
 Flow (flujo productivo)
 Pull Systems
 Mejora continua


Valor
 Definido por el cliente
(maximizar)
 No todo lo que el cliente
paga es valor – actividades
que tienen coste y no
añaden valor al producto
(desperdicio)


Standish
68% proyectos
Group fallidos o problemáticos

59¢ valor por
cada $ de software

64%
funcionalidades no
usadas


La falacia de las 40 hora

Programar (tareas de valor añadido, trabajo
100% (40
en el product, factor de foco, dedicacion
horas por
al Sprint, avance del proyecto…)
semana)


Un modelo más realista:

50%
al Sprint, avance del proyecto…)

Overhead 10%

Bugs, deuda técnica, stoppers, bloqueos, retrabajo,
15%
context switching, otras formas de ‘waste’…
Informes, e-mail, reuniones, entrevistas, trabajo 10%
administrativo, burocracia…

Slack 10%
I+D+I, formación 5%

La cruda verdad:
al Sprint, avance del proyecto…) 35%

Overhead 10%

Bugs, deuda técnica, stoppers, bloqueos, retrabajo, 30%


Slack 10%


La cruda verdad:

Valor
35%

Overhead 10%

Bugs, deuda técnica, stoppers, bloqueos, retrabajo,
30%


Slack 10%

La cruda verdad:

Valor
35%

65%


Ejercicio: identificar desperdicios

MUDA
 Actividades que no añaden valor
 Features no usadas
 Retrasos
 Reuniones
 Hand-offs, burocracias
 WIP, portfolio
 Gold-plating
 Bugs
 Devoluciones, QA al final


MURA
 Ineficiencia por variabilidad del proceso
 Paradas y rearranques
 Cambio de contexto
 Multitarea
 Repriorizaciones
 Cuellos de botella
 Heterogeneidad
 Prescindir de calidad
 Tiempo de ciclo impredecible


MURI
 “No razonable”, ineficiencia por
sobrecarga del proceso
 Plazos de entrega irreales
 Sobrecompromiso
 “No podemos decir NO”
 Horas extra por sistema
 “Wishful thinking”
 “Belief in magic”


Cadena de valor


Code, code, code…! Code, code, code…! Code, code, code…! Code…Done!!

Aclarado!!
Hecha!!

Uhm… Un momento… ¿Se
supone que debe ¡¡Deja lo que Reunión de
Departamento!
comportarse así? estás haciendo y
Necesito una aclaración! haz esta otra
cosa
importantísima!!!


36 horas


Aclarado!!
Hecha!!

Uhm… Un momento… ¿Se
supone que debe ¡¡Deja lo que Reunión de
Departamento!
cosa
importantísima!!!


36 horas


Uhm… Un momento… ¿Se ¡¡Deja lo que Reunión de
supone que debe Departamento!
cosa
importantísima!!!


36 horas


24 horas
(factor eficiencia: 24/36 = 67%)

Uhm… Un momento… ¿Se ¡¡Deja lo que Reunión de
supone que debe Departamento!
cosa
importantísima!!!


Ejercicio: Cadena de valor


Visualizar el flujo de trabajo


Waste!


“Stop the line”
 Política de cero defectos
 Reducción del gasto
 Pensamiento a largo plazo
 Foco en calidad
 Si detectamos un
problema, paramos y
solucionamos


Ejercicio: línea de montaje

B B B BB B BB B C C B B B
C C B B

Proceso A Proceso B Proceso C: Proceso D

First Kanban Game, by Jon Jagger

Flow
Procesos de 1 minuto, 3 procesos consecutivos, lote (batch) de 10 productos

B B B BB B BB B C C
C C

Proceso A: 10 minutos Proceso B: 10 minutos Proceso C: 10 minutos

Lead Time : para todo el lote 30 ++ minutos


Flow

B B B BB B BB B C C
C C



Continous Flow
Lead Time: 12 minutos
“produce uno,
entrega uno” – cero
inventarios

3 min. 12 min.


Flow

B B B BB B BB B C C
C C



INTEGRACIÓN
CONTINUA + LOTES
PEQUEÑOS

3 min. 12 min.


Flow

B B B BB B BB B C C
C C



Ley de Little: tiempo de
ciclo aumenta con el
número de elementos
en curso

AAA BBB CCC (30min)
3 min. 12 min.
ABC ABC ABC (12 min)

Cultura Kaizen
 La mejora es cosa de todos - colaboración
 Visión global, extremo a extremo
 Pensamiento a largo plazo
 Poder para decidir y cuestionar
 Calidad no negociable – Stop the line!
 Tolerancia a fallos
 Intolerancia al desperdicio
 Control visual
 Políticas claras
 Cultura de excelencia – respeto y confianza


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
 Ayuda al sistema a fluir
 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
 No escribimos mas código
del que podemos testear
 No testamos más código
del que podemos
implementar

(Corey Ladas)


Kanban en portfolio

400 días

Backlog Paralelización (“¡Todo es importante!!”)

?


Kanban en portfolio

Backlog

40 días

¿Cuáles son las 5 cosas que más valor nos aportarían
en los próximos 40 días?

?


Kanban en portfolio

1 año en backlog (inventario, muda, muri, eliminar)

40 días

¿Cuáles son las 6 cosas que
más valor nos aportarían en
los próximos 40 días?

?


Ejercicio: Dot Game

By Allan Shalloway

Panel Kanban VSM

Selected Test


Panel Kanban VSM

Test Build Deploy &
Backlog Selected Design Code Release Done!
load test


Panel Kanban VSM

Analysis Client Test
Backlog Selected Design Code Done!
Aproval


Panel Kanban VSM

Selected Test

PRIO


Políticas explícitas

Código J-43745
Ticketing “Como administrador, quiero Descripción
saber quién está conectado en
todo momento para poder
comunicarme con ellos”!
Bck: 3/2/11 BufCount: I I I I I I
Días en colas (una
Tiempos marca por día)
Sel: 9/2/11
Est: 20 25
An: 12/2/11 Re-estimaciones
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11 Seguimiento


Compromiso entrega
Código J-43745 BEFORE: 29/2/11
Ticketing “Como administrador, quiero Descripción
Días en colas (una
Tiempos marca por día)
Sel: 9/2/11
Est: 20 25
An: 12/2/11 Re-estimaciones
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11 Seguimiento


Elementos Kanban

J-43745
“Como administrador, quiero Task! Task! Task!
Bck: 3/2/11 BufCount: I I I I I I Task! Task!
Sel: 9/2/11
Est: 20 25
An: 12/2/11
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11


Elementos Kanban

J-43745
Task! Blocking
“Como administrador, quiero Feature!
Issue!
Change Critical Refactor
Sel: 9/2/11
Est: 20 25 Request! Bug! request!
An: 12/2/11
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11 Non-
Critical
Bug!


Panel Kanban VSM

Selected Test

Critical
Bug!

Feature!
Change
Request!
Refactor
request!
Feature!

PRIO


Panel Kanban VSM

Selected Test

Critical
Bug!

Change
Request!
Refactor
request!
Feature!

PRIO


Panel Kanban
Design Code
Selected Test
Backlog Done!
On On


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


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


WIP limits
Design -4 Code -4
Backlog Done!
On Rdy On Rdy


“Pero es que…”


Cuellos de botella
 Teoría de las limitaciones (ToC)
 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


Cuellos de botella
 Teoría de las limitaciones (ToC)
 Cuidado con pedir “mas recursos” como
primea opción (elevar)
 Subordinar:
 Asegura que el sistema opera al ritmo
del cuello de botella
 Utiliza el “slack” en torno al cuello para
reducir el cuello: forma en nuevas
habilidades, divide el tipo de tareas,
identifica las rutinarias / sencillas…
 Establece rutinas de “Swarming”


Estableciendo WIP Limits
 Muchas opciones:
 2 por persona (o un
poco menos)
 Tantas como personas
en el equipo
 La mitad del equipo
(equipos XP maduros)
 Comenzar por el cuello
de botella, evolucionar
desde ahí


Estableciendo WIP limits

Design Code -1 Test - 1 Design Code Test - 1
Backlog Selected - Done! Backlog Selected - Done!
2 On -1 Rdy On Rdy 2 On -8 Rdy On-10 Rdy

WIP muy bajo WIP muy alto


“Swarming”


Skills Matrix


“Swarming”

 Buscar compromiso entre
eficiencia en cola e ineficiencia al
trabajar todos en lo mismo
(coordinación, dependencias…)
 “9 mujeres embarazadas no dan
a luz a un niño en un mes”
 Sin embargo, técnicas como Pair
Programing, integración continua
o propiedad colectiva de código
aportan una mayor eficiencia que
“cada uno a lo suyo”


Ejercicio: diseñad vuestro Kanban
Design -4 Code
Backlog Done!
On Rdy On -2 Rdy -6


Kanban Planning

 Añadir elementos a
Backlog
 Priorizar Backlog
(triage)
 Analizar release plan
 Seleccionar próximos
Items


Kanban Stand-ups

 Enumerar trabajo de
derecha a izquierda
(Pull)
 Concentrarse en
excepciones
 Cuellos de botella
 Impedimentos
 Bloqueos
 WIP rotos
 Escalados
 Prioridades…


Retrospectivas en Kanban

 Kanban no prescribe
retrospectivas, pero
tampoco las prohibe
 ¿Ayudan las
retrospectivas a hacer
fluir el tablón?
 WIP’s, colas, bloqueos,
políticas, tiempos…


Scrum!

 Añadir “ceremonias” a
Kanban:
 Product / Sprint plan
 Daily Stand Up
 Demo
 Retrospectiva
 Definir un periodo de
tiempo arbitrario como
“Sprint”
 Opcionalmente, medir
velocidad y usar Burn-
down

 Límites WIP
 Terminado-terminado,
estándar de calidad
 Objetivos Lead Time,
Throughput, SLA’s
 Criterios de priorización,
calidades de servicio
 Actuación ante bloqueos o
interrupciones
 Reporte de progreso, criterios
de tablón
 Criterios de branches, builds,
releases
 …….

Design Code Test
- ormal
N Backlog Selected Done!
On Rdy On Rdy On Rdy
- ug
B

SPRINT
- volutivo
E

Atención FIRE!
inmediata
PRIO
Atención
prioritaria

Sólo si hay
buffer y el ASAP
Sprint va bien

- nte
A - est
T
bloqueos, automatizados - oc.
D
ayudar tester antes de ready actualizada
con criterios - eguir
S
aceptación estándar de - 5% coverage
9
- ax. 3 avatars por
M
persona código


Políticas explicitas

 Orden de atención (ej):
 Si puedes ayudar a terminar
algo en curso, haz eso
 Si no puedes, localiza un
cuello de botella y trabaja para
resolverlo
 Si tampoco puedes, coge un
nuevo elemento
 Si tampoco puedes, encuentra
algo interesante a lo que
dedicarte (I+D+I, formación,
deuda técnica…)


Lead time / cycle time
Total Lead Time ~120 días

LEAD TIME ~15 días

Cycle Time ~4 días

Design Code Test
Backlog Selected Done!


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


Algunas ideas para tablones:


WIP compuestos 6

Design Code
Selected - 2 Test
Backlog Done!
On Rdy On -2 Rdy -6


Cola revisión
Design Code - 7
Selected - 2 Test-2
Backlog Done!
On Rdy On -2 Review-2 Rdy -6

- arcar
M
para
retrospect.


Cola revisión
Design Code
Selected - 2 Test
Backlog Done!
On Rdy On -2 Rdy -6


Cola Bloqueos
Design Code - 7
Selected - 2 Test-2
Backlog Done!
On Rdy On -2 Block-2 Rdy -6

- arcar
M
para
retrospect.


Cola integración
Design -4 Code
Selected - 2 Test - 2 Wait
Backlog integration Done!
On Rdy On -2 Rdy -6

Min.

Max. (Go!)

Integraciones
tan frecuentes
como sea
posible


Proveedores
Design -4 Code
Selected - 2 @TEST
Backlog SUPPLIER - 3 Done!
On Rdy On -2 Rdy -6

- Sync. Diaria
- SLA: 3 días
- Marcar todos los
días una raya


Proveedores
Design -4 Code
Selected - 2 Test int. - 2
Backlog Done!
On Rdy On -2 Rdy -6

Test Out. - 4

- ync. Diaria
S
- LA: 3 días
S
- arcar todos los
M
días una raya


Backlog & “Disneyland Queue”
Design -4 Code Test - 2
Backlog - 6 Done!
On Rdy On -2 Rdy -6

1 semana

2 semanas


Pair Programming / widen Job titles
Design Code
Selected - 2 Test
Backlog Done!
On Rdy On -2 Rdy -6


Espacio adicional
Selected - Design -4 Code Test - 2
Backlog Done! Proyecto:
2 On Rdy On -2 Rdy -6 Retro:

1. Necesidad de
Equipo: Scrum, Demo: un Product
Owner
2. Bloqueos en
testing
Burn-down:: 3. Maquinas
nuevas
4. Historias mal
definidas
5. Pair
programming
Release Plan: 6. Piloto Hudson-
Maven

Vacaciones


Througput & Burn-Down

Establecer una cadencia arbitraria


Calidades de servicio
Design Code Test
SPRINT On Rdy On Rdy On Rdy

FIRE!

PRIO

ASAP


Especialistas y generalistas

Design Code Test
SPRINT

FIRE!

PRIO

ASAP


Scrumban
Design Code Test
V Scrum
SPRINT

Sprint Burn-down:

FIRE!

PRIO

V Buffer
Buffer burn-up:

ASAP


Análisis de demanda

Evolutivos Valor
Proyectos (V. Scrum)

Waste (Failure Demand)


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


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


“Olores”


Design Code Test

FIRE!

PRIO

ASAP


Design Client Code Test
Backlog Selected Approval Done!

FIRE!

PRIO

ASAP


J-43745 Alberto
“Como administrador, quiero
Sel: 9/2/11
Est: 20 25
An: 12/2/11
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11


Secuencia-olor…


¿A qué huele…?


Diagrámas de flujo acumulado



Scope Creep

Lead time

WIP



Carga de trabajo (MURI)

Capacidad



Carga de trabajo (MURI)

Ensachamiento =
Cuello de botella, MURA

Capacidad


Conclusiones
 Distinguir kanban de Kanban
 Un sistema Kanban necesita una
cultura Kaizen
 Equipos auto-organizados
 Propiedad del sistema
 Pensamiento sistémico
 Completar trabajo y reducir el
tiempo es tarea de todos


Conclusiones

 El sistema Kanban comienza donde
estas y progresa evolutivamente, un
cambio cada vez
 Una correcta priorización es
esencial
 Si el sistema opera a máxima
capacidad, no tiene sentido
aumentar la carga de trabajo – en
su lugar, trabaja el sistema


Conclusiones

 El foco de un sistema Kanban
está en mejorar el tiempo de
ciclo, la capacidad y la entrega
de valor, no en seguir un plan
 La categorización y
normalización de la demanda
permite no obstante una alta
predictibilidad
 Si el sistema no fluye, no tiene
sentido aumentar los objetos en
cola (inventario)


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, David J.
Anderson, Mattias Skarin, Corey Ladas, Mary
Poppendieck & David Joyce.


Debate: las estimaciones como MUDA


Estimaciones


Cono de Incertidumbre

(Pista: estimar aquí )

Cono de incertidumbre


Estimación no es ESTO:
Probability

Estimation Value


110928 kanban 4.0

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (20)

Similaire à 110928 kanban 4.0

Similaire à 110928 kanban 4.0 (16)

Plus de Proyectalis / Improvement21

Plus de Proyectalis / Improvement21 (20)

110928 kanban 4.0