El documento describe el proceso de mejora continua conocido como Lean Journey o Camino Lean, el cual utiliza un modelo visual llamado LeanSight para guiar la mejora. El modelo muestra las etapas de comprender la situación actual, definir la situación objetivo, identificar la brecha entre ambas y realizar experimentos para cerrar la brecha de forma gradual a través de la mejora continua.
El equipo de Agile Coaches de ING España está formado por 14 personas.
Pero… ¿qué hace este equipo?, ¿en qué trabaja exactamente?, ¿cómo está organizado?, ¿cúal es su producto o servicio?, ¿cómo se mide su impacto?
En esta charla nos hace ilusión compartir con generosidad las aventuras de este viaje de 13 años: los tropiezos, los descubrimientos, lecciones aprendidas, peripecias y malabares… ¡y hasta algún acierto casual también!
Charla introductoria a las metodologías ágiles, específicamente al mundo de las Historias de Usuario como herramienta para recopilación de requerimientos y a SCRUM como marco de trabajo para el Desarrollo de Software
Descripción de los roles que se encuentran en un equipo agil, generalizados más allá de un framework específico,eliminando la restricción de ser aplicados a un desarrollo de software
Agiles RD comparte esta presentación como símbolo de agradecimiento a todos los interesados en el tema de agilidad y por su grata asistencia al taller de Scrum.
Webinar: Integrar la analítica en Metodologías ÁgilesIEBSchool
Alberto Ambrosio nos explica cómo integrar la analítica en metodologías ágiles en este nuevo webinar de IEBS.
Las nuevas tecnologías nos permiten analizar y obtener resultados en un periodo de tiempo reducido. Las organizaciones tienden a modelos en los que se mejora la productividad de forma rápida y a métodos de gestión que permiten una mayor flexibilidad, tales como metodologías de gestión de proyectos ágiles.
La analítica debe ser nuestro pilar fundamental para la toma de decisiones, de forma que ayude a mejorar nuestro impacto en el negocio, cliente y mercado. Es importante integrar la cultura analítica dentro de los procesos internos de la compañía y basarnos en datos cuantitativos que nos permitan dirigir nuestras decisiones directamente a ámbitos que mejoren el negocio.
El equipo de Agile Coaches de ING España está formado por 14 personas.
Pero… ¿qué hace este equipo?, ¿en qué trabaja exactamente?, ¿cómo está organizado?, ¿cúal es su producto o servicio?, ¿cómo se mide su impacto?
En esta charla nos hace ilusión compartir con generosidad las aventuras de este viaje de 13 años: los tropiezos, los descubrimientos, lecciones aprendidas, peripecias y malabares… ¡y hasta algún acierto casual también!
Charla introductoria a las metodologías ágiles, específicamente al mundo de las Historias de Usuario como herramienta para recopilación de requerimientos y a SCRUM como marco de trabajo para el Desarrollo de Software
Descripción de los roles que se encuentran en un equipo agil, generalizados más allá de un framework específico,eliminando la restricción de ser aplicados a un desarrollo de software
Agiles RD comparte esta presentación como símbolo de agradecimiento a todos los interesados en el tema de agilidad y por su grata asistencia al taller de Scrum.
Webinar: Integrar la analítica en Metodologías ÁgilesIEBSchool
Alberto Ambrosio nos explica cómo integrar la analítica en metodologías ágiles en este nuevo webinar de IEBS.
Las nuevas tecnologías nos permiten analizar y obtener resultados en un periodo de tiempo reducido. Las organizaciones tienden a modelos en los que se mejora la productividad de forma rápida y a métodos de gestión que permiten una mayor flexibilidad, tales como metodologías de gestión de proyectos ágiles.
La analítica debe ser nuestro pilar fundamental para la toma de decisiones, de forma que ayude a mejorar nuestro impacto en el negocio, cliente y mercado. Es importante integrar la cultura analítica dentro de los procesos internos de la compañía y basarnos en datos cuantitativos que nos permitan dirigir nuestras decisiones directamente a ámbitos que mejoren el negocio.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Versión de la presentación "La alternativa ágil" usada en la charla del mismo nombre durante el Uniencounter de Marzo de 2011
Como novedad incorpora la parte "El profesional", y habla de orgullo, habilidades y software craftmanship :)
Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.
- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil
Gestión y desarrollo ágil de proyectos. como salir al mercado lo antes posiblefernandomilla.es
En este taller orientado a todo tipo de público donde pretendemos enseñar un conjunto de buenas prácticas que nos permitirán ir sacando al mercado versiones incrementales de nuestro producto o servicio, cada una de ellas con valor añadido sobre la anterior, en los menores plazos posibles, hasta tener el producto completo. Y con ello, ir generando ingresos de forma temprana a la vez que comprobamos la viabilidad del proyecto con usuarios reales.
Hoy en día, las empresas quieren y tienen que ser capaces de lanzar productos y servicios al mercado lo más rápido posible, atender a las constantes demandas y solicitudes de cambio de los clientes de manera eficaz y flexible, y al mismo tiempo optimizar la gestión de sus recursos. Por ello, gestionar y dirigir de forma ágil los proyectos es clave para reducir el tiempo de lanzamiento del producto/servicio que desarrollas a la vez que ofreces un mayor valor a tus usuarios.
La gestión ágil (agile development) es un enfoque innovador para la gestión de ideas, proyectos y empresas, que ayuda a las personas a trabajar juntas, cohesionadas, de forma autónoma y efectiva para lograr los objetivos de negocio de forma eficiente.
Tomaremos como base dos metodologías ágiles como Scrum y Kanban y explicaremos como adaptarlas para conseguir aplicarlas a nuestro proyecto y lograr resultados lo más rápidamente posible.
La presentación cubre:
-Pequeño repaso sobre el desarrollo de software siguiendo la metodología waterfall
Agile y Lean Startup
- Los pilares de Scrum;
---- Roles: Product Owner, Scrum Master y Equipo de Desarrollo.
---- Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva.
---- Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad.
---- Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.
Versión de la presentación "La alternativa ágil" usada en la charla del mismo nombre durante el Uniencounter de Marzo de 2011
Como novedad incorpora la parte "El profesional", y habla de orgullo, habilidades y software craftmanship :)
Razones para adoptar ágil, fallas y tips para hacerlo de forma correcta.
- Hasta la diapositiva 51, introducción a la agilidas
- de la 52 a la 80 por que los equipos ágiles son más "rápidos" y efectivos
- de la 81 a la 94 errores en la adopcion agile
- de la 95 en adelante mitos y tips en la adopción ágil
Gestión y desarrollo ágil de proyectos. como salir al mercado lo antes posiblefernandomilla.es
En este taller orientado a todo tipo de público donde pretendemos enseñar un conjunto de buenas prácticas que nos permitirán ir sacando al mercado versiones incrementales de nuestro producto o servicio, cada una de ellas con valor añadido sobre la anterior, en los menores plazos posibles, hasta tener el producto completo. Y con ello, ir generando ingresos de forma temprana a la vez que comprobamos la viabilidad del proyecto con usuarios reales.
Hoy en día, las empresas quieren y tienen que ser capaces de lanzar productos y servicios al mercado lo más rápido posible, atender a las constantes demandas y solicitudes de cambio de los clientes de manera eficaz y flexible, y al mismo tiempo optimizar la gestión de sus recursos. Por ello, gestionar y dirigir de forma ágil los proyectos es clave para reducir el tiempo de lanzamiento del producto/servicio que desarrollas a la vez que ofreces un mayor valor a tus usuarios.
La gestión ágil (agile development) es un enfoque innovador para la gestión de ideas, proyectos y empresas, que ayuda a las personas a trabajar juntas, cohesionadas, de forma autónoma y efectiva para lograr los objetivos de negocio de forma eficiente.
Tomaremos como base dos metodologías ágiles como Scrum y Kanban y explicaremos como adaptarlas para conseguir aplicarlas a nuestro proyecto y lograr resultados lo más rápidamente posible.
Desde mejorar equipos de desarrollo de software, hasta mejorar el flujo organizacional de empresas completas, en esta presentación muestro mi exploración del mundo de la mejora organizacional y cómo he ido descubriendo principios orientadores para lograrla a los largo de casi 2 décadas de trabajo
Kanban y la Transformación Organizacional - Las revoluciones pueden fracasar,...LeanSight Consulting
as organizaciones actuales están enfrentadas al literal "cambiar o morir". Sin embargo muchas de estas transformaciones fallan al diseñar grandes cambios organizacionales sin entender cuales realmente son los verdaderos problemas de productividad.
Sin importar si hay una estructura tradicional o ágil, el método Kanban ofrece una nueva mirada para hacer explicito los flujos de creación de valor, sus impedimentos, y desde ahi mejorar ágilmente.
Adoptar el marco de trabajo Scrum entrega grandes beneficios de colaboración y entrega incremental del trabajo. Sin embargo hay situaciones donde la realidad amerita una mirada más flexible. Aquí aplicar el método Kanban sobre el proceso Scrum puede ser una gran solución.
¿Cómo se entiende el modelo de madurez del método Kanban (Kanban Maturity Model) para hacer más fluido el trabajo de la organización de forma incremental?
Charla realizada para la Comunidad Kanban Argentina el 27/04/2021
En Scrum, uno de los 3 roles es el Product Owner, encargado final de definir la vision del producto en desarrollo, y de priorizar las funcionalidades de éste. Scrum tiene una forma acotada por lo definido por la Scrum Guide, y para hacer más fluido el trabajo, podemos usar el método Kanban sobre Scrum. Ahora bien, no basta con eso para asegurarnos de pasar de tomar pedidos y realmente impactar positivamente al negocio de la organización, para eso proponemos Lean Product Ownership, inspirado por el Ciclo de Deming como complemento perfecto al desarrollo guiado mediantea Kanban + Scrum. Tenemos formación y certificación disponible en http://www.academiaagil.com
¿Transformaciones con muchas células y sin impacto en el negocio? Lean y Kanb...LeanSight Consulting
Las empresas actuales están embarcadas en procesos complejos de transformación, donde se implementan células ágiles y otras innovaciones metodológicas con una gran inversión de tiempo y dinero.
Sin embargo, al menos un 70% fracasa: por ende no se logra impactar positivamente al negocio.
Haremos explícitas algunas de las causas y cómo Lean unido a Kanban sirven para lograr un mejor abordaje de los problemas a resolver, potenciado por un diseño organizacional alineado a cómo la organización crea valor.
Mucha gente se confunde cuando hablamos del Método Kanban porque creen que no pasa de ser un tablero con papelitos ("un _canvas_"). En esta charla abierta para la comunidad ágil de hispanoamérica explicamos los diversos significados de _Kanban****_ (desde Toyota, los tableros, los sistemas y el método enseñado por la Kanban University)
Como Kanban entiende las organizaciones : Los Lentes de KanbanLeanSight Consulting
Kanban no parte del supuesto de que hay que mirar el organigrama y cambiar puestos, sino de que hay que descubrir cómo fluye el valor en la organización, visualizarlo, y mejorar desde ahí paso a paso.
Presentamos un modelo creado por David Anderson, fundador de la Kanban University, explicando como podemos cambiar nuestra mirada desde la típica pirámide jerárquica a una red de servicios que colaboran para resolver necesidades de sus clientes
Infografía - Comparación entre Scrum y Extreme Programming XPLeanSight Consulting
Scrum y Extreme Programming tienen ciclos de trabajo similares y a la vez una gran diferencia entre ellos. En este diagrama se comparan ambos Frameworks a partir de los ciclos que componen sus prácticas
Flattening the Curve - Kanban and the challenge of managerial mindsetLeanSight Consulting
How do we use the common phrase "flatten the curve" to convince our applicants, who usually have more power than us, to limit their requests to the capacity of our work system?
Aplanar la curva - Kanban y el desafio del Mindset gerencialLeanSight Consulting
¿Cómo usar el lugar común de "aplanar la curva" para convencer a nuestros solicitantes, quienes usualmente tienen más poder que nosotros, a limitar sus pedidos a la capacidad de nuestro sistema de trabajo?
Video de la charla disponible en https://www.youtube.com/watch?v=M4oqmN83LaI
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
En este documento analizamos ciertos conceptos relacionados con la ficha 1 y 2. Y concluimos, dando el porque es importante desarrollar nuestras habilidades de pensamiento.
Sara Sofia Bedoya Montezuma.
9-1.
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta in...espinozaernesto427
Las lámparas de alta intensidad de descarga o lámparas de descarga de alta intensidad son un tipo de lámpara eléctrica de descarga de gas que produce luz por medio de un arco eléctrico entre electrodos de tungsteno alojados dentro de un tubo de alúmina o cuarzo moldeado translúcido o transparente.
lámparas más eficientes del mercado, debido a su menor consumo y por la cantidad de luz que emiten. Adquieren una vida útil de hasta 50.000 horas y no generan calor alguna. Si quieres cambiar la iluminación de tu hogar para hacerla mucho más eficiente, ¡esta es tu mejor opción!
Las nuevas lámparas de descarga de alta intensidad producen más luz visible por unidad de energía eléctrica consumida que las lámparas fluorescentes e incandescentes, ya que una mayor proporción de su radiación es luz visible, en contraste con la infrarroja. Sin embargo, la salida de lúmenes de la iluminación HID puede deteriorarse hasta en un 70% durante 10,000 horas de funcionamiento.
Muchos vehículos modernos usan bombillas HID para los principales sistemas de iluminación, aunque algunas aplicaciones ahora están pasando de bombillas HID a tecnología LED y láser.1 Modelos de lámparas van desde las típicas lámparas de 35 a 100 W de los autos, a las de más de 15 kW que se utilizan en los proyectores de cines IMAX.
Esta tecnología HID no es nueva y fue demostrada por primera vez por Francis Hauksbee en 1705. Lámpara de Nernst.
Lámpara incandescente.
Lámpara de descarga. Lámpara fluorescente. Lámpara fluorescente compacta. Lámpara de haluro metálico. Lámpara de vapor de sodio. Lámpara de vapor de mercurio. Lámpara de neón. Lámpara de deuterio. Lámpara xenón.
Lámpara LED.
Lámpara de plasma.
Flash (fotografía) Las lámparas de descarga de alta intensidad (HID) son un tipo de lámparas de descarga de gas muy utilizadas en la industria de la iluminación. Estas lámparas producen luz creando un arco eléctrico entre dos electrodos a través de un gas ionizado. Las lámparas HID son conocidas por su gran eficacia a la hora de convertir la electricidad en luz y por su larga vida útil.
A diferencia de las luces fluorescentes, que necesitan un recubrimiento de fósforo para emitir luz visible, las lámparas HID no necesitan ningún recubrimiento en el interior de sus tubos. El propio arco eléctrico emite luz visible. Sin embargo, algunas lámparas de halogenuros metálicos y muchas lámparas de vapor de mercurio tienen un recubrimiento de fósforo en el interior de la bombilla para mejorar el espectro luminoso y reproducción cromática. Las lámparas HID están disponibles en varias potencias, que van desde los 25 vatios de las lámparas de halogenuros metálicos autobalastradas y los 35 vatios de las lámparas de vapor de sodio de alta intensidad hasta los 1.000 vatios de las lámparas de vapor de mercurio y vapor de sodio de alta intensidad, e incluso hasta los 1.500 vatios de las lámparas de halogenuros metálicos.
Las lámparas HID requieren un equipo de control especial llamado balasto para funcionar
EduFlex, una educación accesible para quienes no entienden en clases
Por que Toyota mejora siempre y otros no - 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