La calidad era el punto del coaching ágil

8 min de lectura

Antes de convertirse en gestión de ceremonias

Qué es realmente la calidad

Una interfaz bonita no es calidad. Una demo exitosa no es calidad. Pasar QA el jueves y derrumbarse en producción el lunes no es calidad.

La calidad en software significa que el sistema hace lo que tiene que hacer, que lo sigue haciendo cuando la realidad se pone fea, y que todavía puede cambiarse sin convertir cada mejora en cirugía.

Eso incluye al menos cinco cosas:

• El software se comporta correctamente para usuarios y para el negocio.
• Falla de maneras comprensibles en lugar de corromper datos en silencio.
• Puede cambiarse sin detonar tres explosiones ajenas.
• Los equipos pueden decir si está sano porque el feedback llega rápido y de forma real.
• La gente que lo construye puede sostener el trabajo sin ahogarse en miedo y retrabajo.

Ese último punto se ignora porque suena blando. No lo es. Un equipo que vive en ansiedad constante no produce calidad. Produce camuflaje. La gente esconde incertidumbre, agrupa trabajo riesgoso, evita tocar zonas frágiles y redefine “hecho” hasta que liderazgo pueda dormir.

La calidad no es solo una propiedad del producto. También es una propiedad de la forma en que se construye el producto.

Qué significaba originalmente el coaching ágil

Cuando el coaching ágil todavía tenía pulso, especialmente en la escena temprana de Estados Unidos alrededor de Extreme Programming, Scrum en su versión menos esterilizada y el movimiento Agile antes de industrializarse, el trabajo era mucho más concreto.

Se suponía que un coach ayudara a los equipos a aprender a construir software en pasos más pequeños, con feedback más rápido, mejor colaboración y disciplina técnica más fuerte. Eso significaba pairing. Pensamiento test-first. Integración continua. Refactoring. Feedback real de clientes. Trabajo cortado lo bastante pequeño como para terminarse. Conversaciones lo bastante cerca del código como para que el malentendido no acabara directamente en producción.

El centro del trabajo era la calidad.

No calidad como una compuerta al final. Calidad como algo que se construye desde el comienzo mediante feedback, diseño y práctica técnica.

Por eso el lenguaje Agile antiguo incluía la excelencia técnica. No como filosofía decorativa. Como base mecánica de la adaptabilidad. Si el código es frágil, faltan pruebas, la integración da miedo y el despliegue es un ritual, usted no es ágil. Solo está moviendo el pánico por el calendario.

Un coach útil en ese sentido anterior no se limitaba a dirigir talleres. Cambiaba cómo ocurría el trabajo. Ayudaba a los equipos a ver defectos antes, reducir tamaño de lote, hacer visible el riesgo y construir confianza mediante evidencia ejecutable.

Cómo se desvió

La versión técnica seria era más difícil de vender.

Exigía practicantes con oficio. Exigía credibilidad ante desarrolladores. Exigía acercarse a código feo, pipelines rotos, estrategia de pruebas débil y hábitos de gestión que premiaban lo equivocado. Exigía conflicto.

Así que el mercado hizo lo que hacen los mercados. Encontró la versión más barata.

De pronto se podía vender coaching ágil sin una base técnica fuerte. Ya no hacía falta saber cómo ayudar a un equipo a meter calidad dentro del código. Bastaba con facilitar, moderar, reformular, empatizar, mapear notas adhesivas e introducir palabras seguras para la incomodidad organizativa.

En Estados Unidos eso muchas veces se convirtió en consultoría metodológica disfrazada de transformación. En Europa a menudo tomó una función social todavía más rara: una especie de trabajo de calle para equipos de software. Alguien para calmar a la gente, absorber frustración, mantener la comunicación fluyendo, traducir dolor a lenguaje inocuo y hacer que el sistema se sintiera atendido sin obligarlo a cambiar.

Ese trabajo no siempre es inútil. El conflicto humano es real. El malestar de equipo es real. Pero no reemplaza la mejora de la entrega de software. Muchas veces se convierte en una manera de ayudar a la gente a sobrevivir dentro de un sistema malo en vez de confrontar por qué ese sistema sigue produciendo software de baja calidad.

Por qué el mercado prefirió la versión peor

Esta deriva no fue solo corrupción profesional. También fue psicología.

El trabajo serio de calidad amenaza a la gente.

Amenaza a ejecutivos porque revela que fechas, decisiones de financiación y estructuras de reporte pueden estar degradando el producto. Amenaza a managers porque expone lo poco que puede arreglarse de la entrega con teatro de planificación. Amenaza a desarrolladores porque la disciplina técnica real destruye el romance de la improvisación heroica. Amenaza a consultores porque la mejora medible es más difícil de fingir que la energía de facilitación.

