El AutoEngaño del MVP

El mundo Agile está trayendo nuevos conceptos que estamos aplicando en  nuestro día a día. Uno de ellos es el Producto Mínimo Viable (MVP) que básicamente consiste en definir el mínimo conjunto de funcionalidades que necesito para poder subir a producción.

El concepto de MVP tiene una parte beneficiosa. Muchas organizaciones se están empezando a plantear el reducir el alcance y eso es un ejercicio de madurez que no es sencillo. El problema es que se está utilizando el MVP como el nuevo paradigma para cerrar un proyecto.
Por ejemplo, hay equipos que en vez de firmar un año de desarrollo firman cuatro meses con un alcance y una fecha cerrada y lo llaman MVP. Una vez más, entramos en la mentalidad de proyecto, después aparecerán los cambios porque el software es complejo y no podemos preveerlo todo. Esos cambios habrá que afrontarlos y finalmente acabaremos con un software deficiente al no tener tiempo para la calidad. ¡Lo que nos lleva pasando toda la vida pero reducido a cuatro meses!

Otro ejemplo típico ocurre cuando seleccionamos un conjunto de elementos del Product Backlog (PBIs), decimos que son nuestro MVP y los abordamos en cascada.

A esto le sumamos que volvemos a la falacia de que el éxito es entregar el MVP en fecha. ¿Dónde queda la inspección y adaptación de mercado? ¿Y si nuestros usuarios rechazan ese MVP? Con esta mentalidad perderemos la flexibilidad de un marco como Scrum para hacer lanzar hipótesis sobre lo que da valor a nuestros usuarios y tratar de contrastarlas.

Lo ideal es ir al mercado lo antes posible; En el primer Sprint es muy difícil y más cuando nuestro software sustituye a otro existente. Aún así, siempre se puede reducir el alcance para hacer lo que de verdad es mínimo para salir y no esperar varios meses. Algunos autores como Jeff Patton hablan de Experimento Mínimo Viable (MVE) como una manera de hacer lo mínimo para experimentar el éxito de nuestro producto aunque todavía no queramos lanzarlo a todos los usuarios y hacer el lanzamiento mundial. En un Sprint se pueden hacer muchas más cosas de las que creemos, y los equipos maduros en Scrum lo hacen.

Otro de los problemas del MVP es que hay mucho miedo a que “lo que no entra en el MVP no se hace nunca”. Este es el miedo tradicional de las organizaciones que trabajan con proyectos. Esta manera de pensar acaba por engordar tanto el MVP que acabas desarrollando Productos Mínimos de 18 meses ¡Eso es una locura en el 2018!. Pensemos que en el manifiesto Agile se hablaba de máximo 2 meses, y eso fue en el año 2001, seguramente hoy esos tiempos se vean excesivos.

¿Qué alternativas tenemos al MVP? Personalmente a mi me gusta más el Plan de Releases o de Sprints. Es una herramienta que utiliza el Product Owner para hacer una estrategia de subidas que trate de maximizar el valor y el impacto en el mercado. Esta herramienta consiste en distribuir los elementos del Product Backlog a lo largo del tiempo en Sprints. Bien entendida ayuda mucho como guía para saber el futuro del producto, mal entendida se  convierte en un proyecto cerrado con fechas de entrega. Una vez más, aquí dependerá de la mentalidad de producto o de proyecto que tengamos en el equipo.

Por tanto, me llena de ilusión que el mundo del management esté evolucionando. Esto es una necesidad por la manera tan pobre en la que hemos venido desarrollando software y la competitividad en el mercado internacional. Eso sí, utilizar palabras modernas para referirnos a conceptos antiguos refleja que la mentalidad sigue sin cambiar; Solo por cambiar el léxico no vas a conseguir el impacto en el mercado deseado. Desde mi humilde punto de vista te recomiendo que no pares de aprender y ser crítico con todos los conceptos nuevos que aprendas ya que mal entendidos te pueden llevar al lado oscuro.

El AutoEngaño del MVP
Vota este post
Compártelo