Cómo hablar Kata de mejora

Hace ya bastante tiempo que practicamos el Kata de Mejora, pero seguimos luchando con el significado de los diferentes términos, y cómo aplicarlos. Después de leer este artículo deberías tener una visión clara de las partes del Kata de Mejora, lo que significan y cómo aplicarlas. .

¡Comencemos!

Proceso vs. Resultado

Antes de sumergirnos en los detalles del lenguaje de la Kata de Mejora, deberíamos empezar por distinguir entre el proceso y el resultado. Ésta es quizá la parte más difícil de la Kata de Mejora. Estamos acostumbrados a pensar en objetivos y resultados y en lo que queremos conseguir. Queremos llegar a nuestros números de producción. Nos centramos en el resultado. Con la Kata de Mejora nos centramos en el proceso que conduce a un resultado. Debemos poner el proceso en primer plano, y el resultado es la consecuencia del proceso. Siempre intento explicarlo de esta manera:

• No se puede llevar a cabo un objetivo o un resultado.

• Pero sí se puede llevar a cabo un proceso.

¿Por qué es difícil?

Este cambio de mentalidad es la parte más difícil de la Kata de la Mejora. Desde pequeños nos han enseñado a pensar en resultados. Tenemos que fijar objetivos audaces y alcanzar las estrellas. No está arraigado en nuestra cultura pensar en el proceso. Así que tenemos que hacer este cambio de mentalidad para aprender a hacer esta distinción y centrarnos en el proceso.

La mejora del trabajo diario es más importante que el trabajo diario. Pero no sustituye al trabajo diario.

Antes de empezar, un resumen

Este es un esquema general del proceso de la Kata de Mejora. Hablaré de las diferentes partes en este artículo, puedes usar esta imagen como referencia.

El verdadero norte: nuestra visión de la empresa

Queremos ser una empresa tranquila. Y creemos que esforzándonos por lograr estas cuatro cosas en nuestros procesos lo conseguiremos:

• Flujo de artículos único, en secuencia y a la carta.

• Cero defectos.

• 100% de valor añadido.

• Seguridad para las personas.

• Seguridad para las personas.

Examinémoslas más a fondo.

Flujo de artículos individuales, en secuencia y a la carta

Este es uno de los principios fundamentales de la Kata de mejora. Antes de hacer cualquier otra cosa, debemos acercar un proceso, cualquier proceso, a ser un flujo de un solo elemento, en secuencia y bajo demanda. Pero, ¿por qué?

Queremos un proceso estable y predecible. Queremos un proceso escalable y sin muchos residuos. Para conseguirlo, necesitamos ver los cuellos de botella de ese proceso. Pasar a un flujo de artículo único muestra esos cuellos de botella lo antes posible. Y con mayor claridad. Hay que resolverlos, o de lo contrario nada podrá fluir por el proceso.

Si tenemos un proceso de flujo de un solo elemento, en secuencia, no podemos cortar por lo sano y acelerar las cosas para que se hagan. Tenemos que eliminar un cuello de botella en el proceso antes de poder seguir adelante. Mientras no estemos ahí podemos hacer trampas. Si puedes ver claramente el cuello de botella de un proceso, puedes empezar a solucionarlo y mejorar el proceso, lo que conduce a mejores resultados.

Zero defects

Cada vez que un proceso no funciona según lo definido, tenemos un defecto. Por tanto, un defecto se centra en el proceso, no en el resultado. Cada defecto debe investigarse para aprender de él.

Muchos problemas equivalen a un jefe feliz.

100% de valor añadido

Todo lo que hacemos en un proceso debe añadir valor al resultado final del proceso. Si hacemos cosas en nuestro proceso que no añaden valor, no debemos hacerlas. Esto también se conoce como eliminar los residuos de un proceso.

Muchos debates sobre "lean" se centran en la eliminación de los residuos. Se parte de la base de que la eliminación de los residuos es un objetivo de la gestión ajustada, mientras que la eliminación de los residuos es en realidad un resultado de la Kata de Mejora. No es un objetivo en sí mismo.

Seguridad para las personas

Todas las cosas que hacemos deben atenerse a este principio. Cuando fijamos un reto, una condición objetivo o la descripción de un proceso, siempre tenemos que comprobar si está dentro de este límite.