El teatro de procesos, en cambio, es emocionalmente cómodo.

Les da a líderes una intervención visible. Les da a managers un vocabulario. Les da a equipos un ritual. Les da a consultores una oferta empaquetada. Les da a todos una historia en la que se están esforzando mucho.

Esa historia tiene un valor psicológico enorme. Reduce ansiedad sin exigir un encuentro directo con las causas reales de la mala calidad.

Necesidades, estatus y la economía rara de la calidad

Aquí viene la parte fea.

Muchos compradores no quieren realmente la disciplina necesaria para la calidad. Quieren la sensación de haber actuado con responsabilidad.

Esa es otra necesidad.

Algunos quieren estatus: “Trajimos coaches ágiles. Ahora somos modernos.” Algunos quieren absolución: “Si la entrega igual falla, al menos seguimos best practice.” Algunos quieren paz social: “Por favor reduzcan conflicto sin cambiar incentivos.” Algunos quieren esperanza barata: “¿Podemos obtener los beneficios de la excelencia técnica sin costo, tiempo ni incomodidad?”

Y el mercado responde de maravilla a esas necesidades.

Ofrece teatro de mejora a un precio y con un tono que el comprador puede tolerar. No demasiado confrontativo. No demasiado técnico. No demasiado exigente. Solo el lenguaje suficiente sobre mindset, colaboración y madurez para sonar serio.

Siempre habrá alguien dispuesto a comprar promesas baratas de supuesta mejor calidad mientras la historia sea lo bastante reconfortante. Y siempre habrá alguien dispuesto a venderlas.

Eso no es exclusivo de Agile. Así se comporta la mayoría de los mercados con poca rendición de cuentas. Si el comprador no puede inspeccionar con facilidad la calidad subyacente, el empaque gana durante mucho tiempo.

El software es especialmente vulnerable porque la calidad casi siempre es invisible hasta que se rompe en público.

La división psicológica dentro de los equipos

Aquí es donde aparece el costo humano.

Los desarrolladores que se preocupan por la calidad suelen vivir el sistema como una corriente de concesiones evitables. Pueden ver las pruebas ausentes, el acoplamiento peligroso, el tamaño de lote, los riesgos silenciosos, las estimaciones falsas, el miedo al despliegue. Para ellos, la calidad es concreta.

Liderazgo suele vivir la misma situación de otra manera. Ve fechas, presupuestos, presión del consejo, restricciones de personal y la necesidad constante de mantener coherente a la organización. Para ellos, la calidad puede convertirse en una aspiración abstracta que compite con todo lo demás.

Se suponía que el coach ayudara a cerrar esa brecha con evidencia, práctica y bucles compartidos de feedback. En la versión degradada, el coach a menudo se convierte en un amortiguador que ayuda a ambos lados a tolerar la brecha sin cerrarla de verdad.

Eso es una degradación profunda.

Convierte el coaching de construcción de capacidad en absorción emocional de impactos.

Lo que todavía haría un coach enfocado en calidad

Si el rol vale algo, todavía tiene que hacer al menos estas cosas:

• Ayudar a los equipos a hacer el trabajo más pequeño para que el feedback llegue antes de que el daño se acumule.
• Fortalecer las prácticas técnicas que vuelven seguro el cambio.
• Hacer visible la calidad mediante pruebas, señales de entrega, defectos y comportamiento en producción.
• Acompañar a liderazgo para que lea evidencia en vez de ritual.
• Reducir con el tiempo la dependencia del coach en lugar de crear una casta permanente de traducción.

Por eso liderazgo tiene que hacerse cargo del camino, y por eso la metodología se vuelve peligrosa cuando reemplaza la realidad por lealtad. El trabajo nunca fue instalar más proceso. El trabajo era mejorar la capacidad del sistema para producir software de alta calidad.

El mercado seguirá comprando teatro

Esa parte no va a desaparecer.

Siempre habrá compradores que prefieran un método prolijo a un diagnóstico incómodo. Siempre habrá consultores capaces de hacer que sistemas de baja calidad suenen temporalmente sofisticados. Siempre habrá organizaciones que llamen calidad a algo porque alguien lo aprobó, lo documentó o le montó una ceremonia alrededor.

Bien. Que lo hagan.

Para quienes sí quieren calidad, la definición tiene que seguir siendo afilada.

La calidad es software que funciona bajo condiciones reales, que puede seguir cambiando y que se construye mediante feedback disciplinado en lugar de tranquilidad ceremonial.

Ese era el núcleo serio del coaching ágil antes de que el mercado lo diluyera.

Sigue siendo la única parte que vale la pena conservar.