Seminario Kanban y Scrumban

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

Kanban & Scrumban

Madrid, Junio 2011


Ángel [email protected]

@angel_m


¡Un placer!


Ejercicio: Scrum Ball


Ground Rules


* * *


Tomad notas


Open Mind


¡No matéis al mensajero!


Mmmmm… Almuerzo…


Suficiente para empezar


Lean Systems


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”


5 principios

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


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)

Valor


Standish Group

68% proyectos fallidos o problemáticos

64% funcionalidades no usadas

59¢ valor por cada $ de software


Actividades que no añaden valor En manufactura:

Sobreproducción Esperas Transportes Movimiento innecesario Inventario Sobreproceso Defectos Retrabajos

MUDA


Actividades que no añaden valor En IT:

Features no usadas Retrasos Reuniones Hand-offs, burocracias WIP, portfolio Gold-plating Bugs Devoluciones, QA al final

MUDA


Ineficiencia por variabilidad del proceso En manufactura:

Altibajos en producción Retrasos Flujo hacia atrás Cuellos de botella Falta de estándares Atajos oficiales y oficiosos

MURA


Ineficiencia por variabilidad del proceso En IT:

Paradas y rearranques Cambio de contexto Multitarea Repriorizaciones Cuellos de botella Heterogeneidad Prescindir de calidad Tiempo de ciclo impredecible

MURA


“No razonable”, ineficiencia por sobrecarga del proceso

En manufactura: Sobrecarga de maquinaria Sobreexplotación

MURI


“No razonable”, ineficiencia por sobrecarga del proceso

En IT: Plazos de entrega irreales Sobrecompromiso “No podemos decir NO” Horas extra por sistema “Wishful thinking” “Belief in magic”

MURI


Debate: las estimaciones como MUDA


Estimaciones


Cono de Incertidumbre

(Pista: estimar aquí )


Cono de incertidumbre


Incertidumbre


Precisión vs tiempo

Suficientemente buena


Complejidad

Req

uisi

tos

Tecnología


Triángulo de hierro

?

Tiempo Alcance

Recursos


Tradicional vs. Ágil

Fijar:

Estimar:

Alcance

Alcance

Coste Tiempo

Coste Tiempo

Orientación a Plan

Orientación a Valor


Gedanken: el P.O. perfecto

…..


Histograma


Histograma Norma


Histograma

95% SLA

80% SLA

Norma


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


“pero necesitamos presupuestos…”


5 principios



Cadena de valor


Ejercicio: Cadena de valor


5 principios



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: serie o paralelo


Fabricación por lotes

Proceso 2

A B

A+B

Proceso 1


Fabricación por lotes

Proceso 2

Lotes más pequeños:

Proceso 1

Proceso 2

A B A B

A+B

A B A B

A+B A+B A+B

A B

A+B

Proceso 1


Agilidad y tamaño de lotes


Flow

Lead Time : para todo el lote 30 ++ minutos

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

B B B B B

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

B B B B C C C C


Flow



B B B B B


B B B B C C C C

3 min. 12 min.

Continous Flow “produce uno, entrega uno” – cero inventarios

Lead Time: 12 minutos


Flow



B B B B B


B B B B C C C C

3 min. 12 min.

INTEGRACIÓN CONTINUA + LOTES PEQUEÑOS



Flow



B B B B B


B B B B C C C C

3 min. 12 min.

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

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



Lean Software Development

“In lean enterprises, traditional organisational structures give way to new team-oriented organisations which are centred on the flow of value, not on functional expertise.”

Mary Poppendiek


Flow

WIP++ WIP--


Flow & Batch Size

6 grúas, 6 muelles, 6 barcos 1 grúa = 1 barco / 6 días (acumulable, 2 grúas 3 días)


Descarga simultánea: todos 6 días Total uso muelles: 36 días

Flow & Batch Size


Todas las grúas a un barco (1 día) Día 6: todos en el mar Total uso muelles: 21 días

“Swarming”


Colas múltiples / cola simple


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”

“Swarming”


Optimización vs Suboptimización

Optimizar el tiempo de ciclo, no los tiempos individuales de cada célula productiva


