Agile Inception: Cómo empezar un proyecto Agile o qué hacer antes de empezar tu primer Sprint de Scrum

Hay una falsa impresión, creo que generalizada, de que cuando estamos usando Scrum el proyecto ya tiene su Backlog, ya tiene su equipo, su Product Owner, su Scrum Master y esto es correr haciendo Sprint tras Sprint, liberando software en producción y realizando Demos y Retro como si no hubiera un mañana hasta agotar el presupuesto. Pero surge una cuestión ¿cómo empieza todo? O dicho de otra forma ¿cómo nacen los proyectos ágiles? ¿Nacen por generación espontánea y los cazamos al vuelo o hay que hacer algo con ellos? Eso es lo que vamos a ver ahora que hay antes de empezar a usar Scrum.

Scrum es un marco para la construcción de software. Scrum nos habilita para ir recopilando requisitos de una cierta forma organizada e ir procesándolos con el equipo hasta convertirlos en software, en una aplicación que funcione, pasando por la validación con el Product Owner y/o usuario final y pasando por los prácticas para mejorar la forma en la que estamos haciendo las cosas.

Dicho de forma breve Scrum se ocupa de construir Apps, de construir Software, pero los proyectos para iniciarse necesitan más cosas, cosas que hay que decidir y alternativas que hay que seleccionar y eso no está definido dentro de Scrum.

Vamos a ver cómo hacerlo, cómo iniciar un proyecto agile.

Hay muchas actividades que damos por sentadas cuando estamos realizando un proyecto, pero que deben realizarse antes de que comience. Por ejemplo la primera es conseguir financiación para realizarlo, para poder desarrollarlo. ¿Quién lo hace, quién se encarga de ello?

Cuando ya tenemos una iniciativa sobre un Producto, sobre una App, sobre un sistema, parece que la financiación se consigue automáticamente, pero para la primera vez todo es más difícil y alguien tiene que ser el que dé el primer paso para que podamos comenzar, y como todas las primeras veces suelen ser las más difíciles para convencer a todos los implicados.

Otras de las tareas que se suponen hechas, es la de montar el equipo. Seleccionar y unir a las personas que lo forman es una de las tareas más difíciles y parece como si nos cayera del cielo. Que tengan la visión y que esa visión sea la misma no es algo sencillo.

Pero hay otro conjunto de tareas más obvias, pero igualmente importantes de definir al comienzo de un proyecto como son:

• El alcance, entendiéndolo como lo que voy a hacer y lo que no voy a hacer.
• Poner de acuerdo a todos los interesados (stakeholders) en la visión conjunta del proyecto, lo que pretendemos conseguir y lo que no pretendemos conseguir.
• Qué riesgos existen que puedan poner en peligro el proyecto.
• Qué alternativa de solución se propone para llevarlo a cabo.
• Cuanto y hasta cuando nos llevará

Estas decisiones, que no tienen que estar grabadas en piedra, si deben ser abordadas al comienzo de un proyecto para evitar posibles repercusiones posteriores. Una de las técnicas más interesantes para tratarlas es una sesión de Agile Inception.

Por eso vamos a ver en qué consiste una de estas sesiones de Agile Inception.

El Agile Inception es una dinámica o conjunto de dinámicas desarrolladas en el libro The Agile Samurai de Jonathan Rasmusson (libro que te recomiendo desde aquí) para poder dar respuesta a estas necesidades previas al lanzamiento de un proyecto.

Para facilitar las mismas se organizan como un mazo de cartas (inception deck) formado por 10 cartas. Cada una de estas cartas se encarga de un aspecto a tratar al comienzo del proyecto y vamos a ver cada una de ellas a continuación:

Lo primero es aunar la visión que todos los que conforman un proyecto tienen de él. Cada persona puede partir de una idea diferente, ambigua, por eso lo primero es poner una visión común en la que todos entendamos lo mismo. Para eso se parte del por qué estamos aquí donde se intercambia la visión del proyecto.

Si todos tenemos la misma idea del proyecto tenemos que ser capaces de crear un breve discurso de nuestro proyecto/producto para vendérselos a otros. Afianza el conocimiento sobre el mismo y nos hace volcarnos en lo que nos diferencia del resto.

Para ir más allá en los beneficios que se alcanzará con nuestro proyecto, construiremos la caja de publicidad del producto mostrando sus beneficios, lo que le aportará a los clientes. También buscaremos cual sería su eslogan.

Nuestro proyecto tendrá un alcance determinado y se dejará cosas fuera. En esta dinámica dejamos claro qué está dentro del proyecto, qué se queda fuera y qué temas están pendientes de tomar una decisión sobre ellos.

Es importante conocer a todos los interesados que rodean al proyecto, por lo que dedicar tiempo a conocerlos es algo necesario.

Se acuerda la arquitectura y las herramientas que utilizaremos en la solución del proyecto. No dejaremos suposiciones.

Esta dinámica nos hace pensar en las peores pesadillas que podría suceder. Hora de identificar los riesgos que cada uno podemos identificar para nuestro proyecto.

Se propone dar una idea de la dimensión del proyecto, pero en términos generales, definiendo su duración en 3, 6 o 9 meses, no en términos exactos. El objetivo es tener una idea del orden de magnitud y ver si es asumible con los recursos de los que disponemos.

Nadie debe tener dudas sobre las prioridades cuando vayan surgiendo los problemas. ¿Qué va antes la calidad del producto o el presupuesto? ¿el tiempo o la usabilidad? etc.
Describimos de forma consciente las distintas prioridades.

Aquí ya intentamos dar una idea del roadmap de entregas y de los costes que supondrá.

Espero que tengas un visión un poco más clara del inicio de un proyecto ágil y puedes comenzar a usar la Agile Inception en tu beneficio.