La gente comete errores. Los sistemas que tenemos implantados deben ayudar a evitarlos o, si ocurren, deben reducir las consecuencias de un error. Cometer errores debe ser seguro. No deben provocar catástrofes. Y si se produce un suceso catastrófico o menos catastrófico, tenemos que mejorar los sistemas.

La seguridad de las personas también significa que todo el mundo puede ser él mismo en el trabajo. Debemos poder hablar, dar nuestra opinión y compartir conocimientos. Así es como aprendemos como personas y como organización.

Estado actual

Si hablamos de la situación actual, hablamos del proceso que queremos mejorar. En un mundo perfecto, este proceso debería tener una descripción clara. Esta descripción debería decir cómo nos gustaría que funcionara el proceso. La descripción debería contener:

• Todos los pasos del proceso.

• El tiempo que puede durar cada paso.

• Cuántas personas trabajan en un paso.

• Cualquier métrica de calidad de este paso.

• Cuánto inventario se permite por paso.

• El tiempo de ciclo total del proceso.

También puede contener una descripción de las características de este proceso. Debe mencionarse cualquier preocupación relativa a la seguridad de las personas y, por último, pero no por ello menos importante, debe incluir una métrica de resultados.

En el caso de un proceso nuevo, esta descripción puede hacerse sobre la marcha. Mientras trabajamos para mejorar el proceso, descubrimos cómo debe funcionar. Esto puede y debe escribirse para que pueda utilizarse como documentación sobre el proceso. Y, mientras cambiamos y mejoramos el proceso, esta documentación debe actualizarse. Verás que cuanto más tiempo trabajes en un proceso, más se perfeccionará.

¿Por qué es difícil?

Para poder pasar a un flujo de elementos único y no acabar con optimizaciones locales, tenemos que esforzarnos por conseguir un solo proceso. Cuidado con describir un proceso como un proceso independiente, que en realidad forma parte de un proceso mayor y, por tanto, es un subproceso en sí mismo.

Cuando empezamos a aplicar la Kata de mejora, teníamos un proceso de desarrollo, un proceso de pruebas y un proceso de documentación, traducción y comunicación. Me costó convencer a desarrollo de que teníamos que incluir el proceso de prueba como parte del proceso de desarrollo total. Porque al mejorar el ciclo de desarrollo, pero no poder probar y desplegar historias, habíamos creado un despilfarro.

Tenemos que optimizar el conjunto.

Ejemplo

Utilicemos un ejemplo para ilustrarlo. Nuestro proceso para ofrecer valor a los clientes se compone de los siguientes subprocesos para poner una función en línea:

• Decidir qué construir - 3 semanas

  • Recopilar información sobre solicitudes de características (bajo demanda)

  • Ranking de solicitudes de características para obtener una prioridad (en secuencia).

  • Describir esta característica y planificar su desarrollo.

• Desarrollar una historia - 3 días

  • Discutir con el propietario del producto.

  • Define los criterios de aceptación.

  • Diseña, construye, revisa el código.

  • Refactoriza el código.

  • Prueba con el equipo.

• Testear y desplegar una historia - 3 horas

  • Construir la historia a staging.

  • Ejecutar pruebas de aceptación.

  • Probar una historia.

  • Mergir historia.

  • Desplegar a producción.

• Traducir - 1 día

  • Crear paquete de un solo elemento para esta historia para los traductores.

  • Enviar el paquete a los traductores.

  • Los traductores traducen las etiquetas de esta historia.

• Documentar y comunicar - 3 días

  • Escribir notas de publicación.

  • Escribir, actualizar y publicar artículos de ayuda.

  • Comunicarse con los clientes relevantes.

Tenemos mucha documentación para cada paso en la que se describe la calidad a la que hay que atenerse, cuántas historias puede haber en cada paso, cuántas iteraciones se permiten y cuántos defectos se permiten en una historia. Sería un artículo aparte.

Lo importante de todo esto es que para optimizar el conjunto hay que tener todos los pasos de un proceso y medirlos. Si no lo haces así, la optimización de un paso supondrá un despilfarro en otro.

Métrica de resultados

La métrica de resultados describe lo que produce un proceso. Es el resultado del proceso. Medimos la métrica del resultado de vez en cuando para comprobar si el proceso sigue por el buen camino para ofrecer el resultado deseado a la empresa. Es lo que otras empresas utilizan como objetivos o metas.

¿Por qué es difícil?

