Eliminar el desperdicio (Waste)

Uno de los principios de Lean es eliminar el "Waste" (es decir, el desperdicio). Este concepto fue acuñado a finales de la década de 1940 en la industria manufacturera por Toyota. En aquella época, fabricar vehículos era muy costoso y las empresas tenían que cobrar precios muy altos a los clientes. La única forma que tenía Toyota de reducir los precios de los coches era reducir los costes de fabricación.

¿Qué significa "Waste" en Lean?

"Waste" o "desperdicio" es básicamente lo opuesto a "valor" (una capacidad que se entrega al cliente y que le proporciona un beneficio directo o indirecto). Por ejemplo, una reunión de equipo sin un motivo concreto es pura pérdida de tiempo.

Estas son las siete formas de desperdicio identificadas en el Sistema de Producción de Toyota (TPS) por Shigeo Shingo:

1. Inventarios: productos en proceso (WIP: work in progress)

2. Sobreproducción: producir más de lo que la demanda requiere

3. Procesamiento: pasos adicionales en el proceso que no son necesarios

4. Transporte: trasladar bienes de un lugar a otro

5. Tiempos de espera: intervalos entre los pasos individuales del proceso

6. Movimientos: movimientos innecesarios en el proceso

7. Defectos: errores en los productos que afectan sus características y funciones

¿Cuáles son los tipos de desperdicio en el desarrollo de software?

Basándose en los siete tipos de desperdicio de la industria manufacturera, Mary y Tom Poppendiek definieron los siete tipos de desperdicio en el desarrollo de software:

1. Trabajo en curso: En cada Sprint, los miembros del equipo son responsables de un número determinado de User Stories. Sin embargo, a veces no logran completar todas las Stories. Entonces deben averiguar por qué no pudieron hacerlo, para reducir este tipo de desperdicio.

2. Features adicionales: Al principio, el Product Owner creó una visión y luego un Product Backlog con features priorizados que generan valor para el producto. Sin embargo, el principio de Pareto establece que a menudo no es necesario desarrollar todos los features, porque muchos de ellos son inútiles.

3. Reaprendizaje: En cada Sprint se acumula cada vez más conocimiento que puede utilizarse para no reinventar la rueda constantemente.

4. Traspasos: Aquí el trabajo se pasa a otra persona una vez que la primera ha terminado con él. ¿Cómo se puede contrarrestar esto? Lo mejor es eliminar las dependencias entre las User Stories (y los features) o asignar todas las User Stories con dependencias a un solo equipo para mitigar el riesgo.

5. Retrasos: Todo aquello que retrasa la entrega o el inicio de una actividad que genera valor. ¿Cómo se puede prevenir? Hay que eliminar los cuellos de botella y rediseñar cada proceso lento para alinearlos.

6. Cambio de tareas: Esto ocurre cuando el Product Owner cambia sus prioridades y los miembros del equipo deben cambiar de una User Story a otra sin poder terminar la anterior. La razón principal suele ser que el Product Owner no tiene una visión clara del producto o que un competidor ha lanzado un nuevo producto y se quiere adaptar y lanzar el propio lo antes posible.

7. Defectos: Este es uno de los mayores problemas en el desarrollo de software. Después de cierto tiempo, se acumula una enorme cantidad de deuda técnica y, a partir de ahí, hay que invertir mucho tiempo y esfuerzo para reducirla Sprint a Sprint.

En conclusión, puedo decir que, aunque mucha gente cree que Lean no es un buen enfoque para un equipo que trabaja con Agile, se equivocan. De hecho, cada empresa debería aplicar primero Lean y luego pasar a Agile.

Este texto proviene del blog de Mario Lucero y fue traducido al español.

Product Backlog Refinement

=> Así funciona un Backlog Refinement en equipos Scrum.

¿Cómo funciona una Sprint Review en equipos ágiles?

=> Aquí descubrirás cómo puede desarrollarse una Sprint Review ideal.