Taiichi Ohno, Estándar y Kaizen

 

"Donde no hay estándar, no puede haber kaizen (mejora continua)" - Taiichi Ohno

---

"Where there is no standard, there can be no kaizen (continuous improvement)" - Taiichi Ohno

---

New Minibook: Some Ideas for Agile Team’s Retrospectives

More than two years ago, after sharing a meetup on Retrospectives in Mexico City, I observed that were retrospectives, so useful in Agile frameworks, was not being conducted in a way that would generate the desired impact, which is: ACHIEVING THE IMPROVEMENT OF TEAM PERFORMANCE.

Due to the above, the idea of ​​this minibook entered my backlog of pending to build, and today I am finally sharing it with the Agile community and with all those who want to take their work teams to a mindset of continuous improvement.

Some Important Notes from the Mini-Book

The illustrations were made by my wife Diana Apráez, the launch flyer was designed by my daughter Mariana, translation by Dhiraj Bellara - @BellaraDhiraj, additionally I asked colleagues and friends of the Latin American Agile Community to collaborate with me with their reviews, prologues, advices and revisions, thanks again: Diana, Nadia, Lucho, Carlos Palacio, Carlos Quiroga, Carlos Serna, Wbeimar, Juan Andrés, Jaime, Augusto, Alma, Roberto, Daniel and Leonardo for all your contributions.

For the English edition, Ben Linders -https://www.benlinders.com/- did me the honor of writing a Foreword.

I share it below.

Foreword by Ben Linders

Retrospectives are not a new thing. They became widely known through the agile manifesto, the Scrum Guide, and by books like Project Retrospectives by Norm Kerth and Agile Retrospectives by Esther Derby and Diana Larsen. The practice of reflecting to learn and improve is much older. I was doing it already in the past century, by assisting people to form a shared picture of what's happening to learn and improve. 

The main thing that we can learn from agile is that retrospecting is a team activity. It's up to the team to find out, acknowledge, and take action. The retrospective facilitator is there to assist the team, to provide the environment, and foster a culture where people feel safe to speak up. Having said that, facilitating is not an easy thing to do.

Many people still seem to struggle when facilitating retrospectives. Expectations are often high, which makes it even harder. Jorge's book brings together many useful practices and suggestions that can help you to facilitate retrospectives that help teams to become a better version of themselves. Use the book to experiment in your retrospectives, and see what works for you. Don't worry if something goes wrong, remember the Prime Directive and use it to learn from things that didn't work. Occasionally you may want to retrospect your retrospectives too. 

Wishing you a wonderful journey of learning and improving!

- Ben Linders

----

Thanks a lot Ben for this foreword!

Thanks a lot Dhiraj for the translation!

www.amazon.com/-/es/dp/B08R6YVSCJ

Agile greetings / Saludos ágiles

Jorge Abad

Sobre La Mejora Continua

La Mejora Continua no tiene como propósito ser cumplida por el proceso, esta ahí para hacernos inalcanzables.

Retrasar el realizar una mejora es reducir la probabilidad de supervivencia de la organización

Más de un millón de mejoras en el año en Toyota

Hola a todos

Con frecuencia citamos cosas por que las hemos escuchado de personas que son relevantes para nosotros y que son referentes.

Hace un tiempo escuché y constantemente compartía algo que varios referentes decían:

 "En Toyota se hacen más de un millón de mejoras en el año con su proceso de mejora continua o Kaizen"

Decidí averiguar la referencia a esa cita y un agilista, Hugo Suaréz me proporcionó la referencia exacta,

Kaizen, la clave de la cultura Japonesa por Masaaki Imai

y la Cita exactamente reza:

"Una de las características de los trabajadores japoneses es que usan tanto el cerebro como las manos. Nuestros trabajadores proporcionan 1.5 millones de sugerencias al año y el 95% de ellas se ponen en uso práctico. Existe un interés casi tangible por el mejoramiento en el aire de Toyota" 

Eiji Toyoda, Presidente del Consejo de la Toyota Motor.

Gracias Hugo por la referencia y esta es una invitación a no detenerse, quiero invitarlos a:

no caer en la tentación de realizar mejora continua por que lo dice el proceso, el framework, el marco, la metodología, o la norma, esta aproximación es una mala interpretación del método de Toyota y se aleja radicalmente del propósito del Kaizen, hay que hacer mejora continua por que es la única forma de hacernos inalcanzables.

