Ejecución Ágil de proyectos cerrados, ¿tiene sentido hacerla?

0
332

Ejecución Ágil en proyectos cerrados: el asunto en cuestión es un tema controversial y seguramente genere más debate con mi respuesta, pero antes de meternos de lleno en ella es necesario que queden claros algunos conceptos. Entre ellos el de qué es la Ejecución Ágil.

Si preguntas a la gente, de tu alrededor en el sector IT, sobre qué entienden ellos por Agilidad probablemente recibas respuestas muy dispares. Algunos te dirán que se trata de conseguir que las personas colaboren, que se reúnan diariamente, obtener equipos autoorganizados. Otros te dirán que esto no es una definición de la Agilidad y que la Agilidad es una mentalidad. Aunque esto tampoco responde a la pregunta.

Entonces, ¿de qué se trata? Pues todo tiene que ver con el producto.

Al inicio de un proyecto, cuando empiezas a trabajar en un proyecto que no es Ágil, lo primero con lo que te encuentras es que las expectativas no están claras en este punto. No las conoces al inicio, pero una forma de lidiar con ello es preguntar al cliente, a los usuarios finales, investigar el mercado, esto es hacer todo el trabajo que sea necesario para tener un entendimiento claro de las expectativas y esto se hace al principio del proyecto.

Una vez que tienes estas expectativas claras piensas en la solución que puede satisfacer dichas expectativas. Luego haces el diseño, planificas cómo se va a crear y finalmente, puedes marcarte una hoja de ruta para que tu proyecto tenga éxito siguiendo un plan. El cual nunca será ideal y tendrá múltiples desviaciones de las que deberás reponerte para alcanzar una entrega exitosa.

La imagen muestra cómo se desvía un desarrollo de la planificación original hasta la entrega del producto final.

Esto funciona de forma acertada para determinados tipos de proyectos. Por ejemplo, si quieres construir un edificio o mandar una cápsula tripulada a la estación espacial internacional. De hecho, puede que sea la única forma que tengas de hacerlo. Sin embargo,  existen algunos proyectos que cuando lo haces de esta manera y entregas el producto observas que los clientes tenían otras expectativas bastante diferentes.

Esto es más frecuente de lo que te puedes imaginar porque el cliente no sabe lo que quiere cuando se trata de proyectos IT. Sólo lo sabe cuando le entregas algo que de verdad funciona, y tal como hemos visto, esto ocurre al final y eso es un gran problema.

¿Tenemos alternativas?

Pues sí, la otra alternativa se da cuando encaramos expectativas que no están claras, en lugar de forzar, seremos extremadamente precisos al inicio del proyecto, actuaremos de forma que nos enfocaremos en los siguientes pasos que vamos a dar para acercarnos al producto deseado. Esto es, crear el producto más simple que puedas crear y que cumpla las expectativas, o también llamado MVP (Minimum Viable Product). Aquí te lo explica más en detalle mi compañero Jesús.

Lo que ocurrirá aquí será que cuando muestres este MVP al que llamaremos Incremento, tendrás un mejor entendimiento de las expectativas del cliente y se te mostrarán diversas alternativas por las que continuar desarrollando ese producto y en función del feedback obtenido, se selecciona la que parece mejor. Y así, continuamente irás mostrando el incremento y obteniendo un feedback que te guiará hacia donde se quiere llegar.

La imagen muestra un incremento el cual validado proporciona diversas vías a elegir y como eligiendo la que se cree más correcta da lugar un nuevo incremento con nuevas vías que surgen según el feedback recibido tras su validación.

Por lo que hemos visto, aquí tenemos dos formas de desarrollar un producto:

  • La primera, llamada PREDICTIVA.
  • La segunda, llamada ADAPTATIVA.

En la primera intentamos predecir todo de antemano (piensa en la cápsula espacial) y en la segunda alternativa vamos sobre la marcha haciendo pequeños pasos sobre los que obtenemos feedback que recibimos del entorno. Puedes saber más sobre la planificación predictiva y adaptativa en este artículo de aquí.

Por tanto ÁGIL o AGILIDAD es un término que podemos usar para referirnos a sistemas adaptativos independientemente de la metodología o marco de trabajo empleado para crear el producto.

Entendiendo esto, ahora podemos embarcarnos en responder a la pregunta de cómo encajar la agilidad en un proyecto cerrado o PREDICTIVO, o lo que es lo mismo: ¿podemos usar la Ejecución Ágil en cualquier tipo de proyecto?

Pues podríamos generar un debate, incluso alguna charla para foros, Meet Up y Open Space donde hablamos del mismo.

Lo que hace especial a la Ejecución Ágil es su ciclo de vida y para saber si tiene sentido hacerla debemos plantearnos dos preguntas:

1.- ¿Necesito ser Adaptativo? 

Hemos visto que el principal problema de los proyectos IT cuando trabajamos de forma Predictiva es que vamos desarrollando la solución durante todo el ciclo de vida y es al final de este cuando se muestra, descubriendo el gran problema que tiene este tipo de proyectos y es que o tienes muy claro lo que quieres construir desde el inicio (piensa en el caso de la construcción de un edificio) o en otro caso tendrás bastantes problemas intentando predecir qué tipo de producto se necesita entregar al final del proyecto.

En el caso de no tener clara la solución tenemos la alternativa de trabajar de forma adaptativa, esto es, teniendo iteraciones en el que al final de cada una tendremos un MVP con el que los usuarios finales podrán interactuar y darnos un valiosísimo feedback con el que continuar el desarrollo.

Plantéate ser adaptativo cuando tengas que adaptarte constantemente al entorno, cuando exista tal incertidumbre que no sepas cuál será el siguiente desafío que vas a tener que superar para conseguir dar forma a tu solución.

Por tanto, piensa siempre en la imagen global de tu proyecto y hazte la pregunta: ¿realmente necesito ser adaptativo?

2.- Por último, aborda la pregunta: ¿puedo ser adaptativo?

Para finalizar y continuando con mi respuesta a la pregunta inicial “Ejecución Ágil de proyectos cerrados. ¿Tiene sentido hacerla?”, indicar que un proyecto calificado como cerrado ya está mal desde el principio puesto que haciendo esto lo que pretenden es reducir la incertidumbre sobre el mismo (mediante la fecha de entrega).

No hay que engañarse, el proyecto no va a llegar a fecha, este no se va a desarrollar de forma ideal con lo cual dejémonos ya todos de engañarnos de una vez. La agilidad lo que te va a permitir es poner orden, diferenciar la entrega, y centrarnos en aportar valor al cliente.

Lo que sí vamos a conseguir desarrollando de forma adaptativa es la entrega de un producto mínimo viable (MVP), funcionando y que cumple con tus expectativas (incluidas las de excelencia y de calidad), en un plazo menor de tiempo. Podemos decir entonces que nuestra velocidad de entrega ha aumentado.

Esto es así ya que con la ejecución ágil buscamos una sostenibilidad y continuidad del ratio del valor entregado (Sustainable Pace). El cual incluye el control de la Deuda Técnica de forma constante que en otro caso nadie nos garantiza que se controle.

Dejar respuesta

Please enter your comment!
Please enter your name here