Crear un recurso multimedia. Maricela_Ponce_DomingoM1S3AI6-1.pptx
Por qué Toyota mejora siempre: el modelo Lean Journey
1. ¿Por qué Toyota mejora siempre y otros no pueden?
Lean Journey un modelo visual para la mejora continua
22-09-2022
2. Alistair Cockburn
firmante del
Manifiesto Ágil
experto mundial
en fundamentos
ágiles
David J. Anderson
creador del
Método Kanban
Manuel Olguín
Agile Lean (2011)
Accredited Kanban Trainer
desde 2019
Pamela Falconi
Diseño educacional
Master en Gestión Educacional
mediante Lean y Agile (2015)
Agustín Villena
Pionero Agile en Chile (2002)
Kanban Coaching Professional
desde 2012
Partners mundiales
Transformamos tu organización para el futuro
+20 años de experiencia en Lean y Agile
+200 organizaciones clientes
Manuel Olguín
Agile Lean
Accredited Kanban Trainer
desde 2019
3. Experiencia y presencia mundial
Chile desde 2002
Perú desde 2010
México 2018
Colombia 2014
Uruguay 2016
Argentina desde 2008
USA 2011
Ecuador 2016
Inglaterra 2016
España 2018
Austria 2019
2002 U. De Chile
Desarrollo Ágil de Software
Dpto. Ciencias de la Computación
2010 U. De Chile
Innovación Tecnológica (Lean Startup)
Dpto. Ciencias de la Computación
2018 U. De Chile
Agilidad de Negocio
Master en Business Engineering
2018 U. Católica
Agilidad de Negocio
Diplomado de Transformación Digital y
del Negocio
7. La preocupante estadística sobre las
Transformaciones Digitales
Conversemos en bit.ly/contenidos-academia-agil
8. Sólo 30% de las Transformaciones
Digitales son exitosas
Fuente:
Companies That Failed At Digital Transformation
And What We Can Learn From Them
Conversemos en bit.ly/contenidos-academia-agil
9. Problemas comunes de la
transformación digital
Fuente:
Companies That Failed At Digital Transformation
And What We Can Learn From Them
Foco en cantidad y no
en la calidad de los
proyectos
Icons by the Noun Project
“Too much work” by Gan Khoon Lay
“Shipwrek” by Luis Prado, US
”Developer” by Oksana Latysheva, UA
“Customer” By Linda, CN
Transformación Digital
aislada del resto de la
compañía
Transformación Digital como
objetivo en sí misma en vez
de potenciar al negocio
Conversemos en bit.ly/contenidos-academia-agil
11. El ciclo de Shewhart
como fue explicado por W. E. Deming
conocido como PDCA (Plan, Do, Check, Act) ó PDSA (Plan, Do, Study, Adjust)
Planificar un cambio o experimento,
orientado como una mejora
Ejecutar
(preferentemente en pequeña escala)
Estudiar los resultados
¿Qué aprendimos?
Ajustar
Adoptar el cambio,
ó Abandonarlo,
ó Ejecutar el ciclo otra vez,
posiblemente en condiciones
ambientales diferentes.
12. Reporte A3
PLAN
Entender el problema y el
estado deseado a lograr.
DO – CHECK –
ACT
Experimentar para
resolver el problema
Source: A3 Report template by Tom Poppendieck and Henrik Kniberg
13. Contexto PLAN
Juegos retrasados, 2 años de tiempo de puesta en el mercado
● Ventanas de mercado perdidas ➔ ingresos decrecientes
● Equipos desmotivados ➔ desarrolladores principales a punto de renunciar
● Sobrecostos ➔ Tiempo para desarrollar juegos en constante aumento debido a la
disminución de la calidad técnica
● Hay presión para trabajar ¡MÄS RÄPIDO!
Condición actual (Mapa de flujo de Valor) PLAN
Objetivo / Condición Target PLAN
● tiempo de ciclo 8x más rápido
● Disminución en 5x de defectos no detectados
● Mejora del 20% en los ingresos
Análisis de Causa Raíz (Diagrama de causa-efecto) PLAN
Contramedidas (experimentos) EJECUTAR
1. Equipos multifuncionales – Desde Diseño Gráfico hasta Puesta en Producción
○ Se predice entrega 2x más rápida
=> Terminar dependencias - ahora gastan el 75% de tiempo en esperas /
negociaciones
2. Abandona todos expecto los juegos en cada cola, a excepción de los 3 más
prometedores. Hacer UN juego a la vez por cada equipo multifuncional.
○ entrega 4x más rápida al reducir cambios de contexto
○ La eliminación de colas reducirán 1,3 años de horario
3. Involucrar a los desarrolladores en jugar juegos y en la selección las ideas
○ 30% más ganancias a la par con el mejor competidor
=> Flitro mejorada para las ideas de juegos a desarrollar
=> Juegos más entertenidos, más populares
Confirmación (resultados) ESTUDIAR
1. Equipos multifuncionales
=> Mitad del tiempo en espera
2. Un juego a la vez
=> Colas eliminadas, tiempo para completar el juego es de 3-4 meses (6-8x más
rápido)
=> Deuda Técnica está disminuyendo - escapado defectos por 2x hasta ahora.
3. Involucrar a los desarrolladores en jugar juegos y seleccionar ideas
=> Un equipo con tiempo para produce juegos más innovadores.
=> Efecto en las utilidaes por determinar.
Seguimiento (acciones) AJUSTAR
1. Considerar la posibilidad de formación cruzada entre los miembros del equipo
para reducir la espera por especialistas.
2. Reducir dificultad de los pasos de integración y puesta en producción
3. Mejorar los procesos de generación y selección de ideas de juegos
a. Reclutar talento si es identificable / disponible
b. Mejorar las habilidades / procesos de las mejores personas que ya están
en la empresa
c. Ampliar tanto la participación en la selección y como en la experiencia
de juego de todos en la empresa
4. Continuar la mejora de los componentes / motores de juego reusables para
mejorar el rendimiento del desarrollo y reducir defectos.
Responsabl
e:
Lisa
Mentor: Henrik
Fecha: 18 de mayo 2009
A3: Desarrollo lento de juegos
Pres
Concepto
.
Asignación
de recursos
Diseño
gráfico
Diseño
sonido
Desa-
rrollo
Integraci;ón
y puesta en
producción
Cola de Proyectos
Juegos con
Diseño listo
Juegos listos para
la producción
Desperdici
o:
Valor:
1 mes 6 meses 1 semana 6 meses 2 meses 6 meses
4 horas 1 día 1 mes 3
semanas
1 mes
3
semanas
3 meses de valor agregado
25 meses de tiempo de ciclo
=12% de eficiencia del ciclo del proceso ¿¡Qué!?
2 años ?!
8 15 12
Idea Entrega
Ingenieros no
orgullosos de su
trabajo
Declive en la
calidad de los
juego
Interminables
retrasos y
generación de
desperdicio
Características no
pueden ser construidos
por 1 solo equipo.
Dependencias entre
equipos.
Ingenieros clave a
punto de renunciar
Disminución de
ingresos por
ventas
Juegos obsoletos
y fuera de fecha
Siempre completar un
juego toma más
tiempo
Colas
Deuda
Técnica
creciente
Los equipos se
concentran sólo en sus
propios componentes
Equipos divididos
por arquitectura Sin visión unificada
de prioridades
Work in Progress
excede la capacidad
No hay tiempo
para
refactorizar
Los defectos
tolerados
Presión desde el
negocio a trabajar
más rápido
Empresa no ha formado
a la gente apara realizar
análisis crítico de ideas
de juegos
Fundador / CEO
ya no tiene
tiempo para
analizar nuevas
ideas de juegos
Comprensión
deficiente de las
necesidades del
mercado
Ingenieros no pueden jugar
juegos
No hay un
filtro de
selección
eficaz
Copiar juegos
de los
competidores
Mercado
competitivo
Demasiados
nuevas ideas
de juego
Problem
a
Problem
a
Causa raíz
Causa raíz
Causa raíz
Plantilla de Resolución de Problemas A3 v1.2 (abril 2015) por Henrik Kniberg y Tom Poppendieck
Licencia: Creative Commons 4.0 Atributo Internacional
Enlace original: http://www.crisp.se/lean/a3-template
Traducido al español por Agustin Villena
14. Cómo se escribe el A3 en la teoría
A3 Problem Solving Template v1.2 (April 2015) by Henrik Kniberg and Tom Poppendieck
License: Creative Commons Attribute 4.0 International
Original link: http://www.crisp.se/lean/a3-template
Background PLAN
Current condition PLAN
Goal / Target Condition PLAN
Root Cause Analysis PLAN
Countermeasures (experiments) DO
Confirmation (results) CHECK
Follow up (actions) ACT
Owner:
Mentor:
Date:
A3: <problem statement>
Source: A3 Report template by Tom Poppendieck and Henrik Kniberg
15. Background PLAN
Games out of date, 2 years time to market
● Missed market windows ➔ revenue declining
● Demotivated teams ➔ key developers about to quit
● Overhead costs ➔ Time to develop games steadily increasing due to declining technical quality
● Pressure to Work FASTER!
Current condition (value stream map) PLAN
Goal / Target Condition PLAN
● 8x faster cycle time
● 5x fewer escaped defects
● 20% improvement in revenue
Root Cause Analysis (cause-effect diagram) PLAN
A3 Problem Solving Template v1.2 (April 2015) by Henrik Kniberg and Tom Poppendieck
License: Creative Commons Attribute 4.0 International
Original link: http://www.crisp.se/lean/a3-template
Countermeasures (experiments) DO
1. Cross-functional teams - Graphics design through deployment
○ Predict 2x faster delivery
=> End dependencies - now spend 75% of time waiting/negotiating
2. Abandon all but most promising 3 games in each queue. Do ONE game at a time per cross-
functional team.
○ 4x faster delivery from reduced task switching
○ Eliminating queues will cut 1.3 years from schedule
3. Engage developers in playing games and selecting ideas
○ 30% more profit to par with best competitor
=> improved filtering on which games to develop
=> more fun games, more popular
Confirmation (results) CHECK
1. Cross-functional teams
=> Half as much time waiting
2. One game at a time
=> Queues eliminated, time to complete game is 3-4 months (6-8x faster)
=> Technical Debt is decreasing - escaped defects down by 2x so far.
3. Engage developers in playing games and selecting ideas
=> One team taking to to play is producing more innovative games.
=> Impact on profit is to be determined.
Follow up (actions) ACT
1. Consider more cross training of team members to reduce waiting for expertise.
2. Reduce difficulty of integration and deployment steps
3. Improve processes for generating and selecting game ideas
a. Recruit talent if identifiable/available
b. Improve skills/process of best people already in company
c. Broaden both participation in selection and game playing experience of everyone in the
company
4. Continue improvement of reused game components/engines to improve development throughput
and reduce defects.
Owner: Lisa
Mentor: Henrik
Date: 18 May, 2009
A3: Slow game development
Concept
pres.
Resource
allocation
Graphics
design
Sound
design
Dev
Integrate
& deploy
Game backlog
Design-ready
games
Production-ready
games
Waste:
Value:
1 month 6 months 1 week 6 months 2 months 6 months
4 hours 1 day 1 month 3 weeks 1 month
3 weeks
3 months value add
25 months cycle time
= 12% process cycle
efficiency
WTF!
2 years?!
8 15 12
Idea Delivery
Engineers not
proud of their work
Game quality
declining
Endless delays
& thrashing
Features cannot be
built by single team. X-
team dependencies.
Key engineers about
to quit
Declining sales
revenue
Games stale &
out of date
Taking ever longer
to complete a game
Queues
Tech Debt
increasing
Teams focus on
their own parts
only
Teams divided by
architecture No unified view of
priorities
Work in Progress
exceeds capacity
No Time to
Refactor
Defects
tolerated
Pressure from
business to work
faster
Company has not
grown people to
vet game ideas
Founder/CEO
no longer has
time to vet new
game ideas
Weak understanding
of market needs
Engineers don’t get
to play games
No
effective
selection
filter
Copying
competitors
games
Competitive
market
Too many
new game
ideas
Problem
Problem
Root cause
Root cause
Root cause
Cómo se escribe el A3 en la teoría
Source: A3 Report template by Tom Poppendieck and Henrik Kniberg
16. Cómo se escribe el A3 en la práctica
Source: A3 Report template by Tom Poppendieck and Henrik Kniberg
23. Mejorando la Agilidad de negocio
120
“p blem ”
Efectos
Indeseados
manifestaciones visibles
de problemas
Operaciones
Flujo de
Mejora
Afiliados
Pensionados
2016
Operaciones implementó un
equipo en conjunto con T.I.
dedicado a implementar
mejoras
Usuarios
contacto@leansight.com
Licencia Creative Commons BY-NC-SA
24. Pe e un equ p “ m d de ped d ”
Usuarios
Icons by the Noun Project
Backlog by Giyonces González
120
“ n umpl m en de
l n m v v gen e”
Pedidos
2018
Varios millones de dólares
invertidos
Sin impacto de negocio visible
contacto@leansight.com
Licencia Creative Commons BY-NC-SA
25. 1. Entender Problema y sus
Causas
2. Diseño y Desarrollo de
Experimento de Mejora a pequeña
escala
3. Estudiar
Resultados
4. Actuar
según los
Resultados
Contrastemos con el Ciclo de Resolución de Problemas
Usuarios
Icons by the Noun Project
“Research” by Eucalyp
“experiment” by P Thanga Vignesh
“Research” by Llisole
“decide” by priyanka
¿Qué sucede si
nos saltamos
este trabajo?
Foco TI
Tradicional
contacto@leansight.com
Licencia Creative Commons BY-NC-SA
27. Aplicamos Lean Journey al Problema
Varios
Millones de
Dólares
invertidos
sin impacto
visible
120
Incumplimi
entos de la
Normativa
Vigente
Implementar
Mejoras con
un equipo T.I.
28. 2019: Aplicamos el Ciclo de Resolución de Problemas
1 mes de estudio
70% de Demanda
por Falla
Trabajo generado por
funcionalidades
entregadas
incorrectamente
(“deuda técnica”)
2 meses de
investigación
Sólo 3 sub-procesos
causan la demanda por
falla
contacto@leansight.com
Licencia Creative Commons BY-NC-SA
Eliminar
Demanda
por Falla
120
Incumplimi
entos de la
Normativa
Vigente
Varios
Millones de
Dólares
invertidos
sin impacto
visible
29. 1. Entender Problema y sus Causas
2. Diseño y
Desarrollo de
Experimento de
Mejora a pequeña
escala
3. Estudiar
Resultados
4. Actuar según
los Resultados
2019: Aplicamos el Ciclo de Resolución de Problemas
Usuarios
Icons by the Noun Project
“Research” by Eucalyp
“experiment” by P Thanga Vignesh
“Research” by Llisole
“decide” by priyanka
Pedidos
Modelo analítico
1 mes de estudio
70% de Demanda
por Falla
Trabajo generado por
funcionalidades
entregadas
incorrectamente
(“deuda técnica”)
Investigación de
causas raíces
2 meses de
investigación
Sólo 3 sub-procesos
causan la demanda por
falla
Siguiendo el ciclo, en 6 meses
demanda por falla baja a
prácticamente 0
Con fracción del $ original
contacto@leansight.com
Licencia Creative Commons BY-NC-SA
30. Danos tu feedback y obten el PDF del
Lean Journey
mail a contacto@agil.cl
contacto@leansight.com
Licencia Creative Commons BY-NC-SA
www.leansight.com
contacto@leansight.com
@leansight
+56 9 7414 0462