¿Cómo Hacer Contratos para Proyectos Ágiles?

Los contratos tradicionales para el desarrollo de software se enfocan en los requerimientos deseados y en el tiempo y precio requeridos para entregar dichos requerimientos. El objetivo de este tipo de contratos es crear un costo y tiempo predecible, y transferir la proveedor el riesgo en caso de que el costo sea mayor al planeado.

Este tipo de contratos generan un contexto de poca flexibilidad, ya que fomentan la evasión de cambios y ajustes. Es así que en el mejor de los casos, si el proyecto se ejecuta exitosamente de acuerdo a lo planeado, obtenemos el software que necesitábamos hace 12 meses (cuando el proyecto se planeó).

Por otro lado, en los proyectos donde se aplica la filosofía Agile, los contratos típicamente son acuerdos del tipo “tiempo y materiales”, pero con un enfoque en entregar valor de forma temprana y continua. Un contrato ágil también consta de componentes para identificar cambios en el desempeño. Dichos componentes se derivan de los principios ágiles: “software funcionando es más importante que documentación”, y “la colaboración es más importante que el proceso”.

Equipos, etapas y tarifas

Los contratos en proyectos ágiles se enfocan en construir equipos, no en contratar a personas individuales. Ponte de acuerdo en la estructura del equipo (ej: líder, desarrolladores, analistas, testers, etcétera), las capacidades requeridas para cada rol y las tarifas a cobrar. Los equipos requieren tiempo para formarse; contratar personas adecuadas lleva tiempo, así que entre cliente y proveedor deben acordar cómo se va a absorber este costo.

Una vez que el equipo está formado, hay que estar consciente que le va a tomar tiempo llegar a altos niveles de productividad pero es importante que comience a entregar software y generar valor desde el primer día, aunque sea a un ritmo lento. Tal vez sea buena idea que durante esta etapa de formación y aprendizaje del equipo las tarifas cobradas sean menores y que no se tomen en cuenta para la compensación las medidas de desempeño.

Métricas, desempeño e incentivos

Una vez que un equipo se está desempeñando y ha entregado software a lo largo de varias iteraciones, ha establecido una “velocidad”. La velocidad de cada equipo es única, e incluso depende del dominio del problema (un mismo equipo puede tener velocidades distintas en distintos dominios). Por lo tanto, no es recomendable establecer un sistema de pago basado en la cantidad de software entregado en cada periodo, así como tampoco es válido comparar la velocidad de distintos equipos y considerarla como criterio para la entrega de incentivos. Lo que sí recomiendo es monitorear el cambio en velocidad de un equipo y recompensarlo o penalizarlo según sea el caso.

Dado que es el equipo el que genera valor (no un individuo), los incentivos deben otorgarse a todos los miembros del equipo. Por otro lado, cuando un equipo baja su velocidad típicamente se debe a factores externos, por lo tanto a quien se debe penalizar en caso de la reducción de velocidad de un equipo no es al equipo como tal, sino a la organización que emplea al equipo, por no haber eliminado los obstáculos que provocaron la baja de desempeño del equipo. Las penalizaciones no le son de ningún beneficio a los clientes; el costo del tiempo perdido es mucho mayor que cualquier compensación que pudiera un proveedor aceptar pagar. Así que crea penalizaciones que llamen la atención de la gente que necesita eliminar los obstáculos para los equipos.

Los principios del desarrollo ágil hacen que este tipo de contratos funcionen: medición de desempeño y retroalimentación frecuente. Las mediciones se basan en datos duros: o el software está funcionando o no, y la estimación usando abstracciones (puntos de historias de usuario) brindan una idea de la cantidad de software entregado. Esto permite que el acuerdo pueda ser evaluado de manera temprana y continua para corregir problemas desde un principio, y que ambas partes obtengan el mayor valor de la relación.