Reinvención de los contratos ágiles: inspección y adaptación.

La forma de desarrollar software de hace 15 años no encaja en el mundo digital actual. Este mensaje parece que ya ha calado en la mayoría de empresas españolas, ahora hay que ser Agile (así, con mayúsculas), ése es el camino para conseguir el éxito en el mercado digital.

Pero no basta con tenerlo claro, el camino es complicado y, entre otros obstáculos, los contratos tradicionales no ayudan. El problema ya es conocido: querer jugar a un juego con las reglas de otro.

Muchas de las tendencias y prácticas llamadas ágiles (lean, scrum, etc.) enfatizan la importancia de la inspección y adaptación, de experimentar, medir, observar y aprender. Pues bien hagamos lo mismo con los contratos, veamos cómo se pueden adaptar.

¿Qué hay más allá de los contratos cerrados y los de tiempo y materiales?

Un buen punto de partida es aprender de la experiencia, de la propia y de la ajena. Para ello hemos recopilado las principales iniciativas que ha habido en cuanto a contratos ágiles, algunas de ellas, promovidas por grandes figuras del agilismo y el desarrollo de software.

Sprints de confianza

Consiste en ofrecer un número determinado de sprints para generar confianza y establecer una base sólida de relación con el cliente. De esta manera se pretende eliminar incertidumbre y minimizar riesgos para que el cliente cuente con la confianza necesaria para no recurrir a un contrato cerrado.

No hay nada como empezar a trabajar juntos para poder hacer mejores planes basados en la realidad y no en la percepción.

Not-to-exceed with fixed-fee (NTE/FF)

Uno de los principales impedimentos que plantean los clientes ante modelos de relación abiertos son los límites presupuestarios. Esta medida trata de establecer un mínimo (fixed-fee) y un máximo (not-to-exceed) para proteger tanto al proveedor como al cliente.

Sin embargo, esta aproximación presupone un alcance estable y predefinido, lo que se ajusta poco al principio de adaptabilidad.

Target cost

Este modelo incentiva la entrega de software funcional de forma iterativa. Para poder aplicarlo se debe acordar qué es un punto de historia, ya que estos llevarán asociado un coste. Otra aproximación sería asociar coste por ítem del backlog (si son de tamaños comparables).

El cliente pagará por los puntos entregados en cada sprint de forma iterativa. Las ventajas de este modelo son, por un lado, que no limita el alcance y deja margen para la adaptación al cambio y, por otro, que el riesgo está más repartido entre cliente y proveedor.

El problema es que implica consenso en las estimaciones, esto puede llevar a guerras internas si, nuevamente, no hay confianza y se teme por una actitud oportunista del otro.

Bob Martin’s idea

Uno de los firmantes del Agile Manifesto propone, entre otros, un modelo de contrato por tiempo y materiales combinando el precio por hora y el precio por punto de historia.

Hace falta tener una estimación global aproximada a partir de un backlog inicial. De ahí se obtiene un presupuesto total en base al precio por hora que se tenga establecido (por ejemplo: 5 sprints de 2 semanas, 4 personas, 50€/h = 80k€).

Hasta aquí todo nos suena, la idea ahora es reducir la tarifa referente al tiempo y cubrir el resto del presupuesto con la tarifa por puntos de historia.

• Se acuerda una tarifa horaria media bastante inferior a la tarifa inicial o de mercado (por ejemplo 15€/h en lugar de 50€/h).
• Se acuerda una tarifa por punto de historia para cubrir el presupuesto total (80000–15x1600)/1000 = 56€/punto de historia).

De esta forma, por un lado se mitiga el riesgo del cliente de desviación por sobrecostes: si se entregan finalmente 1000 puntos de historia, pero tardando por ejemplo 14 semanas en lugar de 10, el proyecto costaría 89.600€ (=15x160x14+56x1000). Comparándolo con un contrato por tiempo y materiales, que habría costado 112.000€ (=50x160x14), vemos que el sobrecoste se ha reducido desde un 40% a un 12%.

Por otro lado se mitiga el riesgo que asume el proveedor frente a cambios de alcance y aumenta la motivación por terminar antes, ya que si finalmente termina 1000 puntos de historia en 8 semanas, en lugar de 10, el proyecto costaría 70.400€ (=15x160x8+56x1000), con lo que su tarifa media sube de 50€/h hasta 55€/h (un 10% más).

IDIQ (Indefinite Delivery, Indefinite Quantity)

Como no se puede determinar con exactitud qué se va a entregar ni la cantidad (velocidad a la que se va a entregar), se establece una estimación a muy alto nivel de demanda y plazos.

Realmente es parecido al método NTE/FF, en el que se define un máximo y un mínimo, pero con otro enfoque. Por ejemplo: queremos AL MENOS 1000 puntos de funcionalidad y entregas entre 4 semanas y 6 meses.

Jonathan House’s idea

Prácticamente, su idea se basa en añadir bonus por entrega a tiempo y penalizaciones por retrasos. Tiene el inconveniente de que las estimaciones de tiempo se hacen, la mayoría de las veces, en una fase muy inicial donde la incertidumbre es muy alta.

