Explicar el concepto de Deuda Técnica resulta complejo, pues en esencia es algo que no se ve, pero que se siente. Es algo que se huele, que se intuye, y que se sabe que está ahí, escondida, esperando hasta el preciso momento de sorprender. Y cuando esta cae sobre ti, duele, y mucho.

Si no se controla este concepto tan etéreo, con el tiempo, podrá convertirse en un verdadero problema que acarree sobrecostes no planificados a la empresa de turno y mucha ansiedad y estrés en la plantilla.

Así que vamos a verla y analizarla.

 

Los Orígenes

Para entenderla, primero hay que conocer las Leyes de Lehman o Leyes de la Evolución del Software formuladas allá por el ´74 y escritas por los señores Lehman y Belady. En esta serie de leyes empíricas se nos habla sobre la vida propia que adquiere un software desde el mismo momento en que nace y sobre cómo éste, no deja nunca de evolucionar y de cambiar constantemente.

Es interesante que las conozcáis.

Si nos apoyamos pues en estas Leyes de Lehman y las tomamos como premisas, podemos asegurar que si el entorno evoluciona y los requerimientos y funcionalidades varían constantemente, las decisiones a tomar deben ser lo más rápidas y precisas posibles, pues una mala solución implementada puede transformarse en decenas de problemas a futuro. Por lo que, para no generar más Deuda Técnica, primero, hay que pensar (y mucho), y luego, actuar.

Lehman hace también mucho hincapié en el hecho de que menospreciar la calidad del producto es un grave error que traerá consigo un futuro muy negro y oscuro. Y desgraciadamente, esto es precisamente el día a día de nuestra profesión: ante problemas clave, abandonar la calidad lo primero.

El cumplimiento de las Leyes de Lehman es inversamente proporcional a la Deuda Técnica, esto es, si las Leyes Lehman fallan (calidad, evolución, moral, autogestión, estabilidad…), la Deuda Técnica, aumenta.

He ahí la relación directa entre ambos conceptos: Deuda Técnica y Leyes de Lehman.

  

Las fechas de entrega y las prisas

Tomar decisiones sin parar es la constante de cualquier informático, y lo difícil del asunto es ver el alcance de las mismas con antelación y detectar los errores antes de que surjan tirando de intuición. Ante un problema concreto, podremos decidir qué solución tomar, pero si no somos hábiles, ésa decisión puede acarrear problemas a futuro que no habíamos previsto, por lo que tarde o temprano, nos encontraremos con las consecuencias. Y estas no serán agradables, seguro.

En el ámbito del software development es normal marcarse plazos de entrega y medir los tiempos de desarrollo casi al milímetro y afinándolos al máximo con tal de cumplirlos a rajatabla. Pero si en una de esas, los requisitos cambian, o el sistema varía, o la capa de sistemas se queda parada por incidencia o si simplemente, tu ordenador no va lo bien que debiera, dichos plazos, se verán afectados, y por lo tanto, se producirá en consecuencia un retraso en la entrega del producto.

Y qué ocurre? Pues que durante el transcurso del proyecto todo cambia constantemente, excepto una cosa, la maldita fecha de entrega. Así que nos encontramos con cambios de entorno periódicos y fechas de entrega fijas, las cuales suelen ser muy rígidas y difíciles de cambiar sino es que llegas a acuerdo con el stakeholder del producto.

El entorno puede no ser idéntico al de ayer y aunque pienses que nada ha cambiado, la verdad es más dura, y los cambios están ahí, invisibles, encima de tu cabeza. Y por tanto, cualquier fallo de apreciación, de perspectiva o de decisión, conlleva consigo una consecuencia oculta que provocará que los tiempos de entrega, se retrasen.

En mi opinión, las fechas de entrega fijas y las estimaciones al aire provocan siempre Deuda Técnica.

Además, existe un clásico en este tema, y es que al final, cuando llegue el momento, alguien pagará esa Deuda Técnica con su sangre, sudor y lágrimas. No se sabe a quién, pero al final, la explosión siempre le tocará o al proveedor de turno o al cliente pagador o el mismo Project Manager al mando o al becario que lleva el MySQL. Eso es así. Para lo que no se ve, no se tiene culpable al que culpar. Nadie sabrá nada. Todos hicieron bien su trabajo. Nadie tomará responsabilidades.

