Quinto artículo sobre calidad en Lean Software Development. En los posts anteriores hablamos de cómo construir con calidad desde los errores, el diseño técnico, la colaboración y la visibilidad. Ahora abordamos un tema clave: por qué muchas organizaciones aún no trabajan así, y qué podemos hacer para cambiarlo.
En el mundo del desarrollo de software, existe un mito persistente: que la calidad y la velocidad son fuerzas opuestas, que hay que sacrificar una para obtener la otra. Sin embargo, la realidad, como demuestran los informes DORA y la experiencia de equipos de alto rendimiento, es que la calidad es el camino más directo y sostenible hacia la mayor velocidad posible.
Existe una paradoja fundamental: cuanto más nos obsesionamos con la velocidad inmediata sacrificando calidad, más lentos nos volvemos. Los equipos que acumulan deuda técnica, bugs no resueltos, o código difícil de mantener hacen que cada nueva funcionalidad sea exponencialmente más costosa. Lo que parecía una decisión "pragmática" se convierte en un lastre que ralentiza todo el sistema.
El verdadero pragmatismo está alineado con los principios Lean: posponer decisiones hasta tener información suficiente, aplicar YAGNI (You Aren't Gonna Need It), mantener un diseño simple, e iterar constantemente para tener la versión más sencilla del sistema que cumpla con las necesidades actuales. Esto es ser realmente pragmático.
Es importante entender que en la época que vivimos, de continuo cambio y adaptación del software, cuando hablamos de "medio plazo" en realidad nos referimos a unas pocas semanas. No estamos hablando de meses o años para ver los beneficios de la calidad. Los efectos de trabajar con calidad se notan en muy poco tiempo, y ese supuesto trade-off a corto plazo solo tiene sentido para software de usar y tirar.
En el pensamiento Lean, la forma de tener más impacto es minimizar el desperdicio, siendo la falta de calidad uno de los principales desperdicios en software. Así que la combinación ganadora en desarrollo de software es maximizar el impacto, minimizando la cantidad de software generada, y haciéndolo con calidad en el proceso. El enfoque no es hacer peor o más rápido, sino ser inteligente y disciplinado para conseguir tener más impacto con menos, y con calidad. Esta es la verdadera forma de ir rápido, lograr el máximo impacto y ser un equipo de alto rendimiento sostenible.
Motivos comunes para no trabajar así (resistencias frecuentes)
Presión por velocidad a corto plazo
"No tenemos tiempo para escribir tests", "hay que entregar ya". Esta es la más clásica. Sin embargo, como ya hemos visto, los tests bien integrados en el flujo de desarrollo permiten avanzar más rápido y con menor coste a medio plazo.
En entornos donde se valora el output inmediato, invertir en calidad al inicio puede parecer más lento, pero evita una ralentización mayor incluso a corto plazo. No estamos hablando de beneficios que tardan meses en llegar —en cuestión de semanas ya se nota la diferencia cuando la deuda técnica no se acumula y el desperdicio se mantiene bajo control. Las prácticas Lean suelen malinterpretarse como un freno inicial, pero su verdadero valor se revela claramente cuando el sistema empieza a fallar y se evidencia el coste real de no haber invertido en calidad.
Desalineación entre negocio y tecnología
Si el negocio solo mide entregas visibles (features) y no entiende el valor del refactor, los tests o el diseño simple, se generan incentivos perversos que empujan a evitar todo lo que no "se vea".
Aquí es necesario alinear los incentivos, demostrando con datos que la inversión en calidad genera un mayor retorno. Además, el desperdicio de construir funcionalidades innecesarias o mal entendidas se dispara cuando falta esta alineación. Y no nos engañemos, el desperdicio fundamental en el desarrollo de producto software es implementar lo que no se necesita, y además mantenerlo durante toda la vida del producto. Ya sabemos que el coste basal no se aplica solo a las funcionalidades que se usan.
Falta de formación o experiencia
Para muchas personas, esta forma de trabajar es nueva. No han visto entornos con trunk-based development, TDD o automatización real. Si no han vivido sus beneficios, es normal que desconfíen o los subestimen. Algunas de estas prácticas requieren un cambio de mentalidad significativo y competencias técnicas específicas que necesitan tiempo para desarrollarse. La inversión en formación y mentorización es clave para superar esta barrera inicial y construir la confianza necesaria en estos métodos.
Miedo al cambio
El temor a lo desconocido es una respuesta natural humana. Muchos equipos se sienten cómodos con sus procesos actuales, incluso si son ineficientes. Cambiar rutinas establecidas genera incertidumbre y resistencia. Este miedo puede manifestarse como escepticismo ("esto no funcionará aquí") o incluso como sabotaje pasivo. La transición requiere liderazgo efectivo, comunicación clara de los beneficios esperados y creación de un entorno seguro donde experimentar con nuevos métodos sea valorado y respaldado.
Falta de calidad estructural
Algunos equipos quieren trabajar con calidad, pero ya tienen un sistema lleno de deuda, sin tests, sin confianza. Cambiar requiere una inversión que muchas veces la organización no está dispuesta a hacer. Aquí la mejora debe ser incremental, con wins visibles: reducir el tiempo de despliegue en un 10%, arreglar los 3 bugs más críticos, etc. Establecer "zonas limpias" en el código y expandirlas gradualmente puede ser una estrategia efectiva para recuperar terreno sin necesidad de una reescritura completa.
Inercia organizativa y estructuras rígidas
Si los equipos no tienen autonomía, si las decisiones se toman desde arriba sin feedback técnico, o si los procesos de release, QA o seguridad están fuera del equipo, es difícil aplicar jidoka o reaccionar rápido a problemas.
El sistema inhibe la calidad y el desperdicio de tiempo y recursos aumenta exponencialmente mientras los problemas persisten.
Cultura del castigo y la culpa
Si la organización no tolera errores, si se busca culpables en lugar de causas, o si los incidentes generan miedo en vez de aprendizaje, se oculta el error en lugar de visibilizarlo. Y sin visibilidad, no hay mejora ni se puede reducir el desperdicio.
El miedo paraliza la innovación, retrasa la identificación de problemas y oculta el desperdicio en todos los niveles.
Aunque parezca exagerado, muchas organizaciones se enfrentan a esta disyuntiva cuando ven que su forma de trabajar ya no es sostenible. Mejorar requiere esfuerzo, pero no mejorar tiene consecuencias inevitables.
Crear las condiciones para construir con calidad
Trabajar con calidad, como hemos visto a lo largo de esta serie, no depende solo de herramientas ni de talento individual. Es una consecuencia directa del entorno (sistema) que construimos. La calidad no surge de forma espontánea: necesita espacio, alineación y una cultura que la valore.
Desde Lean Software Development, partimos de una premisa: las personas quieren hacer un buen trabajo. Pero si los incentivos, los hábitos y la cultura no acompañan, incluso los equipos con las mejores intenciones caerán en prácticas que sacrifican la calidad en favor de la urgencia, el volumen o la apariencia de productividad. Y esto inevitablemente lleva a generar mucho desperdicio.
“A bad system will beat a good person every time.”
—W. Edwards Deming
Como líderes en desarrollo de productos, tenemos una responsabilidad clara: crear las condiciones adecuadas para que la calidad no solo sea posible, sino inevitable. Esto implica intervenir en tres dimensiones clave: los incentivos, los sistemas de trabajo y la cultura.
La calidad no mejora actuando solo sobre lo visible. Como bien resume Donella Meadows, existen muchos niveles desde los que intervenir en un sistema. Cuanto más profundo es el punto de intervención (mentalidad, cultura, estructura), mayor es su impacto. Este marco nos recuerda que si queremos calidad sostenible, no basta con ajustar métricas: hay que transformar cómo pensamos y cómo trabajamos.
 |
| Lugares para intervenir en un sistema según Donella Meadows |
Redefinir el éxito
En lugar de celebrar solo la cantidad de funcionalidades entregadas o la velocidad aparente, enfoquémonos en el impacto real, en la sostenibilidad del sistema y en la capacidad del equipo para adaptarse con confianza.
Calidad no es entregar más, sino poder entregar mejor: con menos riesgo, manteniendo un ritmo sostenible, aprendiendo continuamente y anticipando mejor los cambios.
Dar espacio al aprendizaje y la mejora continua
Uno de los errores más comunes es pensar que el tiempo para el Kaizen es prescindible. Pero reservar tiempo para refactorizar, automatizar, revisar procesos o simplificar no es un lujo: es parte del trabajo del equipo y una inversión en salud del sistema.
Para hacerlo posible, necesitamos introducir slack intencional: espacio planificado para observar, aprender y mejorar. Sin ese margen, todo el tiempo se dedica a entregar, y no queda energía ni foco para el Kaizen.
La mejora continua requiere tiempo, atención y un ritmo sostenible. Es lo que permite reducir el desperdicio de forma constante.
Cuidar la cultura del equipo
La seguridad psicológica es clave. Si hay miedo a equivocarse o a señalar problemas, no habrá jidoka, kaizen ni visibilidad. Solo en un entorno donde se pueda dudar, explorar y aprender sin castigo podremos detectar errores a tiempo y mejorar juntos, reduciendo el desperdicio que generan.
También debemos evitar incentivar el trabajo heroico: cuando el buen resultado depende solo del esfuerzo extraordinario de una persona, es señal de que el sistema está fallando.
En lugar de héroes, necesitamos equipos que trabajen de forma sostenible, con procesos que aseguren calidad de manera continua y predecible. El trabajo heroico suele ser un generador crónico de desperdicio.
Además, hay que dar autonomía real: decidir tecnologías, diseñar los procesos de testing, tener voz en la planificación, etc. Un equipo sin control sobre su entorno técnico, su flujo de trabajo o su forma de validar lo que construye, difícilmente podrá garantizar calidad.
La autonomía, combinada con responsabilidad compartida, es uno de los pilares más fuertes de la calidad en Lean.
Por último, hay que alinear los incentivos con la calidad. Reconocer y visibilizar el trabajo que permite que todo fluya: no solo las nuevas funcionalidades, sino también cuando se reduce deuda técnica, se mejora el proceso de testing, se evita una caída en producción o se simplifica una parte crítica del sistema.
Todo eso también es valor entregado. Y suele ser el que más perdura.
Cómo hacer que la calidad sea inevitable: liderazgo en la práctica
Hacer posible la calidad no consiste en pedir más esfuerzo a los equipos. Consiste en cambiar el sistema para que trabajar con calidad sea lo más natural, lo más sencillo y lo más rápido. A lo largo de los años, he intentado sistematizar este enfoque con decisiones muy concretas. Aquí algunas de ellas:
- Reservar espacio para el aprendizaje. Decidir activamente qué parte del tiempo se invierte en aprender. A veces es formación, otras veces simplemente es preguntar: “¿Qué habéis aprendido? ¿Qué podéis compartir?”.
- Convertir los errores en aprendizaje colectivo. Introducir blameless postmortems. Liderar los primeros, definir el proceso, normalizar que los errores no son culpa, sino oportunidades de mejora.
- Liderar con el ejemplo. Aplicar TDD, diseño evolutivo, pairing. Ser el primero en documentar y actuar sobre incidencias. No exigir lo que no se practica.
- Introducir Technical Coaching. Aprender junto a quienes ya dominan prácticas como TDD o Pair Programming. Si es posible, traer personas expertas con experiencia real.
- Cambiar los procesos de contratación. Evaluar cómo trabajan, no solo qué saben. Introducir TDD, pairing, diseño colaborativo como parte del proceso.
- Recompensar y visibilizar mejoras estructurales. Valorar explícitamente lo que mejora la calidad: reducción de deuda, mejor estrategia de tests, simplificaciones, etc.
 |
| Modelo de impacto del liderazgo transformacional según DORA / Accelerate |
Liderar para hacer la calidad inevitable
Construir con calidad no es solo una cuestión de prácticas técnicas: es, sobre todo, una cuestión de liderazgo. Nuestro papel como líderes no es exigir calidad como si fuera un extra opcional, sino entender que es la base para una velocidad sostenible, para reducir el desperdicio y para maximizar el impacto real.
La calidad no es una meta ni una opción: es el sistema operativo sobre el que se apoya todo lo demás. Si ese sistema falla, cualquier intento de avanzar rápido nos lleva directo al colapso.
Nuestro trabajo como líderes es crear las condiciones donde la calidad no dependa de la voluntad individual, sino que sea lo más fácil, lo más rápido y lo más natural. Donde construir con calidad no sea un acto heroico, sino lo inevitable.
No comments:
Post a Comment