Principios Lean

Los principios Lean se pueden aplicar en muchos ámbitos. Todos los componentes de una empresa involucrados en el flujo de producir o añadir valor al producto o servicio que se ha creado, mejorado o mantenido se pueden beneficiar de estos principios.

En el ámbito del desarrollo de software, Lean se puede convertir en una guía para aquellos que quieren desarrollar un software más eficiente y de alta calidad.

Lean proporciona una guía para los equipos de desarrollo ágiles. De hecho, la metodología Scrum puede ser vista como una manifestación de los principios Lean. El entendimiento Lean puede ayudar en la implementación de Scrum pero también se puede aplicar en toda la empresa, ayudando así a aplicar Scrum en toda la organización.

1.- Respetar a las personas

En desarrollo de software, respetar a la gente incluye la noción de que el equipo que hace el trabajo es el responsable del proceso que sigue. El proceso se convierte así en la aplicación de sus ideas de cómo desarrollar buen software. Cuando hay cambios, el proceso cambia. Por lo tanto, el proceso es la base por la que el equipo que construye software lo hace de la mejor manera que sabe, dentro de las limitaciones que se dan. Respetar al equipo es respetar su proceso.

2.- Eliminar residuos

La eliminación de residuos, desperdicios, basura o en inglés “waste”, es la pauta principal para el practicante de Lean.

• Residuos es código más complejo de lo que debería.

• Residuos se producen cuando se crean defectos.

• Residuos es esfuerzo necesario para crear un producto sin valor añadido.

Donde quiera que haya residuos, el practicante de Lean analizará el sistema para ver cómo eliminarlos, ya que es probable que un error en el sistema vuelva a repetirse tarde o temprano.

3.- Aplazar el compromiso

Aplazar el compromiso significa tomar decisiones en el momento adecuado, en el último momento en que se pueda responder. No se deben tomar decisiones demasiado pronto, cuando no se tiene toda la información que se necesita, ni demasiado tarde, cuando puede suponer un gasto extra.

Este principio se puede utilizar para guiar el proceso de toma de requisitos, el análisis y el diseño e implementación.

Un enfoque alternativo es el llamado “diseño emergente”, que consiste en:

• Utilizar los bien conocidos patrones de diseño para crear arquitecturas de aplicación resistentes y flexibles.

• Limitar la aplicación de patrones de diseño a aquellas características que estén completamente definidas.

• Escribir test de aceptación y tests unitarios antes de escribir el código.

Estas características del diseño emergente permiten aplazar el compromiso de una implementación en particular hasta que se entienda lo que realmente se necesita hacer.

4.- Crear conocimiento

El software tiene un valor inherente escaso: su valor viene de que permite y optimiza la entrega de productos y servicios. Es más útil pensar en el desarrollo de software como parte del proceso productivo.

El desarrollo de cualquier producto tiene tres pasos:

1. Descubrir lo que el cliente necesita

2. Encontrar la manera de fabricarlo

3. Fabricar

Crear conocimiento significa comprender el proceso, documentar lo necesario, compartir arquitectura, y sobre todo escribir pruebas unitarias con nombres claros que traduzcan directamente el requerimiento que cumplen.

5.- Entregar rápido y con frecuencia

Otra razón para hacer el desarrollo iterativo es entregar al cliente de manera rápida y continuada, permitiendo una pronta inmersión en el mercado, mayor credibilidad, lealtad, y retroalimentación útil.

Este principio busca eliminar los retrasos, que son residuos costosos. Pero debe hacerse de forma sostenible.

6.- Producir con calidad

La calidad ha de estar estructurada. El sistema debe basarse en la calidad a todos los niveles:

• En el proceso

• En el código

• En las pruebas antes de programar

Sin pruebas automatizadas, los errores se repiten, el código es difícil de mantener, y el equipo pierde tiempo resolviendo bugs.

7.- Optimizar el conjunto

Hay que concentrarse en todo el proceso en su conjunto, desde el principio (concepto) hasta el final (consumo).

Optimizar cada paso individual puede generar grandes “inventarios” (tareas a medio hacer) que ocultan errores, malentendidos, bugs, errores de integración…

Cuanto mayor sea el inventario o más partes haya, más probable es que haya errores no detectados. Residuos. Gastos.

¿Por qué no muchas “equipos ágiles” obtienen los resultados esperados?

• ¿Por su falta de experiencia?

• ¿Por falta de atención durante el aprendizaje?

• ¿Se olvida la gestión del cambio?

• ¿No están siguiendo el libro?

• ¿Es porque no han contratado a un tutor o un profesor con experiencia?

• ¿Tal vez se olvidaron de las buenas prácticas y los patrones de diseño?

• ¿Es porque no se ha dominado la complejidad o el pensamiento sistémico?

• ¿Será que no se centran en la mejora continua?

Es posible que se deba a uno o varios de estos motivos, pero muchos casos que he visto están relacionados con el diseño de la organización, con burocracia interna y con falta de comunicación interdepartamental.

Los equipos ágiles se centran en la entrega de valor a intervalos regulares. Cada dos o tres semanas trabajan en una lista de oportunidades de negocio expresadas en las historias de usuario o tareas y juntos trabajan a toda velocidad para analizar, desarrollar, probar y liberar todo el conjunto.

Su enfoque es fuerte y simple, y sus resultados suelen ser bastante buenos. Sin embargo, dependen de personas fuera del equipo: gerentes, administrativos, ingenieros de sistemas, comerciales… Todos ellos forman parte de diferentes departamentos que, aunque pertenecen a la misma empresa, tienen otro enfoque y otra visión.

• Las historias de usuario no se acaban dentro de la iteración, porque el product owner no ha tenido tiempo para validarlas.

• La siguiente versión del software no sobrevivirá mucho tiempo porque el servicio de soporte técnico no tuvo tiempo para formarse.

• Operaciones ha decidido aplazar la implantación de un nuevo desarrollo interno por un grave problema de almacenamiento.

¿Cómo podemos aprovechar los beneficios si el resto de la organización hace lo contrario?

Las empresas deberían empezar a plantearse el coaching ágil a todos los niveles. Se ha visto que la formación en metodologías ágiles ha dado muy buenos resultados en equipos de desarrollo, pero va siendo hora de extender este tipo de pensamiento a toda la organización.

Yo ya me considero “evangelista” de estas metodologías. Me encanta hablar de eficiencia, y he conseguido que varias personas de distintos departamentos —amigos míos, incluso de otras empresas— se quedaran encantados con este enfoque organizativo.

Si crees que sería interesante impartir un curso de formación enfocado a la eficiencia en tu empresa, no sólo en departamentos de desarrollo, tan sólo tienes que ponerte en contacto conmigo y lo adapto a tus necesidades y las de tu empresa.

---

NOTA:

🕰 Este artículo fue escrito originalmente en 2012, ha sido recuperado y remaquetado en Julio de 2025 como parte del archivo histórico de mi blog.
⚠ Algunos enfoques sobre Lean han evolucionado desde entonces. Pronto publicaré una versión crítica y actualizada.