Las dos caras de la eficiencia

Tiempo aproximado: 11 min.

La semana pasada, tras acabar la lectura de “This is Lean”, hice una encuesta en Twitter y el resultado no fue del todo concluyente. Así que he decidido utilizar el libro como excusa y hablar de algunos temas relacionados con la eficiencia.

Encuesta tras acabar la lectura de "This is Lean"

Encuesta tras acabar la lectura de “This is Lean”

“This is Lean”, el libro

Antes que nada, déjame que haga un brevísima reseña del libro que ha venido a provocar este artículo.

“This is Lean”, de Niklas Modig y Pär Åhlström, es un libro publicado en 2016 con el subtítulo “Resolviendo la paradoja de la eficiencia”. Para mí está dividido en dos partes, aunque no de una manera explícita.

Los primeros cuatro capítulos se centran en la paradoja de la eficiencia, donde se explica muy bien la diferencia entre eficiencia en el uso de recursos (resource efficiency) y eficiencia en el flujo de valor (flow efficiency).

A partir de ahí yo diría que comienza, algo lentamente quizás, una segunda parte del libro en la que explican qué son las metodologías de gestión ajustada de la producción (Lean), concluyendo (ATENCIÓN SPOILER) que Lean es un marco (o incluso un paradigma) para definir estrategias operativas de negocio, en las que se priorice la mejora de la eficiencia en el flujo de valor aportado a los usuarios frente a la eficiencia en el uso de los recursos empleados para ejecutar ese flujo de valor.

Como digo, no son dos partes explícitas y claramente diferenciadas, pues hasta el capítulo 8 no se terminan de explicar todos los conceptos necesarios para entender Lean en el contexto de las estrategias operativas. Sin embargo, en el capítulo 5 ya explican los principios fundamentales del Toyota Production System (TPS), que es el origen de Lean en la producción de bienes manufacturados (como los automóviles).

Por tanto, “This is Lean” no tiene, al menos directamente, nada que ver con Lean Startup aunque mucha gente lo pueda confundir. Esto no quiere decir que lo que aprendamos en este libro no se pueda llevar al mundo del desarrollo del software. De hecho, como veremos, se puede aplicar a cualquier negocio. Esto lo dejaré claro en el artículo que continuará a éste. De momento voy a centrar este artículo en la primera parte del libro.

La paradoja de la eficiencia (TL;DR)

En resumen, la paradoja de la eficiencia consiste en que si ponemos un foco desmedido en utilizar nuestros recursos de la manera más eficiente posible, esto tiende a incrementar la cantidad de trabajo a hacer.

En este escenario, intentando ser más eficientes en el uso de los recursos (tiempo, dinero, medios de producción, personas), podremos provocar diferentes fuentes de ineficiencia como:

  • tiempos más largos para acabar una tarea porque nos surgen nuevas necesidades mientras tratamos de resolver la primera, en una a veces incontenible reacción en cadena. Un ejemplo puede ser tener que reagendar una reunión porque nos hemos bloqueado en algún asunto.
  • muchas cosas que hacer o gestionar simultaneamente, con la consiguiente falta de foco, imposibilidad de tener una visión general compartida, problemas que permanecen inadvertidamente ocultos, trabajo innecesario, etc.
  • muchos reinicios del trabajo, como el típico cambio de contexto cuando hacemos multitarea o las reuniones para explicar a otros lo que hemos hecho y que ellos puedan continuar, con los consiguientes defectos y falta de compromiso con los resultados.

Todo esto es un círculo vicioso y la conclusión es que, paradójicamente, cuando NO nos centramos en utilizar los recursos al máximo, entonces somos capaces de liberar recursos.

Si prefieres ahorrarte la lectura, Niklas Modig, hace un fenomenal resumen de esta parte del libro en este video (en inglés).

¿Qué puedo aportar yo que no se explique ni en el libro ni en el video? Pues voy a compartir cómo trabajo yo la mejora de eficiencia en una transformación organizacional.

Diferencia entre eficacia, eficiencia y efectividad