Lo que nos resulta difícil es distinguir claramente entre resultados (métrica de resultados) y proceso. Y una vez definida una métrica de resultados, de repente parece un objetivo. Que tenemos que cumplir, y que nos decepciona no alcanzar. El único propósito de la métrica de resultados es poder medir si nos acercamos a donde queremos estar.

Ejemplo

La métrica del resultado de nuestro proceso de desarrollo es que queremos lanzar una función de 100 dólares cada tres meses por equipo. Creemos que lanzar cada mes una función que aporte valor a nuestros clientes nos proporcionará el crecimiento que la empresa necesita para estar tranquila.

Desafío

El reto describe el estado futuro de su proceso que desea alcanzar. Lo difícil de esto es tener en cuenta que estamos hablando del proceso, no del resultado. Debes describir cómo te gustaría que funcionara el proceso, y no un objetivo o un resultado. Un reto puede plantearse muy lejos con un plazo largo, entre seis semanas y un año. Si ya sabes cómo llegar, está demasiado cerca. El reto da una dirección, y se desglosará en condiciones objetivo más pequeñas.

El mejor lugar para empezar a definir el reto es llegar al flujo de artículos individuales. A continuación, hay que esforzarse por conseguir el flujo secuencial y, por último, la demanda. Conseguir el flujo de artículos individuales y en secuencia nos llevó dos años.

¿Por qué es difícil?

Una vez más, esto se reduce a pensar en procesos y no en resultados. Para mucha gente es difícil enfrentarse a la incertidumbre de no saber cómo llegar.

Ejemplos

Cuando empezamos con la Kata de Mejora nos planteamos el reto de pasar a un flujo de un solo elemento para publicar una historia. Así, cuando una historia estaba lista debía ponerse en línea.

Otro ejemplo es el subproceso de traducciones. Definimos el reto así:
En un plazo de tres meses, conseguir un flujo de un solo elemento para las traducciones, con un tiempo de ciclo de un día, sin dedicar tiempo a responder preguntas.

Condición objetivo

Un estado objetivo es el primer paso que te acerca a tu reto y que es alcanzable en un plazo de tres a seis semanas. Es el estado futuro del proceso al que aspiramos. La condición objetivo nos dará un sentido de dirección para nuestras mejoras. ¿Cómo? Medimos nuestro proceso de trabajo mientras trabajamos. Cada vez que nos desviamos del proceso descrito en la condición objetivo, tenemos que investigarlo. Lo llamamos "análisis de la causa raíz" (ACR). Hacer los ACR nos proporcionará información sobre nuestro cuello de botella.

Ejemplo

Para el reto sobre las traducciones definimos esta primera condición objetivo:
Define y mide el tiempo que se tarda en traducir un único artículo a todos los idiomas. Queremos medir por idioma.

Cuello de botella

A veces nos hemos referido a esto como un obstáculo. Pero la palabra cuello de botella es mucho más adecuada para describir lo que es. Un proceso sólo puede tener un cuello de botella (pero muchos obstáculos). El cuello de botella es lo que nos impide llegar a nuestra condición objetivo.

Si observamos un reloj de arena, la parte más pequeña es el cuello de botella. Aumentar el tamaño del reloj de arena antes o después del cuello de botella no aumenta el flujo. Mejorar todo lo que no sea el cuello de botella es un despilfarro. El cuello de botella impide que el artículo fluya a través del proceso sin interrupciones, o es la parte del proceso con el rendimiento más bajo.

Sólo la mejora del cuello de botella le acercará a su objetivo. Resolvemos el cuello de botella mediante un ciclo PDCA (más adelante hablaremos de ello).

¿Por qué es difícil?

Lo más difícil es definir el cuello de botella. Cuando empiezas a mejorar y le coges el tranquillo ves muchas cosas que se pueden mejorar pero que no son el cuello de botella. Es difícil resistirse al impulso de resolver esas cosas, sobre todo cuando se trata de pequeñas cosas que se pueden hacer. Resolver el cuello de botella es difícil y requiere disciplina. Por otra parte, aunque la teoría dice que sólo hay un cuello de botella, resolver algo siempre es mejor que buscar el cuello de botella y no resolver nada. Hacer una mejora te lleva a practicar los ciclos RCA y PDCA.

Mejorar lo que debe mejorarse, no lo que puede mejorarse.

Ejemplo

