Al igual que en Tesalea el bello Aquiles sería por decisión de Zeus el más apuesto, rápido y letal de los guerreros, la “Agilidad” se posicionaba, como si estuviera predestinada a ello, como la más rápida, fiable, eficiente  y bella forma de gestión en proyectos de TI. Y al igual que Poseidón y Zeus debatían acaloradamente sobre aquel alumbramiento, los gurús de la gestión debaten sobre las virtudes de la agilidad.

Pero, (todo tiene un pero en esta vida), la ninfa Tetis, al asir a su amadísimo Aquiles, no sumergió el tobillo de su hijo en las aguas que conducían al Averno, las de la laguna Estigia, y con ese gesto quedó marcada la leyenda. Nuestras ninfas de la agilidad, aun no siendo tan vanidosas como Tetis, también querían que la agilidad, como hija predilecta que es, fuese esa forma de gestión inmortal, rápida, poderosa y bella que perdurase en la historia. Pero en este caso las aguas de Estigia no bañaron los marcos contractuales y así, como Aquiles y su talón, al no incluir en su tratado cómo manejar la contratación de un equipo ágil nos encontramos con que el modo de contratación no es, por tanto, ágil. No se contrata capacidad, y si hablamos de grandes corporaciones, grandes sistemas o grandes equipos de trabajo con escalamiento etc. los riesgos e impacto son importantes.