Fuere como fuere, a la postre, a alguien le caerá encima la pesada losa de los errores cometidos en el pasado durante el proceso de desarrollo. Es un hecho demostrado. Y quizás, fueron todos los que contribuyeron a aumentarla con sus pequeños actos, sin apenas haberse dado cuenta.

En definitiva, la Deuda Técnica es cosa de todos. Y con fechas fijas, el asunto, empeora.

 

Scrum y la Deuda Técnica

En un modelo Waterfall clásico corregir un fallo es mucho más complicado que en los Modelos Ágiles. Porque desde que el fallo es detectado por alguno de los eslabones de la cadena hasta que se eleva el problema a las capas de decisión superiores y se busca una solución válida para luego volverla a bajar y que ésta sea implementada, puede pasar mucho tiempo, y en consecuencia, se pierde maniobrabilidad y se provocan cuellos de botella innecesarios. Y puede que haya compañeros que quizás dependían de ti y de tu avance.

En los Modelos de Proceso como es el caso de Scrum la cosa cambia, ya que cada día, durante el Daily Scrum, el equipo puede detectar rápidamente los problemas que están escondidos y tomar decisiones rápidas y ágiles para aplicarlas y que no vayan directas a engrosar la Deuda Técnica del proyecto.

La Transparencia, la Inspección y la Adaptabilidad son los pilares fundamentales de Scrum, y estarán ahí, presente todos los días y durante todos los Sprints. Y por este motivo, Scrum facilita el control sobre la Deuda Técnica y sus consecuencias.

Aunque las fechas sean fijas, con Scrum, tendrás tiempo para adaptarte a cualquiera de los cambios que se produzcan en el entorno.

 

Scrum Master VS Deuda Técnica

Es importante que el Scrum Master entienda muy bien el concepto de Deuda Técnica y sus peligros y sepa transmitirlo a todas las capas de la empresa, no solo al Scrum Team. Si se consigue hacer entender el concepto y sus implicaciones a futuro, podremos generar un conocimiento general mucho más reforzado que permita mitigarla más adecuadamente y a tiempo, ya que si todos tienen presente en su día a día que la Deuda Técnica existe y que es algo negativo para el conjunto, se preocuparán de rebajarla al máximo posible.

Hacer uso de la Deuda Técnica es uno de los mejores argumentos que pueda tener un Scrum Master a la hora de defender sus posturas ante eventos, decisiones o situaciones que se puedan dar dentro de su entorno. Si tú le dices a tu interlocutor, que su decisión provocará un aumento en la Deuda Técnica (y es cierto), seguro que la discusión sobre el tema, acabará ahí, y no tendrá mucho más recorrido. Tu interlocutor entenderá las consecuencias negativas de su decisión muy rápidamente y te llevarás la razón. No habrá pues, mayor discusión posible.

Desde mi punto de vista, el Scrum Master debe entender y comprender a la perfección el entorno que le rodea y el ecosistema por el que se mueve. Debe saber detectar incidencias en las relaciones, malos rollos entre las personas, cuellos de botella técnicos insalvables, distracciones innecesarias, quiénes son los Ladrones del Tiempo más laureados de la oficina, quiénes son los deprimidos, los happies, los que van de rebeldes, los vagos, los talentosos, los que van de guays, los tímidos, etc…En definitiva, el Scrum Master debe ser capaz de usar su inteligencia emocional para detectar y analizar todo lo que ocurra a su alrededor y evitar que cualquier situación degenere en un aumento en la famosa Deuda Técnica.

Scrum Master, tienes que ser capaz de ver lo invisible. Y cuanto más nítida sea tu visión, mejor Scrum Master serás. Así que combate la Deuda Técnica con toda tu inteligencia y haz que el resto interiorice el concepto y sus fatales consecuencias. Has de lograr que siempre la tengan en cuenta.

 

En Solving Ad Hoc te ofrecemos una experiencia a medida de tus necesidades reales de cambio y adaptación, con la Agilidad como compañera de viaje en tu Transformación Digital: