Technical Debt / Deuda Técnica

Una de las cuestiones que cualquier proyecto Ágil necesita tener en cuenta es cómo solucionar el technical debt o deuda técnica.

El desarrollo en iteraciones cortas puede llevar a entregar una funcionalidad que no está "completa" desde un punto de vista de diseño/arquitectura más general. Desarrollamos una funcionalidad concreta; no tenemos tiempo de pensar cómo ésta encajaría si diseñásemos una aplicación más amplia y nos centrásemos en construir una solución escalable y robusta.

En los proyectos waterfall "tradicionales", la solución está diseñada "por completo" desde un principio. El "gran proyecto" se piensa y se diseña por adelantado y luego la fase de desarrollo consiste en implementar ese diseño al nivel acordado de calidad. Nada de deuda técnica, entonces. Pero... !Esto no es cierto! Y no es cierto porque los proyectos waterfall tienen estimaciones y plazos. Y las estimaciones y los plazos son las dos fuerzas opuestas que comprometen la calidad. Las estimaciones pueden (y serán) erróneas, pero el plazo no se puede modificar (o al menos eso es lo que piensa la dirección). Así que por lo general un proyecto waterfall se inicia con el equipo entregando software de calidad y termina con ese mismo equipo incurriendo en deuda técnica cuando se acerca la fecha límite y se dispara la presión.

De todos modos, volviendo al mundo Ágil. Sí, normalmente tenemos deuda técnica y tenemos que hacerle frente. Mi opinión es que el equipo debe tener el "poder" de decidir la cantidad de deuda técnica que quiere abordar en un sprint en particular, siempre y cuando se consulte con el product owner y esté de acuerdo en las razones eximidas por el equipo.

El equipo técnico es el que conoce mejor el riesgo de acarrear deuda técnica. Así que debe ser capaz de explicar y negociar con el product owner la inclusión de tareas para solucionarlo durante un sprint. Es un ejercicio útil, porque no sólo hace que el product owner sea más consciente de lo que realmente significa el desarrollo de software, sino que también ayuda al equipo de desarrollo a superar la tentación de tener sprints puramente técnicos. ¡Por algo tenemos el product owner!

Y no sólo eso. Cuando se sugiere cuanta deuda técnica debe incluirse en un sprint, el equipo técnico debe tener en cuenta lo siguiente:

• Naturaleza del proyecto/funcionalidad: Algunas características se desarrollan porque se cree que son una gran idea, pero una vez que se entregan a los usuarios, resulta que no son tan útiles, no son realmente utilizados, o incluso pueden llegar a desaparecer (todo el mundo conoce la regla 80/20).
  Mientras que otras características resultan ser grandes éxitos. Son éstas las que tienen que ser escalables y sólidas. Son estas las que mayor importancia tienen si hablamos de deuda técnica.
  No hay ninguna razón para tratar de abordar toda la deuda técnica, sino centrarse en lo que va a tener continuidad.
  
• Encontrar el equilibrio adecuado entre las tareas técnicas y las tareas de desarrollo de nuevas funcionalidades: Cuando se inicia un proyecto Ágil, el negocio comienza a recibir funcionalidad antes que en un proyecto waterfall tradicional. Pero... ¡Cuidado! Si después "gastamos" un montón de sprints dedicados sólo a abordar la deuda técnica y no a la entrega de características tangibles para el negocio, (por muy importante que lo "techie" sea), corremos el riesgo de desilusionar a los usuarios. Es irónico pensar que lo que hemos hecho sea "malcriar" a los usuarios, pero en cierta manera es lo que hacemos con un proyecto Ágil. ¡Y necesitamos tener usuarios satisfechos!
  

One of the issues that any Agile project needs to face is how to address technical debt.

Developing in short iterations can lead to deliver functionality that is not "complete" from an overall design point of view. We implement just this feature; we don’t have time in an iteration to build a wider solution, scalable and robust.

In traditional waterfall projects, the solution is designed "completely" as part of the great schema of things. The grand design is done upfront and then the development phase consists in implementing this design to the agreed level of quality. No technical debt, then. But this is not true! And it is not true because waterfall projects have estimations and deadlines. And estimations and deadlines are two forces that play against each other to compromise quality. The estimations can (and will) be wrong, but the deadline is normally fixed (or so management likes to think). So typically a waterfall project starts with the team delivering quality software and ends up incurring in more and more technical debt as the deadline approaches and the stakeholder/project management pressure soars.

Anyway, going back to the Agile world. Yes, we normally have technical debt and we need to address it. My view is that the team should be empowered to decide the amount of technical debt that wants to address in a particular sprint, as long as they check with the product owner and he/she agrees to the reasons behind.

The tech team is the one knowing the risk of carrying over technical debt. So they should be able to explain and negotiate with the product owner the inclusion of technical debt items in sprints. This is a useful exercise, because not only makes the product owner more aware of what really means to develop software, but also helps the tech team to overcome the temptation of having sprints only "to address technical debt". We have the product owner for a reason!

And not only that. When suggesting the amount of technical debt that should be included in a sprint, the tech team should take into account the following:

• Nature of the project/feature: Some features are developed because they are thought to be a great idea, but once they are delivered to users, it turns out they are not that helpful, they are not really used or even they can be disregarded (everybody knows the 80/20 rule).
  While other features, however, turn out to be great successes. They need to be scalable and made more robust.
  There is no point in trying to address all technical debt, but to focus on what will have continuity.
  
• Find the right balance between tech debt items and new functionality: When you start an Agile project, the business starts seeing functionality sooner than in a traditional waterfall project. But beware! If then you spend a lot of sprints just addressing tech debt and not delivering tangible features to the business, however important the "techie" stuff might be, you have the risk of disengaging users. It is hard to think that you have "spoiled" them, but basically you have. And you need happy customers!