-Las reuniones son inevitables-

Nos guste o no. Da igual la metodología o el tamaño del proyecto, siempre están ahí, y pueden ser desde una total pérdida de tiempo hasta una de las mejores herramientas de trabajo.

Durante mucho tiempo las reuniones me parecieron un mal necesario. Era incapaz de acudir a una sin el ordenador para poder, al menos, revisar el correo (no sé porqué parece que está más aceptado que hacerlo con el móvil). Aún intento evitarlas cuando puedo si sé que realmente no van a ser útiles.

Por otro lado, he visto cómo muchísimas veces el equipo empezábamos a trabajar y no estábamos alineados. Incluso alguna persona nueva empezaba a programar sin saber de qué iba el proyecto, solo con la descripción de la tarea, lo que daba resultados totalmente inesperados. Todo por no haber hecho una reunión, o no haberla hecho de la forma y con las personas adecuadas.

-Kickoff 2.0-

La reunión de inicio, o kickoff, será sin duda la más importante del proyecto. Para que sea realmente un éxito deberíamos ser capaces de conseguir que todos los involucrados entendamos lo mismo: qué queremos hacer, por qué lo hacemos, cómo vamos a conseguirlo, cuánto nos va a costar… Solo pensar en una reunión larga, con muchas personas, objetivos a largo plazo puede hacer que nos entre el sueño.

Parece algo antiguo y poco ágil, pero nada más lejos, recordemos lo de: piensa en grande y actúa en pequeño. No se puede pensar en grande sin resolver estas cuestiones, por ello Jonathan Rasmusson incluyó en su libro The Agile Samurai la Inception Deck, un conjunto de actividades para el inicio del proyecto orientadas a alinear el conocimiento y ajustar las expectativas. En este artículo incluiré algunas de estas actividades.

-Incepcion Deck-

• ¿Por qué estamos aquí?

La mayoría de las veces hablaremos de lo que queremos construir, pero pocas veces de porqué lo hacemos. Esta actividad consiste en aclarar a los involucrados por qué se invierte tiempo y dinero en este proyecto: por seguridad, por cumplir un reglamento, para mejorar el rendimiento… Comprender el motivo de porqué hacemos el proyecto ayudará a tomar mejores decisiones durante el desarrollo del mismo.

• Crear una “NOT List”.

Se trata de añadir al lado del alcance una lista de lo que no queremos hacer. Es realmente útil y ayuda a definir mucho mejor los objetivos del proyecto. Por ejemplo, saber que estamos haciendo una tienda web pero que no venderemos fuera de España. Esta actividad también saca a la luz aquellos puntos que no están claros, que se anotan como pendientes para resolverlos cuanto antes.

• Muestra la solución.

No se trata de definir todos los detalles de la arquitectura, pero sí dar una visión general de la solución. Aunque seas partidario de que la arquitectura surja durante el desarrollo, estaría bien saber si vamos a desarrollar en Java o en C#, si hay requisitos tecnológicos que cumplir, o cuál es la infraestructura sobre la que vamos a desplegar si ésta ya existe.

• Lo que nos quita el sueño.

Repasar los principales riesgos del proyecto junto a los involucrados ayuda a estar mejor preparados para la tragedia. Saber por cuales merece la pena luchar y cuales son insalvables. Si hay acciones que tomar, cuanto antes, mejor.

-No hay recetas mágicas-

Estas son solo 4 de las 10 actividades incluidas en la Inception Deck. No se trata de una receta mágica, como dice José Manuel Beas en su web, estas actividades se describen como una baraja (deck), no es obligatorio pasar por todas, aunque sí recomendable.

Estas prácticas se pueden sustituir y adaptar, y probablemente sirvan de inspiración para actividades productivas para otros tipos de reunión. Algunos podrían decir que el sprint planning soluciona algunos de estos problemas, y puede que lo haga incluyendo prácticas similares.

Puedes conocer todas las actividades en el artículo The Agile Inception Deck, traducción del artículo original de Jonathan Rasmusson.