Antes que nada, creo que debemos empezar por distinguir algunos términos que confundimos frecuentemente: eficacia, eficiencia y efectividad. De hecho, buscar en el Diccionario de la RAE no ayuda demasiado. Después de mucho buscar, me quedo con estas definiciones en el blog de @jmbolivar, basadas en el trabajo de Peter Drucker.

Eficacia es hacer las cosas correctas (“the right things”).

Eficiencia es hacer bien las cosas (“the things right”).

Efectividad es hacer bien las cosas correctas (“the right things right”).

Por tanto, cuando hablamos de eficiencia estamos hablando de cómo hacemos las cosas, y no necesariamente de si estamos usando muchos o pocos recursos para lograr nuestros objetivos. Ésa sería una definición sesgada del concepto de eficiencia. De ahí que diferenciar entre “resource efficiency” y “flow efficiency” es de gran ayuda para romper ese sesgo. Hablaré de esto más adelante, cuando hable de estrategias de transformación organizacional.

Eficiencia, recursos y flujo de valor

Imagino que ya has leído algo del libro o al menos has visto el video anterior. El capítulo 3 del libro es realmente interesante para ver qué entendemos por flujo de valor, y es clave para comprender los fundamentos detrás de esa paradoja de la eficiencia. Sin embargo, necesito recopilar brevemente algunas definiciones para asegurarme de que me sigues.

Eficiencia en el uso de recursos (“resource efficiency”) es la proporción de actividades de valor añadido que se realizan en un proceso, en una unidad de tiempo dada. Un proceso donde los recursos están siendo utilizados todo el tiempo, se dice que tiene una eficiencia en el uso de recursos del 100%.

Eficiencia en el flujo de valor (“flow efficiency”) es la proporción de actividades de valor añadido que está recibiendo el usuario de un proceso, en una unidad de tiempo dada. Un proceso donde el usuario está siendo atendido (y recibiendo valor en esa atención, claro) todo el tiempo, se dice que tiene una eficiencia de flujo de valor del 100%.

Valor es todo aquello que hacemos para resolver una necesidad de un usuario. Desperdicio es todo aquello que hacemos pero que no aporta valor al usuario. Para ser eficiente en nuestro flujo de valor debemos eliminar el desperdicio presente en el mismo. Muy resumido, en eso consisten las metodologías Lean de producción ajustada. (Lean, en inglés, significa “magro”, “enjuto”, “sin grasa”)

Relación entre holgura y eficiencia

Cuando mantenemos un sistema cualquiera al máximo de su capacidad para trabajar, lo estamos llevando al límite del 100% de eficiencia del uso de los recursos. Pero esto no es bueno: incluso las máquinas necesitan descansar.

Ya escribí en su momento sobre la holgura y te recomiendo que lo releas porque hay buenos consejos y argumentos para defender la importancia de la holgura en nuestros procesos.

Desde un punto de vista de la eficiencia, la holgura es el resultado de mejorar nuestra eficiencia en el uso de recursos y dedicarla a… nada. Bueno, en realidad, la dedicamos a mejorar la eficiencia en el flujo de valor. ¿Cómo? Pues por ejemplo, dedicando ese “tiempo extra” a mejorar nuestros procesos, identificando cuellos de botella, eliminando partes del proceso innecesarias, etc. Aunque a veces, el mero hecho de estar disponible para atender una petición es suficiente para mejorar la eficiencia del flujo de valor.

Experiencia práctica usando Kanban y la eficiencia de flujo de valor

Me he llevado casi dos años ayudando a muchos equipos en eDreams ODIGEO a medir la eficiencia del flujo de valor de su proceso de desarrollo. Bueno, de una pequeña parte del mismo. ¿Cómo lo hacíamos? Pues de entrada ayudando a que modelaran su proceso de desarrollo y aplicaran el método Kanban para gestionar su flujo de valor. La primera mejora en la eficiencia casi siempre ha sido imperceptible porque los equipos inicialmente no tenían un proceso estandarizado de trabajo y eso impedía la comparación. Cualitativamente al menos sí se percibía una mejora en ambas eficiencias. La sensación de ir a salto de mata es un indicador claro de ineficiencia en el uso de recursos.

Además, definimos una métrica (calculada con algunos automatismos desarrollados en JIRA) y que llamamos Local Flow Efficiency. Por ejemplo, un equipo había definido un flujo de trabajo (“workflow”) para sus historias de usuario. Con un convenio de nombres distinguíamos los estados “activos” (en los que el equipo estaba trabajando en ir dejando cada vez más acabada la funcionalidad) y los estados “inactivos” (por ejemplo, cuando estaba en una cola, esperando a que alguien tirara de él, o cuando estaba bloqueado por algún impedimento). La relación entre el tiempo dedicado al trabajo efectivo (suma del “issue” en estados activos) frente al Lead Time (el tiempo total necesario para desarrollar la funcionalidad) es esa Flow Efficiency.

Claro, no puedes atender sólo a esta métrica, porque ya sabes que al final obtienes lo que mides, sino que debemos complementarla con algunas métricas más e incluso con vistas diferentes de las mismas, por ejemplo, agregadas por categorías, etc. Y por supuesto un proceso de revisión constante, en forma de reuniones periódicas en las que el equipo al completo buscaba maneras de mejorar sus acuerdos de trabajo a partir de lo que se observaba en esas métricas. Puedes leer más sobre cómo planificar el trabajo en una de mis recientes entradas dedicadas a las conversaciones en el desarrollo de software o esta otra de la misma serie centrada en los procesos de feedback.

Los mayores impedimentos que he encontrado para medir correctamente la “flow efficiency” han sido:

  • la disciplina a la hora de mover los tickets, que va directamente ligada con el proceso de aprendizaje y empoderamiento de los equipos sobre sus procesos, y
  • el cambio de grano en la definición de los tickets cuando pasan de ser una “épica” a una simple “historia”, pues resulta difícil decidir cuándo estamos trabajando en el refinamiento de una historia en particular.

El primer impedimento se resuelve con formación para que todos entiendan los conceptos a manejar y los beneficios que trae el cambio en la manera de trabajar. Un buen consejo es usar algún ejercicio como el Penny Game (u otro parecido). Oír el tictac de las monedas cuando el flujo es constante es una sensación, que bien facilitada y conectada con esa sensación placentera de fluidez, hace que la gente no la olvide nunca.

Además, también es necesario un acompañamiento en los primeros pasos para asegurar que todos entienden cómo se interpretan las métricas.

A mí me gusta darle un enfoque muy participativo y empoderar a todos desde el primer momento. En este sentido, el “empieza con lo que hagas ahora” de Kanban es muy útil, pero a veces simplemente no hay nada. Sin embargo, trato de adoptar una posición lo menos prescriptiva posible porque al fin y al cabo los responsables de los resultados (para bien y para mal) son ellos. Eso sí, es fácil oirme decir “si habéis decidido hacer Kanban, al menos hacedlo bien”. En ese sentido pongo mucho énfasis en los acuerdos de trabajo (“hacer los acuerdos explícitos”), en que los tickets sólo avanzan o se bloquean en el flujo y nunca van hacia atrás (porque hacemos “pull” en vez de “push”) y en que la mejora continua es vital para el éxito del proceso de aprendizaje.

Como resultado inevitable de este proceso llegamos a un punto en el que todos juntos vemos la importancia crucial de que los datos que nosotros mismos producimos y consumimos sean fiables, pues si no representan fielmente lo que hacemos entonces no nos son útiles para la mejora de nuestro propio trabajo.

El segundo impedimento se resuelve aplicando Kanban a varios niveles. Es lo que @KlausLeopold denomina “Flight Levels” en su reciente libro “Practical Kanban” (muy recomendable, por cierto). Así, si empezamos aplicando el método Kanban al portfolio de épicas o proyectos, es decir, visualizando, limitando el trabajo en curso, etc, tendremos un efecto sistémico beneficioso sobre la variabilidad que afecta al trabajo en niveles más operativos. Así, si a nivel de portfolio identificamos épicas que son cada vez menos dependientes entre ellas, los refinamientos cada vez serán más fáciles y rápidos. La mejora en la eficiencia de esos refinamientos no se puede medir a nivel operativo (a nivel de historias) sino a nivel de portfolio.

¿Por qué Scrum mejora la eficiencia de flujo de valor?

