15 Lecciones: Similitudes entre el desarrollo de software y por qué Lean fracasa [1/3]

Artículo escrito por: Jon Miller

Traducción: Ana Cruz

Al leer el artículo mensual de 'Atlantic' titulado 'The Coming Software Apocalypse' me provoco hacerme esta pregunta en un contexto diferente ¿Por qué fallan las transformaciones Lean? Esta pregunta suele ir precedida de afirmaciones como "el 95% de las transformaciones Lean fallan" y algunas prescripciones contra las fallas. Hasta ahora nadie a citado una fuente para respaldar dichos porcentajes, ni tampoco definir adecuadamente los términos "Transformación Lean" o "fallas". Dejando la semántica a un lado, es cierto que las personas batallan más de lo que deberían para poner en práctica Lean en su lugar de trabajo, lo cual termina frustrándolos.

¿Qué nos puede decir un artículo de cómo se construye un software sobre el por qué las transformaciones Lean fallan a menudo? la respuesta es ¡Mucho! ... y lo compartiré con ustedes a continuación. Este artículo será dividido en tres partes así que no se pierdan las secuencias durante las próximas semanas.

Sin más preámbulos... comencemos,

Lección #1 Es complicado

Hay mucho trabajo detrás de un sistema de gestión Lean. Dicho sistema debe operar en toda la empresa, involucrar a las personas en la innovación y resolución de problemas enfocados en el cliente, a largo plazo. Se requiere más que un boceto o poster pegado en la pared de la planta, dos pilares y un techo dibujados en un pizarrón, o lo que se pueda decir en una presentación motivacional de 54 minutos. "El problema es que estamos intentando construir un sistema que está más allá de nuestra capacidad intelectual de gestión" cita la profesora de aeronáutica y astronáutica del MIT Nancy Leveson en el artículo. Es complicado, en otras palabras. Si exageramos, simplificamos demasiado y nos sumergimos en el pensamiento Lean con mucho entusiasmo pero poca comprensión de lo que se necesita para hacer que todas las piezas juntas funcionen, estamos invitando al fracaso.

Lección #2 Planos antes de los martillos

"Los arquitectos dibujan planos detallados antes de colocar un ladrillo o clavar un clavo", dice Leslie Lamport, un científico informático ganador del premio Turing, "pero pocos programadores escriben incluso un bosquejo de lo que harán sus programas antes de comenzar a codificar". En otras palabras, el software está lleno de errores porque los programadores saltan directamente a escribir el código. La gente comienza a implementar Lean ya sea con A3, Resolución de Problemas, Ideas de Mejora de 2 segundos, Eventos Kaizen, Kata, VSM, etc., antes de tener una idea clara de lo que están construyendo. Esto resulta en una gran cantidad de re-trabajo, retroceso o "aprendizaje" si queremos verlo por el lado positivo. Ya sea por falta de voluntad o presupuesto para invertir en arquitectos, el mensaje exagerado de venta "Lean es muy simple" o la falta de acciones, el martillo sin un plano es uno de los errores más comunes de los fracasos de implementación de Lean.

Lección #3 Ver el sistema y no solo las herramientas

La gestión Lean nos ayuda a resolver problemas, pero también nos incita a que seamos conscientes del proceso de resolución de problemas y de lo que estamos haciendo bien en lugar de saltar directamente a las soluciones. Además debemos reflexionar sobre por qué las personas todavía hacen atajos mentales o caen en malos hábitos mientras resuelven problemas y qué hacer al respecto.

Del artículo...

El código hace que pierdas el bosque por los árboles: atrae tu atención hacia el trabajo de piezas individuales en lugar de enfocarte en una imagen más amplia de cómo funciona tu programa en conjunto, qué se supone que debe hacer y si realmente hace para lo que lo creaste.

Necesitamos usar herramientas para obtener resultados y aprender mientras practicamos. Pero dichas herramientas pueden desviar la atención de la estructura general de un sistema y su lógica esencial. Cuando no lo hacemos, creamos islas de excelencia que no se conectan entre si con resultados sostenibles, esto representa una falla para un verdadero practicante Lean.

Lección #4 Alcance creciente

Según el artículo, el software crece sin límites. "Debido a que se puede cambiar de manera económica, el software cambia constantemente; y porque está deslindado de cualquier cosa física: un programa que es mil veces más complejo que otro, ocupa el mismo espacio real".

Incluso cuando comenzamos con algo pequeño, Lean es difícil de practicar en áreas pequeñas y contenidas porque todo está inter conectado cuando proveemos productos o servicios. Después de mejorar un proceso también se deben mejorar los procesos precedentes y subsecuentes para que las primeras ganancias sean sostenibles. El alcance debe crecer, pero pocos equipos de gestión realmente comprenden su capacidad para planificar y ejecutar proyectos complejo, que por definición se ejecutarán tarde o por encima del presupuesto. Los proyectos o iniciativas no ocupan espacio físico, salvo cosas como rotatorios de papel en la sala de trabajo. Las implementaciones fallidas Lean tienden a maximizas las listas de proyectos a expensas de la ejecución.

Lección #5 Sistemas fáciles de probar

"Cuando teníamos sistemas electromecánicos, solíamos ser capaces de probarlos exhaustivamente", dice la profesora Nancy Leveson del MIT. Podríamos pensar en todas las configuraciones posibles y candados internos que controlan los movimientos del tren, ponerlos en hojas de papel y ejecutar trenes físicos a través de estas configuraciones. Podríamos construir, probar y saber exactamente con qué estábamos lidiando. Lean es un sistema de comportamientos humanos que no son tan confiables como los sistemas electromecánicos. No podemos probar exhaustivamente cómo reaccionara la gente en cada nueva situación que encuentre. Cuando construimos un sistema de gestión Lean habrá errores. Si esperamos que las personas siempre actúen de manera racional, estamos fallando en Lean.

Continuará...