Trabajamos habitualmente con modalidades de contratación obsoletas o que vienen de otros mercados, (no olvidemos que TI es una industria relativamente nueva si la comparamos con otras que vienen madurando desde hace cientos de años, como por ejemplo la arquitectura), y tomemos como un punto de partida de referencia el PMI (Project Management Institute https://www.pmi.org/) que marca la existencia de siete tipos de contratación básicos.

Tipos de contratación según PMI

Tipos de contratación según PMI

Lo habitual es utilizar T&M para outsourcing y Fixed Price (FFP) en el caso de contratación por alcance, con el juego de penalización o incentivos (más bien los primeros) o en algún caso con ajuste económico pero ninguno encaja en la filosofía de la agilidad. ¿Qué tipo de contratación deberíamos buscar en este tipo de colaboraciones?

Si repasamos los principios de la agilidad, tomando como referencia Scrum ya que es el marco más aceptado e implantado, deberíamos buscar como objetivo para definir un contrato el cuantificar el valor del producto y asociar ese contrato a ese valor. Todo en agilidad se mueve alrededor del valor, por lo que deberíamos seguir esa misma línea. Deberíamos buscar también equilibrar los riesgos y no caer en el paroxismo del riesgo total para una de las partes. ¿Por qué no buscar compartir los riesgos, evaluación continua del valor generado para dimensionar la satisfacción y facturar por capacidad del equipo?

No olvidemos que los principios básicos de la agilidad se han adaptado exitosamente en aquellos proyectos con un alto nivel de incertidumbre, es imposible recabar todos los requisitos del cliente, o en los que éstos no son estables y sufren constantes cambios. Si no tienes claros los principios de la agilidad, un buen amigo mío (Alex Menzinsky) tiene un blog interesante sobre agilidad y no puedo perder la oportunidad de proponeros visitarlo, ya sea para principios fundamentales o para ahondar más en la gestión ágil de proyectos. http://scrum.menzinsky.com. He tenido la suerte de trabajar directamente con él y aprender mucho sobre agilidad y lo importante que es un buen Scrum Master. También te animo a leer este post de Juliana Betancur sobre los principios básicos de la agilidad para su escalado, (me encantan las ilustraciones de esta bloguera)

Habiendo hecho el “reloading” del mindset mental de los principios ágiles, continuemos hacia la idea de que la piedra angular de la contratación debería ser, por tanto, que el objeto del contrato no es tiempo, ni materiales, ni costes, ni alcance… Es Capacidad, capacidad para generar valor. Y eso es muy complicado de gestionar en con un departamento de compras de cualquier empresa, ¿Verdad?

Se ha debatido mucho sobre las distintas posibilidades de contratación para adecuarla al espectro de proyectos ágiles, y la solución no es única.Tienes por ejemplo enlaces como estos donde se tratan ejemplos de “contratación ágil”

Pero volviendo al objetivo del post, lo que sí parece común en todas es la dificultad de convencer al cliente de asumir una parte del riesgo económico a cambio de una hipotética disminución del riesgo operativo. Y ahí está la clave, en el adjetivo “hipotético”. Hay que convencerle de que monetariamente el montante del ahorro por la adaptabilidad funcional, la entrega continua, el ROI temprano al tener un producto disponible en las primeras fases del proyecto o la asunción del cambio, es significativamente mayor que el del coste derivado de no tener un  precio tasado.

Y si nuestra estrategia es manejar esa incertidumbre, pensemos en cómo hacerlo con las herramientas a nuestro alcance, y es aquí donde encontraremos la flecha que alcanza el punto vulnerable de la agilidad, su talón de Aquiles. Nunca me he sentido muy cómodo con el tratamiento que se le ha dado desde una perspectiva ágil en la dirección de proyectos a la gestión de la calidad y a las métricas en general. Decir algo tan vago como uno de sus valores (El software que funciona, por encima de la documentación exhaustiva) y uno de sus principios (La atención continua a la excelencia técnica enaltece la agilidad) me parece una perspectiva pobre.

Si queremos ofertar capacidad, (obviamente para que nos contraten capacidad debemos ofertar capacidad) necesitamos herramientas que nos permitan definir, cuantificar, cualificar, valorar y tasar económicamente el coste de esa capacidad y desde luego no es cosa sencilla. Deberíamos empezar por darle la importancia debida a las métricas, por supuesto, si queremos avanzar por esa vía, y nos encontramos de nuevo con que la literatura existente nos habla de técnicas de gestión ágil, de reuniones de planificación, de retrospectivas, de refinamiento…. pero nada, o casi nada, de las métricas. Es como si se sobrentendiese que para hacer software de calidad hace falta medir la calidad y para construir software eficientemente hace falta medir la eficiencia, ¡qué menos! Pues sí, es cierto. ¡Qué menos que hacerlo!, pero también no es menos cierto que que podría incluirse de una manera más explícita la revisión de las métricas de calidad o de eficiencia.

Tenemos por tanto la nada desdeñable tarea de medir la ejecución del proyecto, los costes asociados a las tareas, los costes de los impedimentos, los tiempos, las áreas de actuación, los costes de revisión, de defectos escapados, etc. para poder establecer una correspondencia económica entre lo que busca la Agilidad (aportar valor) y lo que necesitamos a la hora de elaborar un contrato (cuantificar los costes de generar ese valor). Obviamente es inviable madurar este tipo de métricas sin un histórico, pero ese ya es nuestro problema y por tanto nuestra responsabilidad. No obstante también es cierto que al ser nuestra responsabilidad tenemos la capacidad de solucionarlo de manera independiente sin impedimentos externos a nuestro propio equipo, experiencia, capacitación y determinación para hacerlo.

El objetivo a buscar, desde mi punto de vista, es un marco de colaboración (y contratación, claro) en el que:

  • Se establezca una primera fase del proyecto en el que se implementen las primeras historias de usuario a un precio fijo (a riesgo por el proveedor) o por Tiempo y Materiales (a riesgo por el cliente) en la que se establezcan los criterios y se tomen las métricas del proyecto. Tanto en un caso como en otro el riesgo es relativo, puesto que el tiempo es muy limitado y por tanto el impacto es controlado.
  • Definir los criterios que miden la capacidad del equipo en conceptos que desglosen las actividades necesarias para llevar a cabo la implementación de las historias de usuario, analizar sus costes y asignar un precio a esa capacidad.
  • Establecer ese conjunto de historias de usuario de referencia que marque los “story points” para la valoración de tamaño relativo de las sucesivas historias de usuario.
  • Establecer un coste (y por tanto un precio) a esa capacidad.

Es fundamental desde este punto de vista la madurez del equipo de trabajo para que formen parte del proyecto no solo en el ámbito técnico, sino en ese otro incómodo ámbito de contratación, valoración y gestión económica del mismo. Tienen que tener plena consciencia de que durante los primeros sprints del proyecto, el desglose de las tareas que se realizan, su catalogación, la medición de tiempos y recursos dedicados a su implementación, los tiempos necesarios para los procesos de aseguramiento de la calidad, los ratios de defectos escapados, costes de reparación, despliegue, impedimentos, etc. es información fundamental para ofrecer al cliente una descripción detallada de en qué elementos vamos a desglosar sus historias de usuario en las planning meetings.

Y es a partir de esta información de desglose, que marca la definición de la capacidad del equipo y por tanto de su precio, desde dónde tendremos que realizar la asignación del peso relativo de las nuevas historias de usuario con respecto a las de referencia e identificar la capacidad necesaria para su implementación (y por tanto el coste, y precio) que marcará lo que tendremos que facturar en cada iteración por la capacidad de mi equipo, ni más ni menos.

Realmente, siendo puristas, no es necesaria tanta métrica, tanto control, tanta catalogación…. El mismo marco ágil te da implícitamente la solución, ya que la capacidad del equipo se “autoajusta” a medida que madura su experiencia en el entorno, el negocio, su cohesión como equipo, etc. Pero no olvidemos que el desarrollo de software es un negocio, y como tal tiene un marco contractual y de seguimiento económico que enfrenta los intereses de las partes. Desde el punto de vista funcional, de satisfacción, de calidad, etc. los intereses de proveedor y cliente son los mismos, pero desde el punto de vista económico es imposible tener esa misma alineación. No es lo mismo el concepto de “todos ganamos” desde una perspectiva u otra ya que el dinero es como la energía, “ni se crea ni se destruye, solo cambia de bolsillo”.

Pero aun no siendo estrictamente necesario, pensemos en qué nos aporta en el proyecto más allá de la facilidad de acuerdo contractual:

  • Herramientas para la cuantificación de los costes
  • Fiabilidad en la planificación, lo que redundará en la capacidad de llevar a cabo los sprints con éxito
  • Es un punto de partida para el aseguramiento de la calidad, puesto que las métricas forman parte de las valoraciones y no solo de la verificación
  • Mejor perspectiva para abordar la mejora continua
  • Información objetiva, y no solo subjetiva, para las sesiones de retrospectiva
  • Más capacidad de autogestión del equipo
  • Mejor punto de partida para la asunción de tareas por parte de cada técnico, con tareas más atómicas e independientes, con menor número de colisiones y menos posibilidad de interferencias
  • Daily Meetings más alineadas con la planificación del sprint
  • Un tablero más realista
  • Un burndown más creible

¿No son muchas ventajas como para dejarlas escapar? Una de las lecciones aprendidas más interesantes que he sacado de los proyectos gestionados desde un marco ágil es que tres pilares fundamentales lo sustentan:

  • La madurez del equipo (no solo madurez técnica y no solo el equipo de desarrollo, sino madurez de gestión, de negocio, de participación e involucración de negocio, del PO, etc.)
  • La confianza entre todos los interesados del proyecto basada en una comunicación abierta y sincera
  • La mejora continua, tanto en el proceso como en el ámbito técnico.

Y son precisamente esos pilares los más beneficiados. La mejora continua, la confianza y la madurez profesional son la clave para fidelizar a un cliente y ganar la confianza en ese modo de contratación, confianza que debe ser mutua y basada en la profesionalidad.

Y a partir de aquí a crecer, a mejorar la relación con el cliente, si queremos tenemos las herramientas necesarias para apostar por perfilar penalizaciones e incentivos o QA con métricas y con SLAs que penalicen o que aporten un plus económico equivalente. (Quien argumente en este caso el compromiso del software libre de fallos no se dedica al mundo del desarrollo del software y que Dios le pille confesado con la gestión de incidencias en periodo de garantía. Los errores forman parte del desarrollo y hay que minimizarlos y gestionar su impacto y resolución, atacar su causa raíz, etc. Pero están ahí como parte intrínseca al desarrollo de Software.)

Si somos capaces de ofertar de esta manera, ¿Quien no querría contratar a un equipo que funciona así?

Si estás interesado en ahondar en esta perspectiva, no dudes en ponerte en contacto conmigo o comenta en el Blog.