Lean es otra de esas modas que aparecen al calor de la agilidad (para muchos Lean realmente es el padre de todo). Hoy en día, muchos métodos y formaciones incluyen la palabra Lean por moda, sin que realmente reflejen lo que Lean significa y lo que realmente aporta. Además, existe una tremenda confusión en el mercado entre Lean y Lean Manufacturing, lo que hace que queramos aplicar prácticas del mundo industrial que no tienen mucho sentido en el mundo del conocimiento y, en concreto, del desarrollo software. ¡Lo analizamos!
Lean Manufacturing no es Lean
Analizamos en este artículo el origen de la palabra Lean. Lean es una estrategia operativa donde anteponemos la Eficiencia de Flujo sobre la de Recursos. Es decir, nos centramos en nuestros clientes y en el valor que perciben cuando interactúan con nuestros equipos o nuestros sistemas. Esta es, quizás, la gran reflexión del libro “This is Lean”, debemos mirar a nuestro clientes y tratar de entender su experiencia de usuario: ¿Qué partes le aportan valor? ¿Cuáles son tiempos muertos o de espera? ¿Qué necesidades cubrimos?
Por otro lado, tenemos a Lean Manufacturing que es la aplicación de Lean al mundo industrial. Es decir, confundir Lean con Lean Manufacturing es confundir el qué con el por qué. Lean Manufacturing fue la manera que encontró Toyota de aplicar Lean en su sistema de fabricación de coches.
Lean Manufacturing sí que tiene principios y valores definidos, además de prácticas, como la eliminación de desperdicios o la visualización. Estas técnicas se aplican porque es la manera que encontró Toyota de mejorar su eficiencia de flujo y centrarse en sus clientes. ¡Esta es la clave!
Lean Manufacturing es peligroso en el mundo del conocimiento
El mundo del conocimiento lidera el futuro de las organizaciones. Gracias a la Transformación Digital, las organizaciones han visto en el software y la digitalización nuevas oportunidades de hacer negocio, de crecer o de sobrevivir. Por tanto, en el contexto del desarrollo software, necesitamos entregar el máximo valor posible.
Extrapolar las prácticas que funcionan en un mundo industrial al mundo del conocimiento puede ser un grave error. Por ejemplo, la variabilidad en el mundo industrial se controla, aunque son negativas muchas variaciones. Sin embargo, en el desarrollo del software, la variabilidad es lo que nos da de comer, ya que la variabilidad nos permite personalizar los productos y servicios que construímos. Actualmente, no existe una “fábrica de webs”, sino que las construímos muy personalizadas y en base a las necesidades que queremos solventar. Lo más cercano a este tipo de “fábricas” podría ser WordPress pero siempre se quedan muy limitadas.
Otro de los conceptos clave es “Kaizen” que consiste en eliminar desperdicios y estandarizar. Esto tiene sentido en un proceso industrial secuencial. En software, aunque existe un ciclo de vida, realmente desarrollamos de muchas maneras diferentes y la estandarización es uno de los grandes problemas, porque nos impide centrarnos en la entrega de valor (lo importante no es el proceso sino el resultado).
El concepto Just-in-time es clave en el modelo Toyota Production System, pero quizás no tiene mucho sentido en un desarrollo software donde la clave no es “tener el trabajo a tiempo” sino ser capaces de fluir en la entrega “end-to-end” de todo el trabajo que realizamos.
Aplicar Lean en el mundo del desarrollo software
Lean Manufacturing falla en el mundo del conocimiento porque se enfoca en un mundo diferente y menos complejo que el desarrollo software. Ahora bien, Lean nos proporciona una estrategia nítida de trabajo: enfocarse en valor, en entregar y darle al t customer lo que necesita y le aporta y, después, centrarse en los (mal llamados) recursos.
Por tanto, si un equipo Software quiere hacer Lean, tiene que reflexionar sobre varios aspectos. El primero es pensar a quién entregamos valor: tener claro a quién te diriges es clave para entender si fluyes. Después, hay que definir qué elemento genera valor: ¿es un producto software u otra cosa? Normalmente, la manera de entregar valor se consigue incrementando y mejorando un producto concreto, es decir, a medida que desarrollamos features. Por tanto, ser capaces de hacerlo fluir es clave.
Otro paso clave es medir cuánto valor entregamos por unidad de tiempo y cuánto tiempo tardamos desde que recogemos una necesidad hasta que la cubrimos (lead time). Tener estas métricas nos puede ayudar a entender sí estamos centrándonos en que el valor fluya o en que las personas estén ocupadas, ¡la clave de Lean!
Después, podemos definir nuestros valores, principios, métodos y herramientas que necesitemos para potenciar esta entrega de valor. No es que Lean no los tenga, pero no podemos copiar los métodos, principios y prácticas de un modelo muy diferente al desarrollo software, ¡tenemos que crear los que nos funcionan a nosotros!
Y tú, ¿haces Lean?
Muchas gracias por este aporte!