Por otro lado, volvemos al problema de gestión de cambios de alcance, para que no haya retrasos y no haya penalizaciones.

Venture-capital financing model

Imita el comportamiento de una start-up. El sponsor consigue una cantidad de dinero para llegar a unos objetivos y el proveedor debe entregar resultados para conseguir más financiación.

Después de cada periodo de trabajo (entre financiación y financiación) se pueden revisar los términos del contrato y el resultado de cada periodo es algo acordado entre ambas partes.

Se ajusta bien al desarrollo con frameworks ágiles, ya que se basa en en la entrega de software funcionando de forma iterativa e incremental, permitiendo la inspección y adaptación.

Cláusulas de Jeff Sutherland

Uno de los padres de Scrum, Jeff Sutherland, propone añadir dos cláusulas a los contratos cerrados. Dichas cláusulas sólo son aplicables bajo ciertas condiciones, principalmente que todos los participantes estén cumpliendo con sus responsabilidades dentro del framework utilizado y estén implicados.

Money for nothing:

El cliente puede rescindir el contrato al final de cualquier sprint. La medida estándar para que el cliente haga esto, es cuando se percibe que el coste de seguir desarrollando es mayor que el valor que va a aportar.

En este caso, el cliente pagará el 20% del valor restante acordado en el contrato. El proveedor, por su parte, se compromete a entregar el 80% del alcance del proyecto como de alta calidad en la fecha de entrega acordada. La alta calidad se define mediante el DoD (Definition of Done).

Change for free:

El cliente puede cambiar el alcance sin que suponga un coste adicional. Las nuevas historias o ítems sustituirán a otros que estuvieran contemplados en el alcance y que fueran comparables en cuanto a esfuerzo.

Estas cláusulas pueden dar lugar a conflictos y guerras internas respecto a qué es calidad, cuánto es el 80% o qué/quién considera que dos ítems son comparables en esfuerzo, por lo que cuidado con estas gestiones que desvían nuestros esfuerzos de entregar valor.

Lo más interesante e innovador de la propuesta de Jeff es incluir, de alguna manera en el modelo de colaboración, la importancia de que estamos trabajando bien y cumpliendo cada uno con nuestras funciones.

Y esto puede deberse, en parte, a que confía plenamente en que si esas condiciones se dan, la implicación de ambas partes va a favorecer un ambiente de colaboración, confianza y transparencia, evitando llegar a este tipo de conflictos.

Norwegian PS 2000 Agile Standard contract

Hay países en los que se están tomando muy en serio el reto de formular nuevos modelos de relación entre clientes y proveedores de software.

En Noruega ya han tratado la problemática de la falta de adaptación de los contratos tradicionales a los nuevos métodos de desarrollo de productos digitales.

La Norwegian University of Science and Technology (NTNU), las industrias líderes en el sector y la administración pública han desarrollado conjuntamente un estándar de contrato agile.

Se basa en el modelo de desarrollo iterativo, una estrecha cooperación entre el cliente y el proveedor y procedimientos para la resolución de conflictos con un mediador experto.

Consta de 3 partes:

• Sobre el cliente y el proveedor.
• Provisiones generales: derechos y obligaciones de cada parte sobre la entrega de software.
• Anexos específicos sobre agile (versión 3.1)

“Las reglas universales no existen”, Dave Thomas

Es indiscutible que con confianza y colaboración es mucho más fácil (y menos necesario) definir el modelo de relación con un cliente.

Jeff Patton, del que lo aprendimos todo sobre los mapas de historias de usuarios, incluso llega a proponer dejar el contrato cerrado pero trabajar mucho la colaboración con el cliente día a día, para garantizar la satisfacción:

“When we arrived at the due date, features were left unfinished. Strangely no one wanted to talk much about those features. The customer was happy with the product and considered our contractual obligations met. We’d met the schedule and let scope slip.” Jeff Patton, “Unfixing the fixed price contract” en Agile Development Conference 2003

Exploremos, por tanto, medidas que fomenten estos valores y no que los dinamiten. Por ejemplo, pasar de contratos rígidos a marcos de trabajo colaborativos.

Si nos aseguramos de que todas las funciones necesarias van a estar cubiertas y garantizamos la implicación de todas las partes, no vamos a necesitar poner el foco en “de quién será la culpa” y que consecuencias habrá si algo no sale bien.

También debemos garantizar la transparencia absoluta. No podemos exigir confianza a los clientes, si luego no somos transparentes con nuestro trabajo. Por suerte, hay muchos mecanismos para fomentar la transparencia, las herramientas visuales y las métricas son algunas de nuestras preferidas.

El secreto de la alianza

Sintiéndolo mucho, no vamos a revelar la fórmula mágica que soluciona todos los problemas que nos acarrean los contratos tradicionales. ¿Todavía no hemos aprendido la lección?

En el mundo digital el cambio es constante y la clave del éxito es nuestra capacidad de adaptación. Cada situación, cada producto, cada cliente, cada negocio es diferente.