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.
Tabla de contenido
Entradas relacionadas
Cómo crear un objetivo motivador5 (1)
Muy buenas Javi,
Totalmente de acuerdo en el artículo. En nuestro proyecto llevamos ya unos meses haciendo un plan de releases en base a la velocidad y experiencia en cada momento. Como es un proceso empírico, es cierto que a veces «fallamos», pero la madurez del equipo a la hora de planificar un Sprint nos hace «equivocarnos» muy poco. Así, el PO es capaz de hacerse una idea a medio plazo de hitos o épicas. Utiliza los planes de releases para enseñárselos a los stakeholders, cuidando mucho que ese plan no sea una «fecha fin de entrega».
De hecho, una herramienta útil para este fin son las burn-up chart. Hago un poco de propaganda para que le eches un vistazo a mi post: https://www.paradigmadigital.com/techbiz/aliate-con-las-metricas-predice-tu-progreso-en-scrum-con-las-burn-charts/
Buenas!
leí tu artículo y está muy bien, todo lo que sea Agile de Paradgima lo tengo en el rádar. Estoy de acuerdo con tu comentario, las herramientas hay que saber entenderlas dentro de un contexto Agile o al final es otra manera de que pase lo de siempre.
Un saludo Manu!
Me ha encantado leer tu artículo!!! Pienso que si las empresas fueran capaces de basar sus métricas en el valor entregado en cada sprint, aquellas que hagan Scrum llegarán a ese punto de auténticos MVPs o releases de valor. Mientras lo que se mida es trabajo hecho ocurrirán todas esas difuncionalidades que has mencionado.
Gracias por compartir.
Alex
Muchas gracias! Pues estoy de acuerdo. Aún hay un cambio cultural que mejorar 🙂