Gracias a mis amigos y referentes que han compartido información que es verídica y comprobable, suena obvio, pero es importante saber a que líderes seguir en el mundo empresarial y de la agilidad.

Saludos ágiles


Jorge Abad

[Tip Scrum]: Slack o el Tiempo para Afilar el Hacha en Scrum

Hola a todos

Comencemos con una historia para ilustrar el concepto

"Dos hombres determinan hacer una competencia en la cual deben lograr derribar un árbol en el menor tiempo posible. Ambos se lanzan a la obra, llenos de energía y convencidos de que el premio pronto estará en sus manos.

Al blandir sus hachas, vuelan las astillas y los espectadores miran con asombro como el corte en ambos árboles se va profundizando con cada hachazo.

De repente uno de los dos competidores se detiene. El público queda sorprendido al observar que saca una pequeña lima de su bolsillo y comienza a afilar su hacha con toda calma.

Su oponente está feliz. Sigue golpeando con aún mayor fuerza su árbol y muy pronto el corte que está haciendo llega a ser tan grande que su victoria parece ser evidente.

Hasta el momento en el cual el hombre que afiló su hacha vuelve al trabajo. Un, dos y tres. Con solo un par de golpes acertados su árbol comienza a crujir y, ante la sorpresa de todos los espectadores, se derrumba a los pies del hombre sabio, quien supo lo importante que era contar con una herramienta en óptimas condiciones."(1)




Ahora sí...

Entre mis compañeros coaches con los cuales comparto actualmente, es muy común un término que ellos acuñan como "afilar el hacha", yo lo conocía como Slack ( referido en el post  Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - clic aquí- )  y es un tiempo que se separa durante o entre sprints para que los equipos o las personas afilen el hacha y mejoren su forma de trabajo.

Dentro de las formas de seleccionar este tiempo están técnicas como:

• dejar un tiempo pequeño entre sprints de 1 a 2 días 
• 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
• El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
• Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
• ver más en Cutting Slack in Scrum

Hasta acá este pequeño pero poderoso compartir.

Preguntas poderosas para ti y tu equipo

• ¿hace cuánto no afilas el hacha en tu equipo?
• ¿qué te lo impide?
• ¿qué es necesario hacer para lograr afilar el hacha en tu equipo con frecuencia?
• yendo un poco más allá, ¿en tu empresa, en tu relación de pareja, en tu vida hace cuanto no afilas el hacha?

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Tomado de : http://www.grandespymes.com.ar/2011/04/17/el-concepto-de-afilar-el-hacha-para-lograr-ser-mas-efectivo/

Una de las claves de Scrum : Fail Fast - Fallar Rápido

Hola a todos...

Cada vez que tengo una retrospectiva con los equipos en los que soy Scrum Master, vivo, comprendo y profundizo más en el concepto del:

Fail Fast

Fallar Rápido

Pues noto que los ciclos cortos de inspección y adaptación, de retroalimentación (Sprints de 2 a 4 semanas), habilitan y potencializan el PHVA - Planear Hacer Verificar y Actuar - (PDCA - Plan Do Check Act - en inglés) y la mejora continua del ciclo de Deming de una manera sorprendente.

Miremos a Scrum [1] desde esta óptica del PHVA:

• P - Planear = Sprint Planning
• H - Hacer = Ejecución del Sprint (tiempo que transcurre entre el fin del planning y la review)
• V - Verificar = Reunión de Review (se identifica si se cumplió o no con lo comprometido, con su respectivo criterio de DONE / HECHO/ REALIZADO)
• A - Actuar = Retrospectiva, encontrar en cualquiera de los pilares de scrum (Producto, Procesos, Equipo):
• qué se está haciendo bien, para continuar haciéndolo
• qué se esta haciendo mal, no tan bien, o se puede mejorar para desecharlo, mejorarlo (kaizen) y/o corregirlo.

Adicionalmente, el hecho de tener que cerrar el ciclo, obliga a parar y presentar el producto en el estado en que se encuentre para el Review, logrando que el Equipo Scrum (Product Owner, Scrum Master y Equipo de desarrollo) aprenda sobre:

