5 pasos para implantar un framework ágil en un proyecto cerrado

Cuando, como agilistas, escuchamos las palabras “proyecto cerrado”, suele ocurrir que un escalofrío recorre nuestra espalda de arriba a abajo. Sin embargo, afrontar un proyecto cerrado usando un framework ágil no tiene por qué ser una terrible experiencia. En este artículo veremos cómo, aplicando unos sencillos pasos, podemos echar a andar un proyecto y hacer que dos términos aparentemente opuestos puedan confluir.

El escenario para el que estos pasos aplicarían sería un proyecto con duración determinada y para el cual se ha propuesto al cliente seguir un framework ágil para obtener feedback cuanto antes que pueda ayudar a trasladar bloqueos, riesgos o dependencias y proveer de las herramientas para planificar nuevas fases.

Este escenario supone un auténtico reto para un agilista, puesto que debe identificar con el cliente qué bloqueos existen, a qué acuerdos se llegan y qué avance ha habido en el desarrollo de la solución, de cara a gestionar correctamente las expectativas. El objetivo principal es evitar burocracia adicional consiguiendo que haya una transparencia total en todo momento. Veamos cómo podríamos conseguir ese objetivo y ser exitosos.

Paso 1. Elección del framework que se quiere implantar.

Normalmente, al ser un proyecto con alcance cerrado, el marco más adecuado sería acercarnos a Scrum siempre y cuando exista un incremento de valor, mientras que el acercamiento sería más adecuado usando Kanban en el caso de que tuviésemos un flujo continuado de tareas.

Paso 2. Kick-off con el cliente.

El objetivo de esta sesión es establecer un entendimiento compartido del alcance del proyecto, explicitar qué objetivos se quieren conseguir y definir el marco de colaboración con el cliente, esto es, el día a día. En este último punto es donde se encajaría este paso. El objetivo principal es explicar pormenorizadamente aspectos como los eventos, su periodicidad, su objetivo, quién se precisa que asista, la dedicación de personas por parte del cliente y los bloqueos en caso de que existan (accesos, etc.). De cara a un enfoque más ágil, una fase de inception más light podría ayudarnos mucho como forma de sustituir esta parte del Kick-off clásico.

Paso 3. Puesta en marcha del framework.

Al terminar el kick-off, se deberá al menos agendar la daily y la primera planificación del sprint. Sería aconsejable que durante la primera semana se asignen intervalos fijos de tiempo para las reviews, las retrospectivas y los refinamientos (si es necesario, puesto que pueden ser ad hoc). De este modo, a las personas requeridas por parte del cliente les resultará más fácil asistir. Es importante que, especialmente durante la primera iteración, se haga especial hincapié en recordar para qué sirve cada uno de los eventos, de manera que los asistentes tengan claro el objetivo y de este modo evitar temas que no vienen al caso y que generan dispersión. Si el equipo no es lo suficientemente maduro es posible que se requieran algunas sesiones adicionales para mentorizar sobre el framework y que tengan claro el objetivo de cada evento y el principio de entrega de valor en cada iteración. También es importante que en las primeras iteraciones no solo se trabaje con el Product Owner en lo que se ha decidido en el Sprint Planning, sino que se intente adelantar refinando lo que vendrá en siguientes iteraciones, y siempre que el alcance tenga aspectos por definir más en profundidad. Igual que antes, si el equipo es suficientemente maduro los refinamientos serán ad hoc y frecuentes, y si no habrá que establecer unas ventanas donde realizarlos.

Paso 4. Uso del Incremento.

La Guía Scrum indica lo importante que es el buen uso los distintos artefactos (Product Backlog, Sprint Backlog e Incremento) para que el cliente tenga una visión clara de cómo está yendo el proyecto en todo momento. Al ser un proyecto cerrado, el incremento cobra el papel de protagonista principal. La clave es: ¿Cómo mostramos el incremento de forma que no suponga burocracia adicional y nos sirva como artefacto único para explicitar el estado global del proyecto? Haciendo uso de la Sprint Review para mostrar un entregable mediante el cual los stakeholders puedan ver aspectos como el sprint goal, qué se ha hecho y qué no, el avance global, los bloqueos, los acuerdos e incluso para tener la aceptación formal de un incremento de valor. Típicamente, aparte de lo que se muestre visualmente durante la Sprint Review para obtener feedback de los stakeholders, resulta de mucha ayuda realizar una presentación donde se reflejen los aspectos mencionados anteriormente. Usar dicha presentación como guía cumple varios objetivos:

• Hacer transparente el avance y los bloqueos
• Mencionar los riesgos existentes para que se puedan paliar
• Explicitar el estado del proyecto, asumiendo los posibles retrasos si son causados por no ir a la velocidad esperada, pero paliando los posibles retrasos ocasionados por terceras partes o por el cliente.
• Que al cliente le sirva de entregable sin necesidad de recurrir a burocracia adicional
• Métricas para demostrar el avance y la implicación del equipo en la mejora continua

Paso 5. Cambios de alcance y acuerdos.

Este paso solamente sería necesario si el cliente quiere añadir nuevas funcionalidades o reemplazar existentes a las acordadas en la propuesta. Estos son dos de los escenarios más probables:

• El cliente decide añadir una funcionalidad. Se deberá acordar que otra de la misma complejidad debe salir del alcance del proyecto
• El cliente decide incluir una funcionalidad pero se quiere mantener el mismo alcance. En este caso el equipo de desarrollo tomará nota de los requerimientos de la nueva funcionalidad y realizará una estimación en esfuerzo. Se realizará una planificación conjunta añadiendo este esfuerzo en base al número de iteraciones necesario para llevarla a cabo de acuerdo con la capacidad del equipo de desarrollo. Por último, se renegociará el alcance y el coste con el cliente de acuerdo a esa planificación, involucrando a desarrollo de negocio.

Es importante recalcar que si no se realizan acciones similares a las descritas en este último paso, el riesgo de sobreesfuerzos e incumplimiento se incrementa exponencialmente. Dos líneas rojas que se deben paliar con una adecuada gestión de expectativas y negociación con el cliente.

En conclusión, siguiendo estos consejos y realizando una adecuada gestión de las expectativas y de los riesgos, un proyecto cerrado bajo un framework ágil puede ser exitoso y no necesariamente precisar de otro tipo de reportes y reuniones extra.