Pero no sólo podemos conseguir mejorar la eficiencia de flujo usando Kanban. También lo podemos hacer cuando aplicamos Scrum. Porque Scrum establece una serie de reglas muy sencillas que ayudan a reducir la variabilidad de la demanda en el proceso de desarrollo.

El timebox de cada sprint y la planificación del trabajo que hacemos en la Sprint Planning Meeting sirven para limitar el trabajo en curso, lo que redunda en menos desperdicio por reinicios, falta de foco, etc.

Además, también estamos reduciendo los tiempos de entrega porque las tareas que planificamos tienen criterios de aceptación claros y compartidos por todos, con lo que hay menos retrabajo debido a malentendidos.

Y finalmente, el enfoque de equipo multidisciplinar ayuda a reducir los tiempos de entrega porque no se producen largos bloqueos o tiempos de espera mientras las dudas o tareas son resueltas fuera del equipo.

La paradoja de la eficiencia y las estrategias de transformación organizacional

Cuando más arriba definía la eficiencia, hablaba de un sesgo que yo diría que está anclado en nuestros cerebros desde hace mucho. Al menos, desde que Taylor definiera sus 4 principios del management allá por principios del s.XX,. Ya ahí se hace la distinción clara entre los que piensan los procesos y los que los implementan. Sin embargo, en mi opinión, que los managers deciden qué se hace y que los trabajadores lo hacen no es simplemente un sesgo sino una cuestión ideológica y, por tanto, cultural.

En mi opinión, este asunto es clave en cualquier transformación organizacional y debe ser abordado lo antes posible, dependiendo del apoyo institucional del que se disponga. Esta mentalidad produce una organización jerárquica (“yo decido por ti lo que debes hacer”) y miedosa (“yo trabajo para no perder mi posición en el mecanismo” o “yo trabajo sólo en aquello que me piden porque sólo soy una pieza de un mecanismo”). Por tanto, es una organización poco eficiente.

La mejora en la eficiencia se consigue fomentando un entorno de colaboración y dándole más importancia al valor que aportamos a nuestros usuarios en cada interacción que tienen con nosotros.

En cualquier caso, una estrategia de negocio que prioriza la eficiencia de recursos frente a la de flujo está priorizando los costes frente a la diferenciación. En la matriz de eficiencia que explican en el capítulo 8, este escenario es el de una “isla de eficiencia”: hemos hecho todo lo posible por mejorar la eficiencia de recursos y tenemos una eficiencia de flujo baja (al menos en comparación con lo que podría ser). Esto no es necesariamente malo. Eso sí, desde mi punto de vista, lo correcto es que sea una visión compartida por todos, pues de lo contrario estaremos perdiendo oportunidades de movernos hacia escenarios más eficientes.

Por tanto, la mejor estrategia de transformación organizacional deberá tener en cuenta, imprescindiblemente, la estrategia de negocio, pues ambas se retroalimentan.

La tesis del libro es que la estrategia de negocio debe tener en cuenta la estrategia operativa y viceversa. Yo añado que, si tenemos una estrategia de transformación organizacional, debemos alinearla también con estas otras dos. Esto no es necesariamente fácil, pero no hacerlo provoca frustraciones en el medio plazo pues nos encontraremos con partes de la organización tratando de mejorar la eficiencia de flujo de valor (porque están siguiendo la estrategia operativa que prioriza el flujo de valor) y encontrándose con obstáculos organizacionales (porque están siguiendo una estrategia diferente).

En cualquier caso, aunque sea una suboptimización, cuando un equipo (o un área dentro de una organización mayor) es capaz de entender la variabilidad de su demanda y también de su producción, de poner en práctica un proceso de mejora continua y de priorizar la mejora de la eficiencia del flujo frente a la eficiencia de recursos (es decir, “doing the things right”), entonces obtendrá la holgura necesaria para levantar la cabeza y buscar mejoras en otros procesos. Por ejemplo, podrá cambiar los criterios para seleccionar las opciones en las que trabajar (“doing the right things”), con lo que en realidad estaremos mejorando también la efectividad (“doing the right things right”), que en el fondo es por lo que nos pagan.

Mi trabajo es ser capaz de trasladar estos conceptos a todos los niveles y que cada cuál los ponga en práctica.