Time For SAFe - Episodio 2 Deuda técnica

Continuous attention to technical excellence and good design enhances Agility (Agile manifesto)

Build in Quality (Valor fundamental de SAFe)

Houston, Houston, tenemos un problema… un follón de dimensiones bíblicas, vaya.

Las implementaciones en las que la deuda técnica (aquello que hicimos sin un esquema lógico y sostenible, ese código que, a pesar de ser incomprensible e ilegible, funcionaba y dejamos estar, con duplicidades sin corregir, con daños colaterales por falta de tests, …) no se gestiona en base a riesgos y a una evaluación objetiva de impactos, no es otra cosa que pan para hoy y hambre para mañana. Porque a medida que vayamos incrementando el producto, y cuando aquella “ñapa” deje de funcionar (que lo hará…), será difícil entender dónde está el problema.

Desde ese mágico momento en adelante, se presenta un futuro agónico e inmanejable para el pseudo-tren, a menos que se encuentre una bola de cristal que descubra el origen del problema y cómo solucionarlo, o que seamos capaces de reordenar los bits del disco duro con una imposición de manos, para eliminar toda deuda técnica. Sólo en ese caso prevendríamos los impactos en los incrementos posteriores, o no necesitaríamos clonar humanos para que los miembros de los equipos fueran capaces de construir las nuevas características a las que el pseudo-tren se haya “comprometido” para poder continuar su viaje.

Sin embargo, la realidad se impone. Las consecuencias van desde hundir la velocidad del pseudo-tren, a pararlo en seco y/o volver a empezar, o bien jugar a la ruleta rusa y cruzar los dedos para que la “ñapa” se pueda apañar y nada explote más adelante. Y la calidad, entonces, queda en el olvido. Como cantaban en los boleros.

“Technical debt tends to increase in SAFe organizations because the prioritization of dealing with it is raised to a management level rather than team level” (Kevin Bendeler, I don`t like SAFe, 2022)

¿Qué valor tiene un producto si su calidad es dudosa y las infraestructuras que lo soportan no son sólidas?

Recordemos que SAFe tiene 7 competencias core, siendo una de ellas Lean-Agile leadership. Es responsabilidad de los líderes crear el entorno para que cada cual pueda cumplir con su rol y ejercer su función. En los casos en los que los líderes no hayan resuelto esta necesidad, en donde se mantenga, por ejemplo, una preponderancia tradicional de negocio sobre tecnología, o donde existan presiones para incrementar la velocidad del tren, reduciendo la dedicación a la deuda técnica, efectivamente, puede darse el problema de que los managers interfieran en la priorización del program backlog para el siguiente PI. Antipatrón al canto, si esto sucede. Y querer tapar mucho cuerpo con una manta pequeña, te deja los pies fríos y una neumonía de caballo.

También puede suceder que falten roles en la implementación, lo que impediría que se vele por el cumplimiento de dos competencias core más, que evitan la acumulación de deuda técnica: Agile Product Delivery y Team & technical Agility. O algo peor, que se hayan anulado las responsabilidades de alguno de ellos en el tren.

Porque SAFe dispone de los mecanismos y los roles para evitar que la deuda técnica se convierta en un caballo de Troya.

Desde el pre-PI, el equipo comienza a considerar que va a entrar en cada una de las iteraciones para que puedan cumplirse los objetivos del próximo PI. Aquí incluimos cualquier acción que implique una demanda de capacidad del equipo, incluyendo formaciones, incorporaciones, enablers, … y por supuesto, deuda técnica.

Uno de los guardarraíles que aseguran que invertimos nuestro presupuesto de la manera más eficiente posible es la Capacity-Allocation, o distribución de la capacidad. Consiste en la definición, a nivel estratégico, de una política en la que se acuerda que porcentaje de dedicación de cada tren debe dedicarse a cada tipo de work item (por ejemplo: funcionalidades 70%, 20% enablers, 10% deuda técnica). Se debe pagar una pequeña parte de la deuda en cada iteración.

En los objetivos del PI, los equipos comprometen que deuda técnica van a resolver, en función de la priorización y del cost of delay. ¿Cómo hacen esto? La respuesta es mediante el WSJF (Weighted Shortest Job First). (WSJF) es un modelo de priorización por el que los equipos secuencian el trabajo (features, capabilities, épicas, …) utilizando la estimación relativa del coste de retraso (cost of delay) /el tamaño del trabajo (job size). El objetivo de esta priorización es siempre generar el máximo beneficio económico, por lo que las preguntas que debemos responder son: ¿cuánto nos cuesta no resolver la deuda técnica? ¿qué dejo de ganar?, ¿qué pierdo? Cuando el coste de retraso es alto, la priorización de esa deuda técnica es mayor, por lo que debe abordarse antes.

El System architect (Arquitecto de sistema) debe asegurarse de incluir la deuda técnica en el program backlog, en cada PI, entre otras acciones, como impulsar la mejora de la calidad de las soluciones y satisfacción del cliente, entregar mejores resultados, crear un ambiente de mejora continua e innovación, impulsar a los equipos sin interferir en sus decisiones… Tanto él como el RTE, que debe gestionar riesgos y dependencias y garantizar la calidad de las soluciones, entre otras cosas, deben estar presentes en todas las implementaciones de SAFe.

El cambio cultural debe suceder en las organizaciones que adopten SAFe. Los peligros de no hacerlo superan a los extraordinarios beneficios que aporta. Los roles, los mecanismos, las dinámicas, los eventos… todo ello pierde valor efectivo si los líderes no empoderan ni impulsan el compromiso de los equipos.

Porque los objetivos, que los equipos se marcan, persiguen construir la mejor solución para el cliente. Y el objetivo de SAFe es construir el producto correcto.

Sin Principios y valores, Agile no es Agile. Y sin sus Principios y Core competencies, SAFe no es SAFe. Ni aunque los bauticen de blanco.