¿Cuándo dar por terminado un proyecto Agile?

Calendario marcado con la fecha de entrega del proyecto
Cortesía de Pixabay

David, un asistente a los cursos on-line de Scrum Manager, se dió cuenta que aplicando Scrum la pila de producto puede ir aumentando y creciendo a medida que avanza el proyecto... y eso le preocupaba, ya que el Propietario del Producto podría alargar y alargar el tema añadiendo nuevas historias de usuario y que termine convirtiéndose en un proyecto eterno!!!

Cuando pensamos en términos de proyecto pensamos en relaciones contractuales y nos puede invadir el mal sabor de boca de nuestra experiencia con proyectos clásicos, recordemos que según el CHAOS Report del Standish Group de 2011 sólo el 14% de los proyectos en cascada son exitosos.

Pero tomemos la perspectiva del producto, que es lo real, lo que hay detrás de la abstracción que llamamos proyecto. ¿Se puede saber cuando finaliza la construcción y evolución de un software? Nadie lo puede saber, va a depender del mercado y de como somos capaces de adaptarnos. Ojalá la pila de producto se alimente continuamente de funcionalidades de gran valor de negocio, eso quiere decir que el negocio que hay detrás del software está floreciendo. Y ante esta perspectiva ¿limitar la adición de funcionalidades de mucho valor a la pila no sería perder oportunidades y por ende mermar nuestra presencia en el mercado? Scrum va de la gestión de entregas de producto, no de proyectos... esa es la clave.

Pero volvamos a los proyectos, al fin y al cabo una de las grandes verdades de la vida es que los recursos son limitados y las ideas no, por tanto nuestro cliente puede estar limitado por un presupuesto, ¿Scrum podrá proporcionarle un producto por ese presupuesto a base de las mejores ideas?

Un proyecto ágil se limita por presupuesto y tiempo, pero no por alcance, porque su entrega no consiste en funcionalidades, como en un proyecto tradicional, sino en la entrega de valor. En definitiva, limita presupuesto y tiempo, saca el alcance inicial de ecuación, utiliza ese alcance inicial como un punto de partida materializandolo en la pila de producto, y haz que el equipo siempre construya lo más importante, lo que más valor aporte, y con calidad. En el camino incluye funcionalidades emergentes de mucho valor y priorizalas, y cuando llegue la fecha de entrega y se haya gastado el presupuesto, simplemente se acabó el proyecto. A esa fecha habrás obtenido el mejor producto posible para ese presupuesto y tiempo.

Un ejemplo de la vida común: contratas un proyecto a un pintor para que pinte tu salón de color rojo y tu baño de color verde. Lo que más valor tiene para ti es el salón, por tanto el pintor hace el primer sprint en el salón, y supongamos que le ha cabido la primera pared. Hacéis una revisión de sprint, y cuando ves la pared de color rojo te das cuenta de cuanto te has equivocado, que no vas a sentirte cómodo en un salón con ese color rojo!!! La opción clásica sería que el pintor te diga "acabamos la pared de color rojo, luego el baño de verde y en la fase 2 te pinto el salón de otro color"... ridículo, ¿verdad?

La siguiente opción es cuando el pintor está de acuerdo con el cambio de color pero dice que necesita que aumente el presupuesto para comprar pintura nueva y poder efectuar el retrabajo que requerirá de más tiempo. Es una opción válida.

Pero hay una opción más, el pintor pinta el salón de otro color y como el presupuesto es limitado no pinta el baño, porque resulta que el baño tiene poca importancia para ti. Esa es la solución a la pregunta del post, pon el foco en lo que realmente importa y con calidad.

Recordemos que un cliente sabe lo que quiere pero no lo que necesita. Si el Propietario del Producto es quién gestiona el presupuesto, y si su toma de decisiones la basa en el ROI de cada funcionalidad, sabrá perfectamente cuando es el momento de dar por terminado el proyecto/producto.

Aquí os dejo una reflexión:

Un producto que florece no se termina nunca,

simplemente se detiene en momentos interesantes