• el cumplimiento de los compromisos adquiridos
• la transparencia y
• la efectividad de los cambios y mejoras realizadas (ya sea al Producto, Proceso y/o Equipo) y propuestas en el sprint pasado.

Por lo tanto, tener ciclos de construcción de producto cortos hace que el ejercicio de Scrum lleve al Equipo Scrum a fallar rápido y de forma frecuente permitiendo que se encuentre prontamente con las mejoras que impulsarán a todos a tener victorias tempranas y lograr el éxito en el producto que se está construyendo,

El fallar rápido permite al Equipo Scrum a:

• encontrar los errores pronto
• aprender de estos errores pronto y no permitir que te acostumbres a ellos
• realizar un proceso de mejora exploratorio, basado en:
• encontrar las mejoras a realizar, 
• proponer las mejoras como hipótesis, 
• priorizar las mejoras a realizar 
• construirlas como historias de usuario técnicas, con criterios de aceptación
• intentar pocas mejoras, en vez de muchas (recomiendo a lo sumo 3, pero obvio existiran particularidades y escenarios en que sean más o menos) 
• poner estas mejoras como lo primero del sprint backlog [5]
• ejecutarlas en el próximo sprint,
• validarlas y adoptarlas o desecharlas
• comenzar un nuevo ciclo identificando elementos a mantener, nuevas fallas y nuevas mejoras

Nota: Es responsabilidad del Scrum Master ser habilitador de esta mejora continua, aunque es importante aclarar que en un equipo Scrum, la mejora viene de cualquier miembro del equipo (o de los stakeholders), y esta mejora aparecerá tanto en la retrospectiva como en el día a día del sprint.

Este ciclo exitoso de continuo PHVA retroalimentado, es lo que ayuda a que en cada Sprint se identifiquen mejoras simples y sorprendentes de los componentes de Scrum de una manera natural, estimulante e intuitiva, permitiendo la evolución (mejora continua) rápida de Producto, Proceso y/o Equipo.

Recuerdo bien el espíritu de una frase (no recuerdo ni la frase exacta, ni el autor):

Te perdono que falles, lo que no te perdono es que no aprendas

Hasta acá mi reflexión, no quiero ahondar más en el tema, pues pienso que otros lo han hecho mejor que yo. por lo tanto, a continuación copio varios artículos[6], e imágenes que explican mejor este punto de vista.

Saludos ágiles

Jorge Abad.

Referencias

[1] Guía de Scrum - https://www.scrum.org/Scrum-Guides
[2] Mi evolución sobre las retrospectivas en Scrum - http://lecciones-aprendidas.blogspot.com/2013/04/mi-evolucion-sobre-las-retrospectivas.html
[3] Fail often, fail well -http://www.economist.com/node/18557776?story_id=18557776&utm_source=buffer&utm_campaign=Buffer&utm_content=bufferb5099&utm_medium=twitter
[4] Cómo es un día en pixar, según su director dearte -  http://www.enter.co/#!/eventos/campusparty/2013/jay-shuster-narro-en-cpco6-como-es-un-dia-en-pixar-animation-studios/
[5] Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - http://lecciones-aprendidas.blogspot.com/2013/08/seis-6-formas-de-lograr-mayor-velocidad.html
[6] En el link ▼ a continuación  se encuentran las referencias citadas.

Seis (6) estrategias para lograr mayor velocidad de los equipos en Scrum

Hace unos días en Ceiba (empresa donde trabajo como Scrum Master)  filosofábamos en equipo la siguiente pregunta:

¿qué era necesario hacer para lograr mayor velocidad (puntos por sprint)?

Nota aclaratoria: no fue presión mía como Scrum Master hacia el equipo, pero si es cierto que yo lancé la inquietud (realizando la Inception :-) como en la película el Origen, de Nolan y Di Caprio)


La respuesta a esta inquietud ha llegado gradualmente, y pienso que es  uno de los interrogantes obligatorios que tiene que plantearse un Scrum Master y que debe plantearle al equipo.

Dentro de las responsabilidades del SM están:

• el seguimiento del proceso
• el coach al equipo
• y dentro de ese coach llevarlo a una productividad mayor (a un doble de productividad según Sutherland - padre de scrum-  [1] )

Hay que reconocer que Scrum nos ha permitido ser muchos más veloces y productivos debido a:

