Source: http://jaumejornet.es/blog/2015/03/02/a3-thinking/
Timestamp: 2019-03-21 14:24:07+00:00

Document:
A3 Thinking | Jaume Jornet
por Jaume | Mar 2, 2015 | Blog | 2 Comentarios
Si alguien me preguntase que es lo mejor que me ha aportado King en el casi un año que llevo trabajando en sus oficinas de Barcelona, sin duda la respuesta es poder trabajar con Pablo Domingo, mi compañero Scrummaster en el Studio Dragons. Entre las muchas cosas que he aprendido de él este año, esta el uso de A3 Thinking. Recientemente se ha hecho mención en el foro de agile-spain sobre el tema, por lo que he decidido aprovechar la ocasión para volcar aquí lo aprendido por si a alguien más le puede ser de utilidad.
¿Qué es A3 thinking?
En su origen, A3 fue desarrollado por Toyota como formato para realizar propuestas de mejora y su seguimiento. Actualmente toma su nombre del estándar ISO A3, designado como un tamaño de hoja de 297×420 milímetros (el utilizado por Toyota). La idea detrás de A3 es simple: comunicar tu propuesta de mejora en una sola hoja- ni más, ni menos.
Condensando la información en una sola hoja, el formato A3 permite a los miembros de una organización entender fácilmente cual es la propuesta del autor. Aunque esta sea su ventaja más visible, en su libro Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System, el autor define la metodología A3 como una herramienta usada para mentorizar. Ayudar a todas las personas, en todos los niveles de la organización, a convertirse en “problem solvers” (solucionadores de problemas), en lugar de “problem bringers” (portadores de problemas).
En The A3 Workbook: Unlock Your Problem-Solving Mind, Daniel D. Matthews utiliza el siguiente gráfico para ilustrar el mismo concepto (aunque menciona que provienen de un estudio de OEMs, no aporta referencia que pueda enlazar).
Gráfico extraído del libro The A3 Workbook: Unlock Your Problem-Solving Mind.
De acuerdo al estudio, se clasificaron las tipologías de problemas de OEM analizados en tres categorías:
1. Simples (90,91%): problemas del día a día que requieren conocimientos básicos de resolución de problemas.
2. Significantes (8,95%): problemas que requieren la participación o aprobación de supervisores(1) para la implementación de soluciones.
3. Complejos (0,4%): problemas que requieren métodos de resolución más complicados, o que involucran decisiones estratégicas, etc.
Pese a que el estudio puede simplificar excesivamente el concepto de “problema”, el autor lo utiliza para ilustrar que en el 99,86% de los problemas experimentados por OEM, estos podían ser fácilmente gestionados directamente y de forma autónoma por miembros de los equipos. De acuerdo al autor, ‘el uso de A3 en todas las áreas y niveles de la empresa, permite crear organizaciones de “problem-solvers” que pueden de forma autónoma resolver cerca del 99% de los problemas que surgen en esta’.
Es importante remarcar que A3 thinking no busca únicamente la resolución del problema, sino evitar que este vuelva a reproducirse en el futuro. Si únicamente atacásemos la situación actual con el propósito de corregirla, sin detenernos a reflexionar en cómo hemos podido llegar a dicha situación, la solución adoptada seria incompleta, y el problema susceptible de volver a reproducirse en el futuro.
El uso de A3 tiene sus raíces en el ciclo PDCA. Los distintos pasos que componen la creación de un A3, su ejecución y seguimiento, ayudan a los autores a navegar a través del ciclo. Remarcar que en la totalidad de los libros que he consultado para la elaboración de este post, se destaca la importancia de seguir secuencialmente los pasos. Todos los autores coinciden en que, realizándolos en orden, aumenta nuestra compresión del problema antes de realizar el siguiente paso.
Existen diferentes tipos de A3, diferentes formatos para diferentes tipologias de problemas. Para este post, he escogido el formato que usamos Pablo y yo en King. Consta de siete pasos.
Paso 1. Análisis de la situación actual: antes de emprender ninguna contramedida (el concepto de contramedida lo explicaré más adelante), debemos comprender adecuadamente cual es la situación actual que deseamos corregir.
Paso 2. Definición de objetivos: ¿Cómo deseamos corregir la situación actual? ¿En qué? ¿En cuanto? ¿Para cuando?
Paso 3. Tema: Aunque intuitivamente el primer paso a realizar pudiera parecer ser definir el tema, al principio de la elaboración del A3 puede que nuestra comprehensión del problema que queremos atacar no sea tan exacta como creemos. Es mejor esperar a tener completados los pasos 1 y 2, momento en el que nuestra comprensión de la situación actual y los objetivos que queremos obtener serán más detallados.
Paso 4. Análisis de causa raíz: Al enfrontar problemas, a menudo cometemos a menudo el error de saltar directamente a las posibles soluciones. El análisis de causa raíz pretende ayudarnos a profundizar en nuestro entendimiento de que esta sucediendo y cuales son las causas que nos llevan a la situación actual no deseada.
Paso 5. Contramedidas: cómo explicare más adelante, las contramedidas no son soluciones, si no acciones a realizar que nos permiten corregir la situación actual, acercándonos o alcanzando la situación objetivo deseada.
Paso 6. Implementación: los detalles de ejecución de las contramedidas que queremos llevar a cabo.
Paso 7. Follow-up: seguimiento de las medidas y de sus resultados.
Extraído del libro The A3 Workbook: Unlock Your Problem-Solving Mind.
Lo primero que debemos tener en cuenta a la hora de empezar a ejecutar los siguientes pasos para la creación del A3, es entender correctamente el problema que queremos atacar. Desde el punto de vista del A3, un problema es la diferencia entre la situación actual y el estándar.
– Estándar: una expectativa, o una norma, que describe qué debería estar pasando en una determinada situación. Si el estándar no es conocido y consensuado entre todos, corremos entonces el riesgo de tener tantas percepciones como personas en el equipo de como deberían ser las cosas en dicha situación.
– Situación actual: es la descripción de lo que esta pasando en este momento en relación con el estándar esperado.
– Discrepancia: es la variación medible y reconocible entre el estándar y la situación actual (el problema)
En agile empleamos a menudo (habitualmente, o una mayoría de nosotros) la palabra kaizen, usada para referirse a la búsqueda de la mejora continua. Sin embargo, la búsqueda mejora continua no es la única tipología de discrepancias (o problemas) que podemos encontrarnos. Toyota define 3 tipos de resolución de problemas:
– Preventivo (Soshi): esta tipo de resolución de problemas se focaliza en prevenir situaciones que podrian convertirse en problemas en el futuro. Busca el anticiparse a los problemas.
– Mejora Continua (Kaizen): focalizado en mejorar sistemas o procesos existentes. Habitualmente, el kaizen se da en dos fases: una primera, en la que buscamos la mejora, y una segunda, en la que estabilizamos el proceso, de forma que el cambio sea sostenido. Una vez conseguido esto, podemos ir a buscar la siguiente mejora.
– Mantenimiento (Iji): el tercer tipo de resolución problemas busca resolver situaciones en las que el estándar establecido no esta siendo alcanzado (seguro que alguna vez te has encontrado en una de esas situaciones en las que las cosas se van degradando lentamente).
Entender y ser capaz de situar el problema en su contexto, nos ayudará en la comprensión del mismo e incidirá en los pasos posteriores. Probablemente realicemos de forma diferente el seguimiento de un problema encarado a conseguir que una determinada métrica vuelva al valor que deseamos (Iji) que una situación de mejora continua en la que no estará tan claro cual es el estándar a conseguir.
Una vez contextualizado el problema o discrepancia, A3 thinking hace hincapié en centrarnos siempre en los hechos, no en nuestra percepción. Romper el problema en características especificas del mismo, para poder entenderlo mejor. Para ello, una buena forma de asegurarnos de que estamos contextualizando el problema de forma adecuada es plantearnos las siguientes preguntas:
– ¿Cuando esta sucediendo el problema (horas del día en que sucede, días de la semana, etc.)?
– ¿Con cuanta frecuencia (a diario, una vez por semana, cada seis meses, etc.)?
– ¿Donde esta el problema?
– ¿Hace cuanto que existe (intenta ser lo máximo exacto que puedas, día mes y año si es posible)?
– ¿Cual es la tendencia (va a peor, esta estabilizado, mejora)?
– ¿Quien esta afectado por el problema (personas, procesos, productos, etc.)?
Ejemplo: El ratio de bugs abiertos vs cerrados por Sprint se ha incrementado a lo largo de los últimos cinco sprints, aumentando en todos ellos, hasta superar el umbral 3:1 en el pasado Sprint 44. La tendencia se mantiene al alza, y afecta exclusivamente el Producto X. El descenso en la calidad de las últimas releases se ha reflejado en la percepción de nuestros usuarios sobre el Producto X, descendiendo 0.8 puntos el rating en xxx Store.
Una vez tenemos acotado el problema, llega el momento de evaluarlo, no únicamente desde la visión del mismo sino mirando la organización en su conjunto. ¿Porque es necesario atacar ahora este problema por delante de otros? Priorizar el problema en el contexto de otros problemas que pueden estar sucediendo a la vez, nos ayudará a comunicarlo y razonarlo mejor. Hay tres aspectos fundamentales a tener en cuenta:
– ¿Cual es la importancia del problema? ¿Cómo esta afectando a nuestros objetivos?
– ¿Cual es su urgencia? ¿Cómo de rápido deberíamos atacarlo para evitar que cree otros problemas en el futuro?
– ¿Cual es la tendencia? Basándote en lo que has observado, ¿cómo crees que va a evolucionar? ¿Va a ir a peor? ¿Continuara como actualmente de forma indefinida? ¿Se arreglara poco a poco hasta desaparecer?
Problema Importancia Urgencia Tendencia
Problema Ratio Bugs Open vs Closed Alta Alta Empeora
Problema #2 Media Media Estable
Problema #N Media Baja Estable
Nota: En este punto, me gustaría hacer la reflexión de que lo que inicialmente se antojaba una iniciativa de mejora continua Kaizen (aumentar la calidad de nuestro producto disminuyendo el número de defectos) ha acabado por descubrirnos que esta ocasionando un problema de mantenimiento Iji (se esta produciendo, y aumentando, un gap entre el estándar, la valoración que esperamos nuestros clientes hagan de Producto X, y la calificación actual).
Parece ser que de las cuatro formas en que un problema puede llegar a nosotros
1. El problema es percibido como una posibilidad futura
2. El problema es detectado, evaluado y tomado en consideración
3. El problema es pasado a nosotros por una tercera parte, o
4. El problema nos estalla en la cara
hemos ido a dar con la peor de ellas.
Definir los objetivos que queremos conseguir es un aspecto importante cuando estas realizando un A3. Si no se marcan los objetivos, dejamos abierta la puerta a la procastinación, y es probable que otros temas tomen prioridad en nuestro día a día.
Un objetivo (target) es diferente a una meta (goal). El objetivo no tiene porque ser en si mismo la resolución del problema, si no el grado de avance que queremos realizar hacia la misma(2). A la hora de definir tu(s) objetivo(s), intenta a la vez que en la situación actual ser lo más concreto posible. Una buena forma de hacerlo es utilizar la siguiente plantilla a la hora de redactarlo:
1. Empieza por un verbo, que describa la acción que vas a tomar a cabo.
2. Una pequeña descripción del problema. ¿Que es lo que vas a atacar?
3. Añade la medida especifica de lo que quieres conseguir, y finalmente
4. Incluye la ventana de tiempo en la que quieres conseguirlo.
2. El ratio de número de bugs abiertos vs cerrados en cada nueva release
3. 1:1 o negativo
4. Tres meses (seis Sprints)
Target: “Reducir el ratio de número de bugs abiertos vs cerrados en cada nueva release a 1:1 o negativo en los siguientes tres meses (seis sprints).”
Tal y como indicaba anteriormente, parece intuitivo crear el tema del A3 cómo primer paso. Sin embargo, tu comprensión del problema al inicio será probablemente vaga. Es mejor esperar a tener un mayor conocimiento de cual es la situación actual y el objetivo que queremos conseguir, para definir el tema.
Tema: “Aumentar la satisfacción de nuestros usuarios corrigiendo el descenso en la calidad del producto X.”
Una vez el problema ha sido identificado, debe haber un entendimiento claro de porque a ocurrido antes de tomar cualquier acción para corregir la situación actual. Empezando en el problema identificado, pregúntate a ti mismo: “Basándome en los hechos de la situación actual, ¿qué puede haber causado el problema?”
Una de las técnicas más extendidas para realizar este tipo de análisis es 5Whys: preguntarse al menos cinco veces porqué esta sucediendo la situación actual(3). La representación visual de este análisis suele realizarse mediante un diagrama Ishikawa.
Realizar un correcto análisis de causa raíz no es fácil. Para el actual ejemplo, he sobre simplificado el diagrama de causa raíz al máximo para poder centrarme en lo que quiero explicar, no en la correcto o incorrecto del mismo.
He señalado en diferentes colores
– las causas raíz que atacaré posteriormente en las contramedidas y
– otras causas y caminos que no seguiré.
He querido incluir los caminos que no seguiremos para ilustrar que, a menudo, la realización de análisis causa raíz pueden llevarnos a partes del problema que ni imaginábamos al empezar a analizarlo. Aunque no las exploraremos en este post por simplicidad, es fácil imaginar como de lejos pueden llevarnos preguntarnos porqué nuestra respuesta al usuario no es rápida (el equipo de CRM esta a punto de recibir un problema en la forma 3), o porqué tenemos una presión por liberar producto constantemente. Seguir el hilo nos llevaría a partes de la organización muy apartadas del código fuente en el que esperábamos encontrar las causas.
Saber cuando parar en el análisis de causa raíz no es sencillo. Para determinar si estas ya en una causa raíz, deben cumplirse las siguientes condiciones:
1. La causa es una consecuencia lógica de la discrepancia: A menudo, una buena forma de validar esto es sustituir nuestra pregunta “¿porqué?” por “por lo tanto”, y leer el diagrama al revés. Al hacerlo, no es extraño encontrar saltos muy grandes (que nos llevan a causas intermedias) o que no son consecuencia directa de esa raíz. Puede que lo sean de la combinación de varias, y eso nos obligue a atacarlas todas a la vez.
2. La causa puede ser atacada directamente.
3. La causa es un elemento para el que pueden planificarse contramedidas.
Nota: hay una excepción al proceso de análisis de causa raíz. En ocasiones, no nos será posible contestar a la pregunta ¿porque?, habitualmente dado a la incapacidad de conseguir información fiable. En estas ocasiones, la recomendación es hacer brainstorm de un amplio número de causas raíz. Elegir las que creemos más factibles, dejando las otras on-hold, e implementar contramedidas en la búsqueda de confirmarlas o no. En el caso en que se confirme que no eran la causa, volver atrás a buscar la siguiente más factible que dejamos on-hold, y empezar de nuevo. Cómo es fácil imaginar, este proceso es mucho más costoso en tiempo, esfuerzo e incertidumbre.
Tal y como comentaba anteriormente, una contramedida no es una solución al problema, sino una acción que implementamos para contrarrestar la situación actual, que nos ayuda a alcanzar el objetivo. Podemos hablar de dos tipos de contramedidas:
– Contramedidas a largo plazo: son aquellas que lidian directamente con la(s) causa(s) raíz y nos permiten alcanzar el objetivo, a la vez que prevenir la recurrencia del problema.
– Contramedidas a corto plazo, que habitualmente afectan a alguno de los niveles en la cadena del análisis de causas diferente a la causa raíz, con el objetivo de proporcionar un alivio temporal del problema o acercarnos (sin llegar a alcanzarlo) al objetivo.
A la hora de redactarlas, una buena de forma de validarlas es preguntarnos: ‘Basándonos en los hechos de la situación actual, ¿va a ser esta contramedida efectiva, factible, y va a tener un impacto positivo en la situación acercándonos al objetivo?”
– Efectiva: lo primero a evaluar es la habilidad de la contramedida para conseguir dos cosas: 1) acercarnos al objetivo, y 2) prevenir la recurrencia del problema.
– Factible: de nada nos sirve una contramedida que no es posible implementar, o que hacerlo tiene un coste mayor a la mejora. ¿Va a costar la contramedida más de lo que ayuda? ¿Va a comprometer la calidad? ¿Va a requerir recursos adicionales para llevarla a cabo? ¿Va a ser aprobada?
– Impacto: finalmente, es importante clarificar en que forma y grado va a afectar la contramedida a nuestra situación actual.
En el ejemplo de este post, algunas de las contramedidas fueron definir métricas y activar las herramientas que nos permitiesen medirlas para contrarrestar la falta de visibilidad de la calidad del código, e implementar buenas prácticas de desarrollo de software que nos ayudasen a reducir el número de bugs generados por Sprint.
Ya tenemos las contramedidas que queremos llevar a cabo, ¿cómo vamos a implementarlas? En el libro The A3 Workbook: Unlock Your Problem-Solving Mind, el autor habla de las 3Cs necesarias para implementar con éxito las contramedidas:
– Crea el plan: es importante determinar qué significa exactamente “definir métricas” o “implementar buenas prácticas de desarrollo”. Necesitamos aterrizarlo y traducirlo a acciones concretas.
1. Lista los pasos requeridos: cómo determinar que personas deberían participar en el proceso de definición de métricas, crear el espacio de reunión para discutirlas, etc.
2. Ponlos en orden: ¿que va primero? ¿cuales son las dependencias? ¿en que secuencia los ejecutamos?
– Comunica el plan: Una vez que lo hemos creado, todo el mundo debe conocer que es lo que vamos a hacer, en que nos hemos basado para decidirlo y que objetivos esperamos conseguir. Ten los A3 colgados en el board, así cómo su seguimiento, para que todo el mundo pueda leerlos.
– Haz seguimiento (carry on) de el plan: por muy buenas intenciones que tengamos en nuestro plan, no podemos asumir que funcionará sin más. Una vez creado el plan de implementación que vamos a seguir, debemos revisarlo en intervalos regulares, cambiándolo o añadiendo nuevos pasos si lo vemos necesario. También debemos hacer a todo el mundo responsable del mismo, y de conseguir los objetivos que se encuentran en el A3.
El propósito final de un A3 es conseguir el objetivo que nos hayamos marcado (no esta de más recordar que dicho objetivo incluye no únicamente resolver el problema actual, sino implementar las medidas que permitan que no vuelva a reproducirse en el futuro). Para ello, debemos evaluar los resultados de las contramedidadas periodicamente. A menudo cometemos el error de quedarnos unicamente con las acciones que vamos a realizar, sin planificar su seguimiento.
¿Cómo vamos a verificar sus resultados?
La forma más lógica de hacerlo es utilizar el mismo criterio que usamos para plantear la situación actual. Si en el ejemplo actual nos basamos en el ratio de número de bugs abiertos vs cerrados, y en las valoraciones en la xxx store, estas son probablemente las mejores métricas a utilizar para medir el grado de efectividad de nuestras contramedidas.
¿Cuando vamos a verificarlos?
Determinar la periodicidad con la que vamos a establecer puntos de control no es tarea fácil, intentaré explicar porque. La siguiente curva representa el progreso de la mejora que habitualmente esperamos.
Sin embargo, uno de los posibles efectos que pueden suceder y que debemos ser siempre conscientes a la hora de introducir cambios, es el explicado por la Curva J, representada en el siguiente gráfico.
Lo que nos dice la Curva J es que, al introducir cambios en el sistema, no experimentamos las mejoras desde el primer momento, sino que habitualmente hay un tiempo de adaptación a dichos cambios en el que, probablemente, la métrica empeorara. ¿Porqué es importante tener la curva J en cuenta siempre que introducimos cambios? Peter M. Senge explica en su libro The Fifth Discipline: The Art & Practice of The Learning Organization, una de las limitaciones que sufren las empresas en su búsqueda de convertirse en “learning organizations”: confundir ser reactivo con ser proactivo (“The illusion of taking charge”, Capítulo 4)).
Imaginemos por un momento que nuestra implementación de las contramedidas toma forma de curva J y, o bien no lo percibimos, o erramos estimando cuando tiempo estaremos por debajo de la situación actual hasta empezar a obtener resultados. Pongamos que nuestras contramedidas tardarán dos meses (cuatro sprints) en empezar a dar frutos, y nosotros inspeccionamos cada Sprint. Mejor dicho, “reaccionamos” cada Sprint, aquí esta la trampa de la que intenta prevenirnos Peter M. Senge, en el “overreact”. Lo que nos vamos a encontrar es que tras el primer Sprint la situación será peor que la original. Tras el segundo, probablemente será peor aún. El efecto al que se refiere Peter M. Senge en su libro, es el provocado por la falta de visión de cuanto tiempo tardaremos en ver los resultados. Un exceso de celo, nos podría llevar a, tras el segundo Sprint, dar por no validas las contramedidas, abandonarlas y buscar otras. No solo sufriremos el coste que ya hemos pagado (el tiempo que hemos estado por debajo de la situación original) sino ademas el que nos va a tomar volver a la situación original, y volver a preparar contramedidas.
Es fácil imaginar lo peligroso que puede llegar a ser este exceso de overreact. Nos podemos encontrar “atrapados en el tiempo”. Volvemos una y otra vez a repetir este ciclo, llevándonos a una situación en las que constantemente estamos adoptando cambios, abandonando los anteriores ante la creencia de que estos no funcionan, dado a que nunca damos el tiempo necesario para que se obtengan resultados.
No me entendáis mal, no estoy defendiendo el extremo contrario, no reaccionar ante la falta de resultados. Inspect and Adapt es y debe ser un principio fundamental en nuestra búsqueda de la mejora continua. Con todo esto tan solo quiero resaltar que ser conscientes de cómo de profunda puede llegar a ser la curva de una contramedida es importante, recuerda el punto en que evaluábamos si era Factible implementarla. Si prevemos que implementar una contramedida puede provocar un profundo “valle” durante un tiempo T, siempre podemos implementar contramedidas “de corto plazo”, aquellas que decíamos que van orientadas a mitigar y proporcionar cierto alivio en la situación, actual o provocada por la implementación de una contramedida a largo plazo. Esto de anticiparse a situaciones que no son un problema ahora pero podrían serlo en el futuro tenia un nombre, que no es ni Kaizen ni Iji, ¿no?
En el ejemplo que hemos estado siguiendo, tomó más tiempo de el esperado empezar a obtener resultados. En la siguiente gráfica, es fácil ver que pese a obtener resultados en el corto plazo, la tendencia en el descenso del ratio de bugs es menos pronunciada de lo esperado.
Tras conseguir estabilizarse en un ratio cercano al 1:1, el equipo debe tomar decisiones que escenifican el efecto de la curva J. Llega un momento en que las mejoras que puede seguir realizando sin entrar a hacer grandes cambios en la arquitectura, son poco significativas. El ratio se ha estancado. Para poder seguir avanzando en la mejora, debe realizar cambios que afectaran al Core de la aplicación, y no es trivial (algo que podemos ver gracias en gran parte a que nos hemos dotado de métricas, y herramientas para visualizarlas).
Sin una correcta cobertura en el código, sabemos que, aunque hemos adoptado contramedidas “de corto plazo” como ampliar significativamente los esfuerzos en testing manual, automatización, etc. inevitablemente al hacerlo hay una alta probabilidad de desestabilizar la aplicación y sufrir un alto número de bugs en los siguientes sprints. Tras el Sprint 47 tomamos la decisión de que es necesario acometerlo, los efectos son claramente visibles en el Sprint 49.
Ninguna lectura puede sustituir el “learning by doing”. Espero que este post pueda animaros a utilizar A3 thinking en vuestros equipos, y servir para tener una pequeña guía que ayude a arrancar.
En su libro Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System, los autores comentan que un problema constante que encuentran es la suposición errónea de que sólo hay una manera de escribir un A3 o una plantilla corporativa que practicantes deben utilizar. Siempre hay valor en la normalización, sin embargo la aplicación de una plantilla estándar a todas las situaciones causará tantos problemas como se va a resolver. Por si puede ser de ayuda, en este enlace podéis encontrar la plantilla utilizada en este post para realizar vuestro A3 en formato Word.
(1) En toda la literatura referente a A3 thinking, es habitual la referencia al supervisor o manager. Es importante notar que la importancia de esta figura no radica tanto en la aprobación de la propuesta A3, si no en su función de mentor. Lo que se espera del manager no es juzgar o limitar las propuestas de mejora, si no actuar de acuerdo a la filosofía “lead as a coach”. Ayuda al autor del A3 en su proceso de aprendizaje, mediante la observación. ¿Se ha identificado correctamente la situación actual? ¿Se ha tenido en cuenta la verdadera raíz del problema que se quiere solucionar? La propuesta, ¿soluciona simplemente el problema o permite a la vez que no vuelva a reproducirse en el futuro? Etc. Esta tarea de ayuda al aprendizaje, y no otra, es la función del supervisor.
(2)El día que encuentre tiempo para ello (y aprenda más de los que sé ahora), estoy deseando poder escribir lo aprendido sobre Toyota Kata, y poder entrar en profundidad en la diferencia entre targets y goals.
(3) El uso de la técnica 5Whys no implica preguntarse exactamente 5 veces porqué. Durante la investigación para este post, encontré una anécdota que ilustra este punto. Uno de los autores comparte que, durante su estancia en Toyota, al preguntarle a su mentor porqué cinco, este le respondió que muchos números impares se consideran “de la suerte” en Japón. Tres habría dado poca profundidad al problema, por lo que probablemente se optó por hacer al menos cinco. Al fin y al cabo, cuando estas tratando de resolver un problema, un poco de suerte nunca viene mal.
CNatra	de March 2, 2015 a las 9:42 pm
Excelente artículo Jaume.
Hace mucho no aprendía tanto de un tirón.
Ahora a lo dicho: learn by doing.
Samuel Casanova	de March 13, 2015 a las 3:53 pm
Insuperable el post, no conocía esta técnica, y tal y como la iba leyendo estaba pensando que este formato es perfecto para una retrospectiva “seria”. De hecho creo recordar haber leído algo de literatura sobre Lean Retrospectives en las que el proceso era algo muy parecido. Sin duda un post que va directo a mi caja de herramientas LEAN.

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución