Seminario Kanban y Scrumban

Kanban & Scrumban

Madrid, Junio 2011

Ángel Medinilla!angel.medinilla@proyectalis.com

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

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

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

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

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

“No razonable”, ineficiencia por sobrecarga del proceso

En manufactura: Sobrecarga de maquinaria Sobreexplotación

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

Debate: las estimaciones como MUDA

Estimaciones

Cono de Incertidumbre

(Pista: estimar aquí )

Cono de incertidumbre

Incertidumbre

Precisión vs tiempo

Suficientemente buena

Complejidad

Tecnología

Triángulo de hierro

Tiempo Alcance

Recursos

Tradicional vs. Ágil

Fijar:

Estimar:

Alcance

Coste Tiempo

Orientación a Plan

Orientación a Valor

Gedanken: el P.O. perfecto

Histograma

Histograma Norma

Histograma

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

“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

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

Proceso 1

Agilidad y tamaño de lotes

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

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

B B B B B

B B B B C C C C

3 min. 12 min.

INTEGRACIÓN CONTINUA + LOTES PEQUEÑOS

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

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

50l/sg

10l/sg

100/sg

Suboptimización

50l/sg

11l/sg

110/sg

¡¡+10%!!

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

Suboptimización

50 23l/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

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

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

Design -4

Rdy Rdy On On

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

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

- 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

- 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

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

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

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

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

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:

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

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

Research, Development, training, innovation

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

advance…)

Overhead

Naked truth:

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

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

advance…)

Overhead

Naked truth:

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

Scrum (measured & known)

Overhead

Naked truth:

35% Scrum (measured & known)

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…

Scrumbam

V Scrum

V Buffer

Scrumbam

V Scrum V Buffer

¿Vuestra predicción?

V Scrum V Buffer

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

Yaaargh! ¡Habéis faltado a vuestra promesa!

V Scrum V Buffer

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

Proyectos (V. Scrum)

Evolutivos

Waste (Failure Demand)

Release Plan:

? ? ? ?

Scrumbam

Release Plan:

Scrumbam

Release Plan:

Scrumbam

Release Plan:

P ¿¿Eso ha sido un fuego??

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

oh-oh…

Scrumbam

Release Plan:

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

Buffer Burn-down:

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

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

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

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

Especialistas y generalistas

Done! Design

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

angel.medinilla@proyectalis.com

¡¡¡¡ Blog It !!!!

angel.medinilla@proyectalis.com

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 angel.medinilla@proyectalis.com

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

Poka Yoke y Kanban

110506 - scrumban - XP2011

SAP - KANBAN

Guía visual para Kanban

GESTIÓN ÁGIL DE PROYECTOS (SCRUM SCRUMBAN) · Estrategias de Scrumban GESTIÓN ÁGIL DE PROYECTOS Herramientas para la gestión ágil. Desarrollo de un Taller más un test global

Kanban 091118112533-phpapp01

Scrumban JOCBAESM

Introducción a Kanban

Curso capacitacion de kanban

Kanban y Scrum

Jit kanban-calidad total

Kanban 2012

Manual de Kanban

Scrum Kanban o ambos

El Sistema Kanban n

KANBAN exposicion

Mini Scrumban - Guía Rapida

Lean & kanban: introducción

Scrumban multiproyecto y multiperfil

logistica kanban