• Involucramiento y compromiso del dueño del producto, que permite resolver inquietudes rápido
• Visibilidad y resolución rápida de impedimentos
• Retrospectivas bien hechas, que nos llevan a la mejora continua
• Empoderamiento del equipo, de forma que este por si mismo se auto-organiza y encuentra la mejor forma de entregar el producto
• Los valores de coraje y compromiso, que han permitido querer ir más allá y poder enfocarnos mucho más en como ser mejores
• Atención a la excelencia técnica, que ha hecho que nuestra deuda técnica cada vez sea menor, lo cual mejora nuestra velocidad. "La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad" [2] (principio del manifiesto ágil). (este punto lo retomaré más adelante)
• Teniendo el equipo motivado y feliz,  equipos motivados son más ágiles "Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo." [2] (principio del manifiesto ágil).

Pero luego de estar allí, es necesario plantearse ¿es posible ser mejores? a continuación entonces, enumero en orden de importancia (según mi criterio) las formas en las que considero y he encontrado que podemos ser más veloces:

1. Seguir el patrón Scrumming the Scrum 

En la conferencia de Jeff Sutherland | "Scrum: The Future of Work" [3], presenta este patrón de scrum como una de las formas de llegar "hiper-productividad" en los equipos

Patrón: Scrumming the Scrum [4]

Este patrón se basa en:

• Identificar y priorizar la(s) mejora(s) (kaizen) a realizarle al proceso de Scrum  en la Reunión de Retrospectiva. Recordemos en la retrospecttiva debemos enfocarnos en:
• cómo mejorar el proceso de elaboración del producto,  el cómo que Scrum no resuelve y deja en libertad a los equipos).
• cómo mejorar la calidad y el producto
• cómo mejorar la felicidad del equipo
• Enfocarse  en la(s) mejora(s)  más importante(s) y críticas. He leído por ahí que máximo 3 cosas muy importantes a mejorar (1, 3 ó 4 no recomiendo ningún número en especial - yo prefiero pocas cosas a muchas -  intenten una opción y concluyan - recordemos que lo que funciona en un equipo no tiene por que funcionar en otro)
• Ponga el Kaizen en el primer lugar del sprint backlog con criterios de aceptación cuantitativos.
• Revise la mejora Kaizen en el Sprint Review como si fuera otra historia.

Beneficios:

• terminar antes
• solicitar mas backlog para el sprint
• incrementar la métrica de "el clima de ayer" para el próximo planning.

2. Seguir el patrón de Interrupción 

Otro de los patrones expuestos en esta conferencia Jeff Sutherland | "Scrum: The Future of Work" [3] para llegar a la  "hiper-productividad", es el presentado a continuación:.

Este patrón es útil cuando el producto ya se encuentra en producción y se requiere atención inmediata a temas específicos.

El patrón se basa en:

• Luego del Kaizen determine una cantidad de puntos disponibles para tareas inmediatas que requiere el Product Owner.
• Si identifica que no se van a consumir úselos en más historias.

Beneficios:

• Equipo dispuesto para atender urgencias con un tiempo asignado para ello, sin que les quite velocidad y compromiso..
• Product Owner contento con su equipo, debido a que pueden atender temas urgentes.

3. Hacer Sprints más cortos 

Esta recomendación nos la dió Ricardo Colusso (@rcolusso) de kleer.la en donde nos sugería realizar sprints de 1 semana.


Beneficios:

• Poder fallar más rápido, debido a ciclos de retroalimentación más cortos.
• Despliegue de producto más rápido

Requerimientos

• Más compromiso del Product Owner
• Más historias de usuario refinadas y cumpliendo el criterio de Ready.
• Historias de usuario más pequeñas

Nota: No he intentado esta sugerencia

4. Tener un backlog refinado y con el criterio de ready

Otra de las recomendación que nos la daba Ricardo Colusso (@rcolusso) de kleer.la y que también remarcaba Sutherland era la necesidad de tener un backlog refinado y con el criterio de ready, esto indiscutiblemente proporciona una visión clara hacia donde va el producto.




Beneficios:

• Visión de producto
• equipo enfocado

Requerimientos

• Más compromiso del Product Owner
• Realizar la reunión de refinamiento al la mitad del sprint
• tener al menos 2 sprints más con historias de usuario cumpliendo el criterio de Ready.

5. Resolviendo la deuda técnica