Para nuestro ejemplo de traducción, definimos el primer cuello de botella de la siguiente manera:
No saber en qué consiste un artículo. No hemos definido un artículo y no sabemos qué etiquetas y páginas que hay que traducir forman parte de ese artículo.

RCA

Como ya he explicado, RCA es la abreviatura de "análisis de la causa raíz". Cada vez que nos desviamos de nuestro objetivo, hacemos un ACR para averiguar la causa. Encontrar la causa raíz nos mostrará el cuello de botella.

¿Por qué es difícil?

Una desviación de la condición objetivo nunca se produce en un momento conveniente, la mayoría de las veces hay que molestar a la gente para que se reúna para hacer el ACR. Nos gusta hacer el ACR lo más cerca posible del momento en que se produce la desviación para que el rastro de información no se enfríe. Por tanto, hacer el ACR es un compromiso entre no trabajar con fluidez y mejorar a diario.

El otro día tuve una discusión con Maarten, Front-End Developer & UX Designer, sobre una función que tardó mucho en estar en línea. Se desarrolló así:

Maarten: Por fin tenemos la historia que genera automáticamente las imágenes para la documentación online. Nos ha costado dos RCA y mucho trabajo conseguirlo.
Yo: no te preocupes porque haya llevado más tiempo del previsto, porque hemos aprendido mucho en el proceso.
Maarten: Sí, los ACR que hicimos cambiaron mi forma de pensar de "este proceso es inestable" a "¿por qué es tan inestable este proceso?".

Con este cambio de mentalidad puedes empezar a buscar la causa y pensar en soluciones. Con la mentalidad anterior solo conseguirás enfadarte y frustrarte y no mejorarás nada.

Tenemos que ir más despacio para ir más rápido.

PDCA

PDCA es la abreviatura de "Planificar, Hacer, Comprobar, Actuar". Es el proceso para mejorar un cuello de botella en pequeños pasos. El reto consiste en dar un pequeño paso para mejorar el proceso. Algo que puedas hacer hoy mismo. Para algunas cosas, obviamente necesitamos más tiempo. Por ejemplo, si necesitamos desarrollar o automatizar algo. Pero siempre debemos intentar hacer las cosas más pequeñas. ¿Podemos hacer primero una mejora a mano para ver si nos acerca a la condición objetivo? Si es así, ¿podemos automatizar? Una pequeña mejora desplazará nuestro campo de visión y aumentará nuestro umbral de conocimiento. Después de la mejora vemos y sabemos más.

Una mejora demasiado grande puede llevar al despilfarro porque no nos acerca al reto. Por eso las mejoras deben ser pequeñas. Sólo podemos hacer una mejora por proceso y día. De lo contrario, no sabremos si la mejora ha servido realmente para mejorar algo.

¿Por qué es difícil?

La mayoría de las veces vemos muchas cosas que se pueden mejorar. Y queremos quitarlas de en medio, pensando que así se solucionarán todos los problemas, para poder seguir con nuestro trabajo. Pero no sabemos si todos esos problemas siguen existiendo cuando hacemos algunas pequeñas mejoras.

Otra cosa difícil es no pensar demasiado en el futuro y ver todos los obstáculos del camino. No sabes si esos obstáculos se materializarán realmente cuando estemos allí. Y, si ese obstáculo es realmente el cuello de botella. Así que no lo sabemos hasta que llegamos allí.

Dar pequeños pasos es maximizar el trabajo no hecho. Llegaremos cuando lleguemos.

Campo de visión o umbral de conocimientos

El campo de visión o umbral de conocimiento es lo que actualmente sabemos y lo que podemos ver. En este campo de visión hay muchas mejoras posibles. El reto nos dará una dirección para nuestras mejoras. Si realizamos una pequeña mejora, desplazaremos nuestro campo de visión (línea azul) y aumentaremos nuestro umbral de conocimientos en la dirección del reto. Después de este cambio, sabemos más y podemos ver otras mejoras y pasos que podemos dar para alcanzar nuestro reto.

¿Por qué es difícil?

Nos culpamos por no haber visto mejoras antes. Puedes pillar a alguien diciendo "¿por qué no hicimos esto el año pasado?.

Tengo que citar aquí al famoso futbolista holandés Cruijff:

Je gaat het pas zien als je het doorhebt.

Traducido aproximadamente a:

Sólo lo verás cuando lo entiendas.