Aunque la agilidad esté llegando a muchos sectores, mercados y organizaciones diferentes, todavía, en lo que a las relaciones entre clientes y proveedores se refiere, siguen existiendo vestigios del project management tradicional. Y es que cuando se trata de trabajar en proyectos ágiles donde existe externalización y es un partner o proveedor el que proporciona al cliente el equipo para realizar el encargo, la figura del contrato se hace indispensable.
Pero ¿qué tipos de contratos solemos ver en estos casos? Como te comentaba en el párrafo anterior, esta es una parcela donde todavía hay mucho de gestión tradicional de proyectos. Los contratos que suelen firmarse para proyectos ágiles suelen tener muchas menciones al tiempo, al coste, al alcance del proyecto y a la calidad de este. Quizás te estés preguntando: ¿no era que en agilidad buscábamos tener una visión del producto o la solución y no un alcance definido desde el minuto uno? ¿Dónde está ahí el empirismo si está ya todo definido? Preguntas las dos muy acertadas. Mi respuesta a estas preguntas es sencilla: pese a que disfracemos con la palabra agilidad el proyecto, hay muchos de los valores y principios ágiles del manifiesto que se pierden por el camino debido a las restricciones de alcance y de tiempo y a toda la negociación contractual en sí.
Y, si bien es cierto que podemos tener un desarrollo con toques ágiles: fijando iteraciones cada poco tiempo (entre 2-4 semanas), feedback de cliente al final de cada iteración, reflexión por parte del equipo en lo que se puede mejorar…etc. y pese a que esta fórmula existe y está muy extendida, existen riesgos que pueden derivar de este tipo de acuerdos contractuales. Déjame que te cuente un par de ellos:
- En primer lugar, el riesgo derivado de los cambios de alcance. En proyectos que tienen el apellido “ágil” es muy común ver al final de la iteración solicitudes de cambio o de nuevas funcionalidades que no estaban contempladas inicialmente dentro del alcance. Esto puede ser un problema grave ya que, si no se gestionan contractualmente de manera correcta estos cambios de alcance, el proyecto puede peligrar al no haber tiempo o presupuesto suficiente para realizar todo lo solicitado o que nos encontremos que tenemos que sacrificar la calidad de lo que estamos haciendo para dar cabida a lo nuevo, provocando descontento en el cliente por no conseguir todo lo que ha pedido y desmotivación en el equipo del proveedor porque desafortunadamente estas cosas suelen solucionarse “echando más horas”
- En segundo lugar, el riesgo en la toma de decisiones. En la mayoría de estos proyectos el presupuesto suele ser cerrado y la negociación presupuestaria con el proveedor y los detalles presupuestarios del proyecto no los suele tener el Product Owner, que, por otro lado, es la persona que se supone, tiene la potestad de tomar las decisiones sobre lo que se necesita o no se necesita. Esta toma de decisiones “delegada” donde el Product Owner más que priorizar por valor, prioriza por tiempo que se tarda en desarrollar algo, supone un riesgo importante de cara a identificar posibles desperdicios, a tomar decisiones sobre qué hacer y qué no teniendo en cuenta cosas como el ROI o los indicadores de valor sobre la solución. Cuando el presupuesto viene dado y lo maneja otro, el Product Owner pierde su valor en el proyecto
Teniendo en cuenta estos riesgos, y alguno más que puedes estar pensando ahora mismo como: qué pasa si me arrepiento y no quiero seguir con el desarrollo de la solución o, qué pasa si mis circunstancias y necesidades cambian y ya no quiero continuar desarrollando funcionalidades…Todos estos escollos, podemos salvarlos con el uso de los contratos ágiles, que, nos ayudaran a evitar tensiones entre clientes y proveedores y a su vez a garantizar un éxito total en este tipo de proyectos. Los contratos ágiles tienen en consideración la naturaleza propia de la agilidad: cambios bienvenidos, cliente en el centro, valor por encima de todo, la calidad es clave, planes adaptables, colaboración con cliente…etc. y plantean fórmulas que dan cabida, entre otros, a los cambios de alcance, por ejemplo, cotizando las iteraciones (precio por sprint), o poniendo un precio a las historias de usuario entregadas. Con cláusulas como estas, evitas el riesgo mencionado anteriormente sobre los cambios de alcance y empoderas la toma de decisión de los Product Owners, dejando que sean ellos quiénes decidan qué hacer por cada iteración, ojo, siempre que se les de la responsabilidad sobre el presupuesto, que han de tener de acuerdo con su rol. Para evitar riesgos por cambios de necesidades o por reducción de funcionalidades, y, tras una evaluación exhaustiva por parte de cliente de lo que está generando valor y lo que no, los contratos ágiles proponen acuerdos con el cliente mediante el cual se pueda únicamente facturar un mínimo porcentaje de las funcionalidades que no se vayan a entregar finalmente o que el cliente ya no quiera, precisamente para evitar pagar por algo que no se va a hacer finalmente.
En resumen, los contratos ágiles buscan, que los agentes involucrados, colaboren por encima del contrato que hayan firmado inicialmente (como menciona uno de los principios del manifiesto ágil) y, que el objetivo final de esa colaboración sea la entrega de una solución con valor para los usuarios. Al fin y al cabo, esto último es lo más importante ¿verdad? ¿o lo era la cláusula 5a?
Dice un refrán español que “a toro pasado, todos somos Manolete”. Lo que viene a explicar este dicho popular es que es muy fácil predecir lo que ya se ha visto o ha sucedido.
Y con este refrán en mente he pensado en lo bien que me habría venido al inicio de mi incursión en el mundo de la agilidad predecir algunas cosas que de seguro me habrían evitado algún que otro dolor de cabeza. Por ello, me gustaría compartir contigo un listado con las cinco cosas que me hubiera gustado saber cuando empecé en el mundo de la agilidad. ¡Vamos con la lista!
- Agile no es tan moderno: y es que, aunque esto de la agilidad está de moda desde hace algunos años, como dice una buena amiga mía, esto del agile es más antiguo que “el hilo negro”. El manifiesto Ágil cumplió el año pasado 20 años y muchos de los marcos de trabajo denominados ágiles nacieron incluso antes de esa fecha. Así que no, esto del agile no es algo nuevo ni novedoso, hay muchas organizaciones que llevan ya muchos años trabajando y aplicando esta filosofía. Por muy “cool” que te pueda parecer esto del agile y decir que estás aplicando agilidad en tu negocio, quiero que sepas que, si trasladásemos esto a la curva de adopción de la innovación que creó Rogers, estarías en el grupo al que consideraba como “mayoría tardía”. Pero no te preocupes, lo importante es que te hayas dado cuenta de que necesitas cambiar, ahí va otro refrán “más vale tarde que nunca”
- Agile no es Scrum: o también podríamos decir que: no todo en Agile es Scrum. Debido al gran porcentaje de equipos que usan este marco de trabajo su popularidad se ha extendido por todos lados ya sea dentro o fuera del agilismo y parece como si no existiese otra manera de trabajar en “working solutions” en el mundo ágil más allá de Scrum. Tanto es así que no es extraño encontrarte con personas que tienden a equiparar Agile con Scrum. Si te encuentras a alguien y entabláis una conversación donde salga el más mínimo atisbo de la palabra Ágil o Agile, es muy probable que esa persona acabe diciéndote: “¡Ah! Sí, en mi empresa hay un proyecto que está trabajando con Scrum… Y si, Scrum es un marco de trabajo ágil, pero hay muchos otros y muchas técnicas ágiles también, así que te recomiendo que no te quedes solo con Scrum y que abras tu mente ágil
- Está bien no seguir los marcos de trabajo al pie de la letra: este punto es importante tratarlo con cautela. Los marcos de trabajo ágiles hay que estudiarlos bien, comprenderlos y aplicarlos paso a paso, pero está bien llegar al punto en el que no los apliques al pie de la letra. Me explico, una vez ya has interiorizado correctamente el marco o técnica que estás aplicando, deberías ser capaz de comenzar a ver “fallos” o posibles modificaciones al mismo para que se ajuste correctamente a la necesidad concreta de un equipo. Y en esa búsqueda de la mejora es donde aflora el “cherry picking” que si no sabes lo que es te animo a que leas el último artículo de la temporada pasada.
- Aprende, aprende y aprende: “el saber no ocupa lugar” (va de refranes la cosa…) y es que no hay nada más malo para la agilidad que alguien ya sea un desarrollador, un scrum master, un agile coach o cualquier otro rol agile, que se ha quedado desfasado, y que no se recicla. En mi opinión es de vital importancia estar constantemente aprendiendo, volviendo a los orígenes del agilismo a través de clásicos de este, visitando el futuro leyendo sobre las nuevas tendencias o los nuevos alcances propuestos en agilidad. Volviendo a repasar las guías de los marcos de trabajo que más utilices. Leyendo blogs relacionados con el tema, siguiendo a los firmantes del manifiesto ágil…etc. Todo esto puede ser de mucha utilidad a la hora de enfrentarte a los retos típicos en agilidad.
- El error es bienvenido: en el manifiesto ágil uno de los principios ágiles es que el cambio es bienvenido, y yo a esto añado, que el error también lo es. Toda la cultura ágil está embebida de esa filosofía que promueve el error. Y es que, a mí, en particular, hay una cosa que me gusta mucho decir: “donde mejor funciona la agilidad es en entornos complicados, entornos donde la predictibilidad es escasa, entornos empíricos”. Y si basamos nuestra forma de trabajo en la prueba y el error, no podemos penalizar que la gente se equivoque. Tenemos que dejar espacio para probar, para experimentar. Que los equipos u organizaciones, al acabar las iteraciones, sepan si van por el buen camino o no, si van por el buen camino, ¡genial!, ya saben por cómo y hacia dónde deben continuar. Si no es así, gracias a los periodos cortos de tiempo donde revisitamos lo que estamos haciendo, podemos decidir qué desvío tomar de cara a conseguir nuestro objetivo. No pasa nada por equivocarse, mientras que del error seamos capaces de obtener hallazgos significativos, y planes de mejora. Como decía Edison “no he fracasado, solo he encontrado 10000 formas en la que esto no funciona”
Si llevas tiempo en esto de la agilidad quizás te pase lo mismo que a mí, y veas en algunos de los puntos de esta lista, algunas cosillas que te hubieran servido en tu día y que te hubiera gustado que alguien que ya se hubiese “tropezado con esa piedra” te hubiese contado. Y si eres nuevo, espero que esta lista te sirva como ayuda para tu viaje por la agilidad. Y recuerda: “be agile my friend”.
Manager y Scrum Master en una de las Consultoras más importantes del país. Tuvo la suerte de nacer en Sevilla y de poder desarrollar su carrera en esa ciudad. En sus ratos libres podrás encontrarla disfrutando de su pequeña, paseando por las calles de su ciudad leyendo un buen libro.
Todo lo que un Directivo debe saber...
Ha llegado la hora de formar a la Alta Dirección
Sesiones Directivas en Directo y en Remoto sobre todos aquellos aspectos que debe conocer la Alta Dirección sobre Gobierno y Gestión Organizacional.
