En este último año, me refiero al año pasado, he asistido en diferentes organizaciones a una situación que se repetía en todas ellas, salvado detalles, cuando alguien se ponía a “planificar” una implantación ágil (empezando porque ya lo de “planificar” una implantación ágil suena raro).
La situación de la que te hablo refiere a la gran cantidad de tiempo que en todos estos casos era dedicado a elaborar dicha “planificación”, haciendo previsiones de cómo serán en el futuro los nuevos proyectos ágiles. Hablo del tiempo dedicado a todo eso… a planes, a planificaciónes de implantación, a elaborar en papel fases, y más fases, documentos de trabajo, documentar métodos que se aplicarán cuando un proyecto futuro tenga que hacer uso del paradigma ágil. E, incluso, sí, lo voy a decir, como lo sabes… diagramas de Gantt sobre cómo hemos planificado implantar en el futuro la agilidad. Papel, teoría.
Esto de “planificar” de manera predictiva, pensando en un “papel” lo que a largo plazo ocurrirá, aquello que como equipo de “metodología” pensamos que debe cumplirse, mas aún tratándose de implantar un proceso ágil… suena raro ¿no? Esto representa, de nuevo, que no tenemos las ideas claras sobre la agilidad, que aún no lo hemos pillado, que nos hemos quedado más en el “cambio de método” que en el cambio “de la manera de trabajar”, en el cambio en la “manera de pensar”.
Sin perdernos en detalles, que veo que se me alarga el post, una de las premisas cuando trabajamos de manera ágil, premisa que se cumple igualmente en otras variantes y relacionados, como Lean Starup, o en framewoks más concretos, como Scrum, etc., es la del “feedback” constante y lo más frecuente posible como herramienta de aprendizaje.
Muy sintetizadamente, la idea es que aquello que quiero crear, esa idea general, la voy a ir haciendo poco a poco. Pero, ojo, porque esos “poco a poco” están pensados para ir poniéndose en práctica real, o casi real. Cada uno de esos pequeños trozos (incrementos), queremos que se enfrenten con la realidad rápido y que alguien los use, aun siendo pequeños, para que podamos aprender de esa experiencia de uso y llevarme ese aprendizaje a la creación de la siguiente parte (incremento) de aquello que quiero crear.
Esta idea del “feedback” constante y lo más frecuente posible, con productos no completos pero sí operativos, la puedes ver bajo varios nombres. También puedes encontrártela como “proceso empírico”. Y, de entre todos esos nombres que ha recibido, a mí me gusta mucho el de “Producto Mínimo Viable”.
Algo ya te hable de ello, pero hace ya casi 3 años, en ¿Qué es un Producto Mínimo Viable?, y hoy quiero volver a ello bajo el contexto con el que empezaba este post.
Un Producto Mínimo Viable, o PMV, por el acrónimo, o MVP, de Minimum Viable Product, es un producto parcial orientado a aprender rápidamente qué quiere el cliente, usuario, y haciéndolo empleando el mínimo desperdicio (gastar esfuerzo en cosas que no van a servir).
El producto mínimo viable es una versión mínima de un nuevo producto que permite recoger la máxima cantidad de aprendizaje validado por los clientes con el menor esfuerzo y lo más pronto posible. Hay quien define a un producto mínimo viable como lo mínimo por lo que estaría dispuesto a pagar un cliente.
Puedes decantarte por hacer uso de proceso ágiles o no. Sobre las razones para tomar esa decisión hay ya mucho escrito. Pero si has tomado la decisión de que necesitas tirar poro un proceso ágil… asegúrate que estás siendo ágil.
Y para ello, para no perder la luz, una de las acciones que más te van a ayudar a no perder el norte es esa… trabaja con productos mínimos viables.
Si estás planificando la implantación de un proceso ágil… planifica lo justo y saca un producto mínimo viable que se empiece a usar lo más pronto posible. Sino, caerás en hacer lo de siempre… pero con un nombre más de moda.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024