Suboptimización


Suboptimización

50l/sg

20/sg

10l/sg

100/sg

30/sg


Suboptimización

50l/sg

22/sg

11l/sg

110/sg

33/sg

¡¡+10%!!

- Antiguo troughput: 10 - Nuevo troughput: 11 (10% ok) - Coste: 16


Suboptimización

50 23l/sg

23/sg

23l/sg

100l/sg

33l/sg

¡Kaizen!

- Antiguo troughput: 10 - Nuevo troughput: 23 (130%) - Ajusta carga a capacidad - Coste: 16

- I+D+i - Deuda técnica - Desacople


Suboptimización


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


Recapitulando…



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!

“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

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)


Axiomas:

Es posible dividir el trabajo en pequeños incrementos de valor añadido que pueden ser calendarizados de forma independiente

Es posible realizar estos incrementos de forma continua (Flow), desde la toma de requisitos a la entrega


Kanban en portfolio

?

400 días

Backlog


Kanban en portfolio

?

40 días

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

Backlog


Kanban en portfolio

?

40 días

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

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


Kanban Selected Backlog

Code Test Done!

Design

Rdy Rdy On On


Avatares


Colas Selected Backlog

Code Test Done!

Design

Rdy Rdy On On


WIP limits Selected - 2 Backlog

Code -4 Test - 2 Done!

Design -4

Rdy Rdy On On


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

WIP muy bajo WIP muy alto

Selected - 2

Backlog Code -1 Test - 1 Done!

Design -1 Rdy Rdy On On Selected -

2 Backlog

Code -10

Test - 1 Done! Design -8 Rdy Rdy On On


Lead time / cycle time

Selected Backlog Code Test

Done! Design

Rdy Rdy Rdy On On On

Total Lead Time ~120 días

LEAD TIME ~15 días

Cycle Time ~4 días


Histograma

95% SLA

80% SLA

Norma


Políticas explícitas 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 …….


Políticas explícitas


Done! Design


SP

RIN

T

FIRE!

PRIO

ASAP

- Ante bloqueos, ayudar tester con criterios aceptación

- Test automatizados antes de ready - Seguir estándar de código

- Doc. actualizada - 95% coverage - Max. 3 avatars por

persona

Atención inmediata

Atención prioritaria

Sólo si hay buffer y el Sprint va bien

- Normal

- Bug

- Evolutivo



J-43745

“Como administrador, quiero saber quién está conectado en todo momento para poder comunicarme con ellos”!

Est: 20 25

Bck: 3/2/11

Sel: 9/2/11

An: 12/2/11

Dsg: 17/2/11

Tst: 19/2/11

Don: 19/2/11

BufCount: I I I I I I

Left: 18 16 14 19 16 14 9 6 2 0

Código Ticketing

Tiempos Días en colas (una marca por día)

Descripción

Re-estimaciones

Seguimiento


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


Colas + WIP limits Selected - 2 Backlog

Code Test - 2 Done!

Design -4

Rdy Rdy -6 On On -2


WIP compuestos

Selected - 2 Backlog Code Test

Done! Design

Rdy Rdy -6 On On -2

6


Cola revisión Selected - 2 Backlog

Code - 7 Test-2 Done!

Design

Rdy Rdy -6 On On -2 Review-2

- Marcar para retrospect.


Cola Bloqueos Selected - 2 Backlog

Code - 7 Test-2 Done!

Design

Rdy Rdy -6 On On -2 Block-2

- Marcar para retrospect.


Cola integración Selected - 2 Backlog

Code Test - 2 Done!

Design -4

Rdy Rdy -6 On On -2 Wait integration

Integraciones tan frecuentes como sea posible

Min.

Max. (Go!)


Proveedores Selected - 2 Backlog

Code @TEST SUPPLIER - 3 Done!

Design -4

Rdy Rdy -6 On On -2

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


Proveedores Selected - 2 Backlog

Code Test int. - 2 Done!

Design -4

Rdy Rdy -6 On On -2

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

Test Out. - 4


Backlog & “Disneyland Queue”

1 semana

Backlog - 6 Code Test - 2

Done! Design -4

Rdy Rdy -6 On On -2

2 semanas


Espacio adicional

Selected - 2 Backlog

Code Test - 2 Done! Design -4

Rdy Rdy -6 On On -2

Vacaciones

Proyecto:

Equipo: Scrum, Demo:

Burn-down::

Release Plan:

Retro:

1. Necesidad de un Product Owner

2. Bloqueos en testing

3. Maquinas nuevas

4. Historias mal definidas

5. Pair programming

6. Piloto Hudson-Maven


Througput & Burn-Down

Establecer una cadencia arbitraria


Calidades de servicio


Done! Design

Rdy Rdy Rdy On On On S

PR

INT

FIRE!

PRIO

ASAP


Kanban


Fuegos

Alguien debe dejar lo que está haciendo y atenderlo de inmediato (Context Switching!)

Límite de uno en curso en cada momento dado

Puede romper límites WIP Deben ser severamente

auditados No todo es un fuego (si es

así, buscad un pirómano!)


Prioridades

En cuanto alguien esté libre, debe atender este elemento

Introduce un cambio de contexto controlado

Si siempre hay prioridades, puede haber atasco en otras calidades de servicio (starvation)


“As Soon As Possible”

“As possible” Si existe capacidad

diferenciada / excedente para atenderlo (si no, no)

No se estimarán


Opcional: fecha de entrega

Requieren de cierto análisis y estimación inicial (waste)

Tendrán un punto de no retorno para ser iniciadas – seleccionar antes de dicho punto


“Olores”



Done! Design

Rdy Rdy Rdy On On On S

PR

INT

FIRE!

PRIO

ASAP


J-43745

“Como administrador, quiero saber quién está conectado en todo momento para poder comunicarme con ellos”!

Est: 20 25

Bck: 3/2/11

Sel: 9/2/11

An: 12/2/11

Dsg: 17/2/11

Tst: 19/2/11

Don: 19/2/11

BufCount: I I I I I I

Left: 18 16 14 19 16 14 9 6 2 0

Alberto


Kanban Stand-ups

Enumerar trabajo de derecha a izquierda (Pull)

Concentrarse en excepciones Cuellos de botella Impedimentos Bloqueos WIP rotos Prioridades…


Diagrámas de flujo acumulado



Lead time

WIP

Scope Creep



Capacidad

Carga de trabajo (MURI)



Ensachamiento =

Cuello de botella, MURA

Capacidad

Carga de trabajo (MURI)


Backlog

Censo de proyectos (backlog) Priorización y estimación del backlog Visualización del flujo de valor (VSM + Visual

Management) Iterar


Backlog

Scrum: priorizado y estimado (al menos en talla) Priorización:

No todo el mundo puede ser satisfecho (receta para la mediocridad)

La gestión del backlog es política (de la buena ;-)

Si no puedes decir “NO”, tu “SÍ” no vale nada (Esther Derby)

Generalmente hay más ideas que capacidad: el backlog es FUNNEL, no TUNNEL


Backlog

Centrado en valor de negocio Alineado con objetivos estratégicos Incluir factores como riesgo, coste de retraso Cuidado con criterios como ROI (estimaciones) Mejor cuantos más representados Cuidado con priorizaciones

“emocionales” (prisas, presiones, enfados…) Asegura que todo el mundo conoce los criterios

(comunicación, comunicación, comunicación)


Backlog

Min. Cap.

Max. Cap.

Para la fecha propuesta, esto seguro que lo hacemos

¿Te estás quedando conmigo o qué?

Probablemente acabemos en algún sitio por aquí


Backlog

Min. V

Max. V

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

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

Predicción / estimación


Kanban

Scrumban


The 40 hour week fallacy:

100% (40 hours a week)

Programming (value adding tasks, focus factor, sprint dedication, project

advance…)


A more realistic approach:

50%

10%

15%

10%

10%

5%

Bugs, technical debt, stoppers, blocked tasks, rework, context switching, other forms of waste…

Reports, e-mail, internal meetings, hiring interviews, admininistrative stuff, bureaucracy…

Slack

Research, Development, training, innovation

Programming ( value adding tasks, focus factor, sprint dedication, project

advance…)

Overhead


Naked truth:

35%

10%

10%

10%

5%

30% Bugs, technical debt, stoppers, blocked tasks, rework, context switching, other forms of waste…


Slack


Programming ( value adding tasks, focus factor, sprint dedication, project

advance…)

Overhead


Naked truth:

35%

10%

10%

10%

5%

30% Bugs, technical debt, stoppers, blocked tasks, rework, context switching, other forms of waste…


Slack


Scrum (measured & known)

Overhead


Naked truth:

35% Scrum (measured & known)

65%


Selected. Dev. Valid. Pending Integration Done!

Burn-down::

Release Plan:

Scrumbam



Burn-down::

Release Plan:

! ! ! !

Scrumbam


Velocity

? ?


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

Release Plan:


Scrumbam



Release Plan:


Esto ha sido un tres…

5

1

Scrumbam




V Scrum

V Buffer

Scrumbam


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

85 20

75 30

70 35

75 25

80 25

? ?

Uuuh… Buenos, de media hacemos algo así como 75 scrum points por sprint. Supongo que nos podemos comprometer a eso mientras mantengas el 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

85 20

75 30

70 35

75 25

80 25

60 50

No, de hecho hemos hecho 110 puntos de velocidad agregada, que no está nada mal. TÚ nos priorizaste 50 puntos Buffer durante el Sprint y nos hiciste fallar el objetivo !




V Scrum

V Buffer +

V Buffer -

Scrumbam


Análisis de demanda

Valor

Proyectos (V. Scrum)

Evolutivos

Waste (Failure Demand)



Release Plan:


? ? ? ?

Scrumbam



Release Plan:

CO

MM

ITTE

D

PR

IO

Fire!

ASA

P

Scrumbam


Fire!


Release Plan:

CO

MM

ITTE

D

PR

IO

ASA

P

Scrumbam


Fire!


Release Plan:

CO

MM

ITTE

D

PR

IO

ASA

P ¿¿Eso ha sido un fuego??

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

oh-oh…

Scrumbam


Prio

Fire!


Release Plan:

CO

MM

ITTE

D

ASA

P


ASA

P Pr

io

Fire!


Release Plan:

CO

MM

ITTE

D


ASA

P Pr

io

Fire!

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

CO

MM

ITTE

D

Buffer Burn-down:

Uh-oh, parad el buffer, tíos!!

Mmm…Supongo que tampoco estaría mal hacer algo de Scrum…


ASA

P Pr

io

Fire!

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

CO

MM

ITTE

D

Buffer Burn-up:

Uh-oh, parad el buffer, tíos!!

Mmm…Supongo que tampoco estaría mal hacer algo de Scrum…


V Scrum V Buffer

80 7500

85 7000

75 8000

70 8500

75 7500

80 7000

? ?

¿vuestra predicción?

Uuuh… Buenos, de media hacemos algo así como 75 scrum points por sprint. Supongo que nos podemos comprometer a eso mientras mantengas el Buffer bajo control…

Eso significa no pasar de 7500 Buffer points


Yaaargh! Habéis fallado a vuestra promesa!

!

V Scrum V Kanban

80 7500

85 7000

75 8000

70 8500

75 7500

80 7000

60 11.200

No, en realidad hemos hecho over-buffering (50% más de lo habitual). TÚ nos priorizaste 11.200 puntos Buffer durante el Sprint y nos hiciste fallar el objetivo


Añade colas y WIP limits!

Selected - 3 Backlog Code Test

Done! Design

Rdy Rdy Rdy On- 3 On -2 On - 2 S

PR

INT

FIRE!

PRIO

ASAP


Especialistas y generalistas


Done! Design


SP

RIN

T

FIRE!

PRIO

ASAP

Sprint Burn-down:

Buffer burn-up:


Bonus: personal Kanban


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

[email protected]


¡¡¡¡ Blog It !!!!

[email protected]


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 [email protected]

Special thanks to Henrik Kniberg, David J. Anderson, Mattias Skarin, Corey Ladas, Mary Poppendieck & David Joyce.

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

Seminario Kanban y Scrumban

Business

Transcript of Seminario Kanban y Scrumban