¿Cómo evitar los proyectos sandía?

Proyectos sandía - Sandía cortesía de Pixabay

Estamos a un mes de la fecha de entrega, todo va muy bien y el proyecto está en verde. De repente, como un bandido que nos asalta desde detrás de un árbol, todo parece ir mal y el proyecto se pone en rojo; desviado, con sobrecostes... un verdadero desastre. Eso es lo que se llama un proyecto sandía, verde por fuera y rojo por dentro. Los proyectos sandía suelen ocurrir por falta de transparencia, uno de los valores fundamentales que promueven Scrum y la Agilidad, uno de los valores que debería de estar en cualquier proyecto.

También existen los proyectos cangrejo, que siempre están en rojo, se complican cada vez más y hacen sufrir a todos en todo momento... pero esos son otra historia y no son objeto de este post.

Veamos qué cosas podemos hacer para que nuestros proyectos ágiles no se conviertan en proyectos sandía:

• La DoD (Definición de Hecho): introduciendo una definición de hecho para las tareas del proyecto. La DoD alineará el entendimiento de lo que significa "hecho" para todas las personas involucradas en el proyecto; "hecho" significará lo mismo para negocio, los interesados, el jefe de proyecto y los desarrolladores. Conseguiremos dos beneficios; reduciremos el retrabajo, ya que lo que esté hecho verdaderamente lo estará, y no habrá sorpresas ni malentendidos. Por otro lado ganaremos visibilidad sobre el progreso real del proyecto, ya que lo finalizado realmente estará finalizado.
• Focalizar en valor de negocio: priorizando las tareas en función del valor entregado al cliente. Así empezaremos el proyecto construyendo aquellas funcionalidades que sean más críticas o resuelvan las mayores necesidades de nuestro cliente. Las funcionalidades que queden para el final del proyecto no desatarán ninguna crisis si se desvían o no se hacen.
• Acabar antes de empezar: introduciendo una regla que marque que solo se puede continuar con la siguiente tarea del proyecto cuando la tarea anterior esté totalmente finalizada. A parte de focalizar al equipo, y por tanto acelerar el flujo, esta regla va a evitar que haya muchas tareas abiertas que oculten el verdadero progreso del proyecto.
• Nunca aceptar tareas que no cumplan con la definición de hecho: una tarea hecha al 90%, por ejemplo, no está hecha. Si la aceptamos como hecha, sea como equipo, jefe de proyecto o interesado, introduciremos incertidumbre en el proyecto que cuando explote generará un retrabajo que será muy costoso.
• Dividir en tareas pequeñas: tareas pequeñas focalizan por ser pequeñas, si empezamos una tarea pequeña es muy probable que no nos interrumpan mientras trabajemos en ella. Por otro lado tareas pequeñas son más fáciles de comprobar y de testear, por tanto será más fácil aplicar la definición de hecho. Tareas pequeñas dan sensación continua de avance y de cerrar cosas, con lo que habrá menos ruido en la cabeza de los desarrolladores y por ende una mayor motivación.
• Dar visibilidad frecuente a lideres e interesados: involucrándolos en revisiones y demos frecuentes de lo que estamos construyendo. Muchas veces la falta de visibilidad sobre la realidad del proyecto provoca que interesados, clientes y managers tomen decisiones equivocadas e influyan de forma negativa en el proyecto. Así por ejemplo es muy positivo que éstos conozcan las problemáticas por las que pasa el proyecto o el equipo, ya que éstos pueden aportar soluciones desde fuera que desde dentro del equipo no hayamos pensado.

Quiero finalizar el post resaltando que las prácticas y artefactos que he mencionado son algunos de los que promueve la Agilidad...