La deuda técnica es uno de los elementos que termina frenando la velocidad de los equipos y va en contra de la atención a la excelencia técnica (que es uno de los principios del manifiesto ágil).  Recomiendo el post de Henrik Kniberg - The Solution to Technical Debt . Aunque pienso que es un tema de estudio y de compromiso con el cliente, producto, product owner y mismo equipo.

Presento dos gráficas de este post, que muestran la necesidad de detener la deuda técnica y comenzar a "pagarla" antes de que la velocidad de nuestro equipo se vea frenada radicalmente.

Efecto de programar con código apestoso (crappy code) (en español no encuentro una palabra polite para crappy) [4] 

Efecto de trabajar con código limpio (clean code) [4]

Beneficios:

• Velocidad
• entendimiento del código
• excelencia técnica

Requerimientos

• Equipo con coraje y conocimiento técnico
• Equipo y Scrum Master que sepan vender la idea de resolver la deuda técnica el Product Owner.
• Hacer la deuda técnica como parte del kaizen y darle prioridad e  importancia en el proyecto.

Recomendación

• Tener lineamientos técnicos que se cumplan desde el inicio del proyecto.

6. Teniendo una holgura (Slack) cada cierto tiempo

Por último, la holgura o Slack es un tiempo intencional dejado entre sprints para cubrir cualquiera de las siguientes tareas:

• Innovación técnica
• transferencia de conocimiento entre equipos
• realizar ajustes pendientes de soporte y mantenimiento

Algunas de las formas de implementar el Slack son:

• dejar un tiempo pequeño entre sprints de 1 a 2 días 
• 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
• El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
• Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
• etc..

Recomiendo visitar este post: Cutting Slack in Scrum

En conclusión

Si seguimos estas directrices, no dudo que podremos mostrar gráficas de velocidad similares a la que presenta Jeff Sutherland

Incremento de velocidad aplicando los patrones 1 y 2 [4]

 Y pronto estaremos escribiendo artículos y recomendaciones de como ser mejores en Scrum.

Consideración importante respecto a la puntación de historias

Cuando se mejore la velocidad y encontremos qué cosas que antes nos tomaban más tiempo, pero ahora luego de la mejora nos  toman mucho menos,  debemos de tener una consideración importante respecto a la puntuación:

• si tus puntos fueron diseñados poniendo un pivote de  funcionalidad conocido (ejemplo una pantalla con un formulario de 8 campos), no hay lio, ese pivote y las demás funcionalidades las hará  el equipo más rápido y la puntuación seguirá siendo la misma.
• Si tu pivote esta basado en días felices/productivos (ver [7]) (yo uso esa técnica), considera que si haces algo más rápido debes puntuarlo de la misma forma que usabas al principo del proyecto, como si no tuvieras hiper-velocidad o hiper-productividad, ejemplo:
• si una pantalla tipo a= te tomaba  2 días felices (2 puntos).. .pero luego de la mejora te toma un dia feliz (un punto) síguela puntuando como antes, pues esa es la referencia inicial con la que se dimensionó el proyecto y permitirá visualizar la velocidad y la mejora.

Hasta ahora he encontrado estas 6 formas, talvez hayan más o sean realmente menos, si alguien conoce, aprende, o ensaya más y las puede/quiere compartir bienvenidas sean, es importante todos aprender de todos.


Queda abierto el espacio para sus comentarios y experiencias.


Saludos

Jorge Abad


---
Referencias:

• [1] Video - Jeff Sutherland | "Scrum: The Future of Work" - referencia a la productividad del equipo  https://www.youtube.com/watch?feature=player_detailpage&v=RYIPSPWVc8o&t=1457 
• [2] Principios del manifiesto ágil .http://agilemanifesto.org/iso/es/principles.html
• [3] Video - Jeff Sutherland | "Scrum: The Future of Work" https://www.youtube.com/watch?feature=player_embedded&v=RYIPSPWVc8o
• [4] Diapositivas -Jeff Sutherland | "Scrum: The Future of Work" http://scrumlab.scruminc.com/gallery/album/104-scrum-the-future-of-work/
• [5] Henrik Kniberg - The Solution to Technical Debt  http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt
• [6] Cutting Slack in Scrum
• [7] Scrum y XP desde las trincheras. Por Henrik Kniberg. http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf