Lecciones Aprendidas por Jorge Abad

Este blog comparte estrategias y aprendizajes sobre desarrollo de software, marcos, métodos y metodologías ágiles como Scrum, Kanban y XP, con un enfoque en escalamiento ágil y Business Agility. Su propósito es ayudar a profesionales de la gerencia de proyectos, productos, scrum masters, agile coaches, agentes de cambio, y líderes a mejorar sus procesos y promover la experimentación como motor de innovación, facilitando su adaptación en entornos empresariales cambiantes.

Mostrando las entradas con la etiqueta mvp. Mostrar todas las entradas

martes, noviembre 08, 2022

RespuestasAgiles: ¿Cuál es la diferencia entre Producto Mínimo y Producto Mínimo Viable (MVP - Minimum Viable Product)?

jueves, octubre 06, 2022

El peligroso espejismo de la "Metodología Híbrida" en el mundo del software

Hola a todos

Hace poco tuve tres momentos en donde la metodología o enfoque híbridos de trabajo me los he topado y considero que es valioso escribir y aclarar sobre ellos:

Primer Momento: hablando a cerca del Lean Business Agility Model (LBAM) con el PMI Antioquia, me preguntaban mi opinión sobre el modelo híbrido, en esencia mi respuesta fue:

"Si lo que se está pensando es llevar prácticas de lo tradicional al mundo ágil, esto NO es exitoso, lo contrario sí puede serlo"

Segundo Momento: en varios clientes para los cuales trabajo me están comenzando a decir: "No, no somos ágiles, tenemos una metodología híbrida" y cuando voy a ver, están haciendo proyectos a alcance, tiempo y costo fijo por sprints, sobre lo cual hablaré más adelante.

Tercer Momento: en el reporte de Certiprof Anual - clic aquí -, el cual recomiendo ampliamente pues la mayoría de quienes lo respondemos somos latinos, y cuenta con interesantes hallazgos para nuestra cultura y región; Lucho Salazar y yo opinábamos sobre la aproximación híbrida en la ejecución de proyectos:

CertiProf Agile Adoption Report 2022

"Muchas organizaciones en su acercamiento a la hacia la agilidad han adoptado marcos híbridos, es decir, combinan prácticas ágiles y tradicionales; lo cual es ilustrado en la gráfica. Aunque este enfoque no es la mejor práctica, es un inicio que invita a seguir cambiando, pero si se continua allí puede constituirse en un riesgo a largo plazo, debido a que quienes abrazan la agilidad completamente logran aumentar entre tres a cuatro veces su productividad, tomando una ventaja creciente sobre las híbridas" - Jorge H. Abad L.

---

“Cada día un mayor número de organizaciones están trabajando con un enfoque Agile y Lean. El hecho de que la mitad del estudio los participantes respondieron que usar un enfoque híbrido es natural, dado que la mayoría de las empresas se encuentran actualmente en un proceso de cambiar de las prácticas tradicionales de gestión y ejecución a los basados en el pensamiento ágil. Este es un proceso lento que puede llevar años. Las organizaciones no pueden y no debe comprometerse con un gran cambio o un cambio de "todo o nada", porque primero deben aprender a lidiar con los impactos del cambio y es mejor empezar poco a poco, con una o dos iniciativas. A partir de ahí, a medida que aprenden de las reacciones del entorno, pueden agregar nuevos equipos y áreas de la empresa al proceso. El hecho de que una de cada tres empresas ya esté utilizando un enfoque Agile es consistente con el trabajo que se ha estado haciendo desde la década pasada. Estas empresas han recorrido un largo camino para entender, internalizar, practicar y promover una cultura de colaboración y innovación, pilares esenciales de las organizaciones exitosas de hoy”. - Lucho Salazar

Pero vamos por partes, entendamos el por qué del título de este artículo.

¿Qué es una metodología híbrida?

Inspirado en la "Figure 2-7. Development Approaches del PMBoK 7.0

Un enfoque híbrido, está definido por: "Un enfoque de desarrollo híbrido es una combinación de enfoques adaptativos y predictivos. Esto significa que se utilizan algunos elementos de un enfoque predictivo y otros de un enfoque adaptativo. Este enfoque de desarrollo es útil cuando existe incertidumbre o riesgo en torno a los requisitos. Híbrido también es útil cuando los entregables se pueden modularizar, o cuando hay entregables que pueden ser desarrollados por diferentes equipos de proyecto. Un enfoque híbrido es más adaptativo que un enfoque predictivo, pero menos que un enfoque puramente adaptativo." (1).

Por lo tanto, no es un enfoque donde nos estamos preguntando y validando constantemente "si lo que se está construyendo o entregando es la solución correcta", como ocurre en el mundo del desarrollo de software, pero tampoco se tiene completa certidumbre sobre el resultado final, un ejemplo podría ser el despliegue de un nuevo proceso organizacional, que implique construcción de instalaciones, capacitaciones, desarrollo de software (este software se debe desarrollar con una aproximación ágil) y construcción de máquinas; son varios frentes que se pueden modularizar para entregar valor de forma incremental.

Alguien dirá: ¿Pero en el desarrollo de una solución de software sabemos que módulos vamos a tener? Posiblemente sí, pero el enfoque ágil (adaptativo) te garantiza que no construyas software de desperdicio, y la constante repriorización y refinamiento del backlog, sumado al despliegue continuo de la solución (que te permite su validación) puede significar que se halló valor mucho antes implicando que los supuestos iniciales quedaron obsoletos, pero logrando economias mayores 60% debido a su enfoque basado en Pareto (2).

¿Por qué es un espejismo peligroso en el mundo del desarrollo de software?

Por las siguientes razones:

Es una zona cómoda: he observado que se denomina híbrido a trabajar en cascada en grandes corporaciones, de forma que ya no es necesario tener al usuario con el equipo, ni es requerido que validen las soluciones. es decir,

el mismo desperdicio de siempre,

requerimientos al inicio, esfuerzo del proveedor, controles de cambio y quejas del cliente porque no entregaron lo que se pidió. Por lo tanto,

Híbrido es el nombre de la nueva cascada corporativa

Observo que son organizaciones que no aprendieron a trabajar de forma ágil, no saben como hacer ahorros con este enfoque (aún siguen diciendo que ágil es costoso, lo cual es falso), pero para no verse muy anticuadas llamando a su metodología tradicional o cascada, le llaman híbrida, la cual es un desperdicio de tiempo, dinero, y oportunidad de generar valor por donde quiera que se le mire.

Están poniendo reglas de cascada a proyectos ágiles: he visto que se llama metodología híbrida al ponerle al desarrollo ágil las reglas de cascada, es decir, alcance, tiempo y costo fijo, pero eso sí, hecho en sprints, pero sin retrospectivas porque no es necesario aprender más ¡Plop! - recomiendo leer la referencia (3)-.

Se está perdiendo oportunidad de generar y atrapar más valor: las organizaciones al casarse con este modelo híbrido (insisto no veo problema con que sea algo temporal, lo que veo peligroso es que de allí no se evolucione), están perdiendo oportunidad de capturar valor y de generarlo a sus clientes y más temprano que tarde, organizaciones que realmente si ejecuten ágil de forma disciplinada les tomarán una ventaja exponencial, debido a que la agilidad bien practicada cuadruplica la generación de valor y la eficiencia de los equipos.

¿Cómo evitar el espejismo?

Hay varias estrategias que pueden ayudar en evitar el espejismo:

Comprender en que consiste la mentalidad lean-agile (3).
Comprometerse a ejecutar los proyectos ágiles (y por ende de desarrollo de software) con las reglas de ágil, de forma que se generen ahorros y altos impactos.
Si se tiene un proyecto tradicional y quiere volverlo híbrido, identifique posibles módulos, formas de generar valor temprano y retroalimentación valiosa en caso de que aplique; de manera que logre adaptaciones en caso de ser posible.
No lleve prácticas tradicionales al mundo ágil, es decir, planeación predictiva para el mundo del software, pues estas no van a servir.

Para cerrar, algunas ideas ágiles para el mundo tradicional

Como se ha argumentado en el artículo, llevar prácticas tradicionales al mundo ágil es desperdicio y fricción, pero existen prácticas ágiles que pueden mejorar el mundo tradicional, a continuación, algunas ideas:

tener dailys de sincronización del equipo de trabajo
hacer retrospectivas o sesiones de mejora con cadencia de al menos de una vez al mes.
usar backlogs y priorizarlos constantemente si la naturaleza del proyecto lo permite.
preguntar y preguntarse constantemente ¿si lo que se hace está generando valor? y corregir en caso de que no.
Identificar mínimos productos viables y liberarlos incrementalmente:

Ejemplo 1: Una casa de campo de forma incremental y adaptativa (pues no se posee todo el dinero), un posible plan de releases puede ser:

Release 1 o MVP (PMV - Producto mínimo viable): La cocina, el baño, y una habitación para dormir.
Release 2: otro cuarto
Release 3: la sala
Release 4: la piscina
Release 5, etc, etc.

Ejemplo 2: Una unidad residencial de 12 torres

Release 1: torre 1 y 2
Release 2: torres 2 y 3
Release 3: la piscina y el salon social
Release 4: no se realizó debido a cambios económicos del entorno.

Hasta acá este compartir.

Bienvenidos tus comentarios

Saludos ágiles

Jorge Abad.

Referencias, aclaraciones, notas y comentarios

A Guide to the Project Management Body of Knowledge PMBOK® GUIDE. Seventh Edition
La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum? (clic aquí)
¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?)
Esto lo explico ampliamente en el libro: Nuevas Aguas, Nuevos Navíos, Nuevos Navegantes: Business Agility con notas sobre Transformación Digital (clic)

jueves, febrero 25, 2021

Tres Ejemplos de Productos concebidos de Forma Ágil - Agile Inception

Hola a todos

A mi criterio, una de las mejores formas de aprender ciertas técnicas, a parte de experimentarlas, es viendo ejemplos, es por esto que a continuación les comparto tres casos de Agile Inception de productos digitales, el resultado final es un plan de releases del cual se pueden luego detallar las historias de usuario.

Estos ejemplos fueron desarrollados por los Estudiantes de la Cohorte 2020-Sem02 de la ESPECIALIZACIÓN TECNOLOGÍAS AVANZADAS PARA EL DESARROLLO DE SOFTWARE de la Unab, a quienes tuve la oportunidad de enseñarles la Materia de Metodologías y Marcos Ágiles.

Se desarrollo un caso al cual se le identificó:

El Problema: qué es lo que intenta ser resuelto con el sistema
La Visión: Elevator pitch
El Vecindario: áreas y sistemas con los cuales se relacionará el sistema
Product Vision Board: usuarios, necesidades, productos y metricas
User Story Map con identificación del Producto Mínimo Viable - MVP: Épicas priorizadas con estimación de esfuerzo y asignación de valor
Estimación de Tiempo y Costo
The Go Product Roadmap: Este artefacto también puede ser conocido como el plan de releases.
Historias de Usuario con Criterios de Aceptación: se seleccionaron algunas épicas de forma aleatoria y se les escribieron las historias de usuario, simulando un refinamiento.

Espero estos ejemplos les sean de utilidad,

Saludos ágiles

Jorge Abad.

jueves, octubre 08, 2020

Cálculo de Costo y Tiempo de un Proyecto Usando Épicas y un User Story Map

Referencias

Te recomiendo revisar previamente este ejemplo: Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor (clic aquí)

jueves, julio 02, 2020

Un ejemplo sobre: Épicas, MVP, Historias de Usuario, Agregar Valor Incrementalmente y Agregar Valor

Hola a todos

Debido a recurrentes conversaciones y aclaraciones sobre:

Épicas
Historias de Usuario
MVP (Minimun Viable Product o Producto Mínimo Viable)
Agregar Valor
Agregar Valor Incrementalmente
y Scrum

Voy a desarrollar un ejemplo hasta llegar a la planeación de los primeros tres sprints de un producto de solicitud de crédito, esto con el fin de ilustrar varios conceptos.

Comencemos.

Paso 1. Durante el Inception (9) se creó el siguiente User Story Map

Paso 2. Durante el Inception (9) se realiza la estimación de cada release

Se realiza una estimación de alto nivel y se identifica que aproximadamente (7) cada release tomará:

Release 1 - MVP	7 sprints
Release 2	6 sprints
Release 3	6 sprints

Paso 3. Inception - Durante el Inception se identifican las historias de usuario de los siguientes tres sprints (11)

El equipo técnico luego de tener conversaciones con el PO y los Stakeholders estima que las dos primeras historias épicas son suficiente para los primeros tres sprints, quedando identificadas de la siguiente manera:

Release	Épica	Historia de Usuario
Release 1 - MVP	Formato de solicitud básico	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados
	Validar referencia personales	HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Validación centrales de riesgo 1 y 2	Pendientes por definir (10)
	Calificación	Pendientes por definir (10)
	Creación del crédito	Pendientes por definir (10)
	Desembolso a cuenta propia	Pendientes por definir (10)

Release	Sprint	Historia de Usuario
Release 1 - MVP	Sprint 1	HU1 - Datos personales HU2 - Datos familiares HU3 - Datos laborales HU4 - Referencias laborales HU15-Información del cónyuge
	Sprint 2	HU5 - Ingresos HU6 - Egresos HU7 - Bienes HU8 - Deudas HU9 - Tipo de crédito solicitado HU16 - Declaración de salud
	Sprint 3	HU10 - Validación rápida contra base de datos interna HU11 - Validación de preaprobados HU12 - Validar veracidad de referencias contra base de datos interna HU13 - Registro de llamadas a referencias dudosas HU14 - Escalar problemas a superior
	Sprint 4	Pendientes por definir (10)
	Sprint 5	Pendientes por definir (10)
	Sprint 6	Pendientes por definir (10)
	Sprint 7	Pendientes por definir (10)

Ya que llegaste hasta acá, déjame compartirte cuál es mi punto

Realmente no es un punto, son varios, veamos:

Observa que no existe relación entre la cantidad de épicas y la cantidad de sprints.
El sprint backlog identificado se mantuvo entre 5 historias aproximadamente, la experiencia de varios autores sugiere que un buen Sprint Backlog debería tener entre 6 - 10 historias de usuario de similar tamaño (en la medida de lo posible), menos no es recomendable.
El formulario o Épica de Solicitud de Crédito, NO ES UNA HISTORIA DE USUARIO, es una épica y el principal criterio es que un equipo se demorará más de un sprint en terminarlo (rompiendo los criterios de INVEST y CCC), por lo tanto, para ver progreso de VALOR INCREMENTAL, lo partimos en historias de usuario que nos permiten ver progreso en la construcción del formulario.
Obvio, cuando se termine el sprint 1 tal vez tengamos las historias: HU1 - Datos personales, HU2 - Datos familiares, HU3 - Datos laborales, HU4 - Referencias laborales, HU5 - Ingresos; pero no tendremos nada que liberar a producción, lo que si es cierto, es que habrá sofware funcionando potencialmente liberable (o en producción apagado) esperando el resto del MVP para ser liberado cuando el PO dé la orden.
El formulario o Épica de Solicitud de Crédito se terminará de construir aproxidamente en la mitad del sprint 3, como PO, ¿no prefieres ir observando progreso cada sprint? o ¿deseas luego de mes y medio (suponiendo que cada sprint fuera de 2 semanas) de estar comiendote las uñas, pensando que el equipo no te muestra avance? la verdad, creo que es mejor ver valor incremental; los PO con los que he trabajado luego de conocer el mundo del VALOR INCREMENTAL, de las pequeñas entregas, no desean volverse al anterior. Te invito a leer estos dos post respecto a la necesidad de tener historias de usuario pequeñas para poder observar progreso:

Cuando se termine el formulario o Épica de Solicitud de Crédito, se le agregará VALOR al producto, pero este valor no se hará tangible hasta después que se ponga en producción. Recuerda: "el Software solo adquiere valor cuando es usado".
Se dice aproximadamente, pues realmente no se sabe a ciencia cierta cuanto tiempo va a demorar en construirse cada release, lo que si sabemos es que vamos a estar priorizando por valor y tan pronto tengamos algo que genere impacto lo liberaremos.
Realmente se Agregará o Generará VALOR cuando salga a producción el MVP, antes solo se genera satisfacción al PO y a los stakeholders, pues estos ven progreso. Recuerda: "el Software solo adquiere valor cuando es usado".
El Inception consta de más actividades (ver un ejemplo acá -http://www.lecciones-aprendidas.info/2017/08/ejemplos-de-artefactos-agiles-inception.html )
Estas historias de usuario no se escriben o refinan en el Inception, se detallarán más adelante. Se realiza en la vista del Discovery del Product Owner (ver http://www.lecciones-aprendidas.info/2020/03/product-owners-views-explicacion.html), además como estamos en un mundo tan volátil, es probable que tengan cambios en el futuro y sean fácilmente obsoletas. Recuerda, en ágil nos enfocamos mucho en no hacer activdades de desperdicio, o como dice el principio 10 del Manifiesto Ágil (clic aquí): "La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial."
Es altamente recomendado que como resultado de un Inception, se tengan las historias de usuario de los primeros tres sprints refinadas o preparadas para ser desarrolladas. Estas historias podrán tener formato o modo de representación que desees (ver http://www.lecciones-aprendidas.info/2019/05/modos-de-representacion-de-las-historias-de-usuario.html )
En caso que para el PO y los stakeholders sea de valor liberar la Épica-Solicitud de Crédito (tal vez, porque les ahorra muchos procesos manuales), aunque esta no sea el MVP, pueden hacerlo, (¿quién se los impide?), y para acabar de ajustar no es necesario esperar al review del tercer sprint para ponerla activa en producción, perfectamente pueden liberarla en la mitad, no es necesario que esperen (no te lo imaginabas, ¿cierto 🤯? ). La referencia a esta práctica de liberación continua en la guía de Scrum (ver acá), es la siguiente: "(Scrum se ha usado para) Liberar productos y mejoras tantas veces como sea posible durante el día".

Espero te sirva este post para el desarrollo tu producto y puedas aprovechar los beneficios del desarrollo incremental.

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad

miércoles, octubre 31, 2018

Fail - Contratar el MVP con Alcance, Tiempo y Costo Fijo

Cada vez me encuentro más con empresas que dicen:

"Ok entendí qué es un #MVP, entonces constrúyanlo con un contrato a alcance, tiempo y costo fijo"

Predecir alcance, tiempo y costo en escenarios de #VUCA es imposible.

---

¿Que modelo recomiendo usar ?

Para todo tipo de proyecto o producto de desarrollo de software recomiendo, en primer lugar no ceder frente a las presiones del cliente (no es profesional, y realmente a el no le conviene aunque así lo crea), luego de ahí hacer cualquiera de los siguientes contratos:

1. Tiempo y materiales
2. Tiempo y materiales con tiempo fijo
3. Tiempo y materiales con costo fijo
y por último
4. Estimación por sprint o estimación por trabajo mensual (implica bajo riesgo con orden de trabajo mensual)
5. Tiempo y materiales con alcance fijo (no recomiendo pues implica levantamiento y perdemos flexibilidad... cosa que nos brinda el enfoque agile)
¿y ustedes que han hecho en estos casos? ¿que recomiendan?

miércoles, julio 25, 2018

[Preguntas y Respuestas] ¿En mi producto no hay un MVP de quien es la responsabilidad de que este exista?

Hola a todos

Hace poco publiqué en LinkedIn una pregunta (ver links al final):

"¿Soy #ScrumMaster y no hay un MVP (producto mínimo viable) definido para el producto de quien es la responsabilidad de que este exista?

Del SM, muchas veces el PO es la primera vez que ejerce el rol, y de pronto ni ha sido capacitado, mi deber como sm es ser el Coach del PO y enseñarle a como ser un gran PO, priorizar el product Backlog por valor, encontar el MVP, escribir historias de usuario etc. "

en su clarificación se compartieron varios aprendizajes que han servido

El Scrum Master es el experto en el marco
El Scrum Master esel Agile Coach del Product Owner y del Equipo
El Scrum Master como experto y coach si observa que su Product Owner no entiende ciertos conceptos, lo formará y apoyará hasta que este se haga responsable de los mismos
La guía oficial -scrumguides.org - presenta al Scrum Master a estar al servicio de Product Owner de la siguiente forma:

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible;
Encontrar técnicas para gestionar la Lista de Producto de manera efectiva;
Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Lista de Producto claros y concisos;
Entender la planificación del producto en un entorno empírico;
Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
Entender y practicar la agilidad; y,
Facilitar los eventos de Scrum según se requiera o necesite

Se invitaba a que los Scrum Masters fueran proactivos en vez de esperar que sus Product Owners vengan preparados y listos con todas las técnicas de facilitación y gestión de producto, los acompañaran y formaran hasta que estos fueran Product Owners Grandiosos (recomiendo este post Guía Supernumeraria para un Dueño de Producto Virtuoso - de Lucho Salazar- clic aquí-)
Este post tambien aplica para la pregunta: ¿En mi producto no hay un Plan de Relaeases de quien es la responsabilidad de que este exista?
Es probable que un producto con salidas frecuentes a producción, cada fin de sprint o varias veces durante el sprint, no requiera un plan de releases,

Bienvenido el Feedback

Saludos Ágiles
Jorge Abad

Link de la conversación en Linked in: https://www.linkedin.com/feed/update/urn:li:activity:6412122454839357440

Link de la conversación en Facebook: https://www.facebook.com/jorge.abad/posts/10160545277655788

domingo, enero 14, 2018

Encontrando el MVP con un Roadmap y el Mapa de Afinidad

Hola a todos

Realizando talleres Producto Mínimo Viable - MVP (Minimun Viable Product), he encontrado que para cierto tipo de equipos les da dificultad emplear la técnica del User Story Map de Jeff Patton, para estos equipos he ideado esta técnica basada en el Roadmap y el Mapa de Afinidad, espero les guste y también les sirva con sus equipos.

Saludos Ágiles

Bienvenido el Feedback
Jorge H. Abad L.

Encontrando el MVP con un Roadmap y Mapa de Afinidad from Jorge Hernán Abad Londoño

sábado, enero 13, 2018

Unos tips y preguntas poderosas para encontrar el MVP

A continuación a compartir algunos tips y preguntas que hemos encontrado con varios Agile Coaches (Lucho Salazar @LuchoSalazarC, Pablo Mejía @pmejia73) que te pueden ayudar a en

Siempre busque paretos, cual es el 20% del sistema que generaría un 80% de valor o impacto en el negocio.
Identifique cuál o cuáles son los criterios claves para la selección del MVP (4)
¿Si me voy del proyecto qué es lo mínimo que quiero dejarle?
si es una migración o reconstrucción de un sistema

¿cuales son las funcionalidades que registran más uso del sistema?
¿agrega valor volver a construir lo que se dejó de usar o lo que nunca se ha usado?

Imagine el dinero es suyo, o que le darán un premio por invertir la menor cantidad de dinero
¿Cual es la mínima funcionalidad que comienza a resolver el problema de negocio?
¿Y si le recortaran el dinero al proyecto a la mitad?¿y la mitad de esa mitad?

¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de dinero?

¿Y si le recortaran el tiempo al proyecto a la mitad?¿y la mitad de esa mitad?

¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de tiempo?

Hasta acá este pequeño compartir
Bienvenido el feedback

Saludos Ágiles
Jorge Abad

Notas, Referencias, Comentarios, Aclaraciones

Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html
Criterios de Selección del Mínimo Producto Viable - http://www.lecciones-aprendidas.info/2018/01/criterios-de-seleccion-del-minimo-producto-viable.html

Algunos Criterios o Patrones de Selección del Mínimo Producto Viable

Muchas veces elegir o encontrar el Mínimo Producto Viable (MVP - Minimun Viable Product) no es un ejercicio fácil para el Dueño del Producto y sus interesados (o stakeholders), en ocasiones se deben revisar criterios de negocio, criterios técnicos, o tal vez se requiera de un análisis multi-objetivo que ayude a determinar cual es el valor que se quiere entregar en la primera versión del producto. A continuación les comparto algunos criterios:

Validar una hipótesis de negocio con el mercado. Es la común para las startups, buscando obtener el máximo aprendizaje.
Validar un pedazo riesgoso de una solución
Primero lo más barato
Lo que menos cuesta
Lo que implique el mayor ahorro en el proceso
Primero una una tecnología específica y luego el resto, ejemplo primero construir la solución para Android y luego para iPhone
Automatizar una parte del proceso y luego el resto
Lo que me comience a resolver el problema de negocio más rápidamente
Primero ciertos roles claves y luego otros
Las reglas de negocio de mayor impacto primero y luego las otras
Primero el camino feliz y luego las excepciones
Construir para una segmentación de datos y luego para los otros, ejemplos: compradores frecuentes y luego compradores de ciertos productos.
La operación del sistema que me permita obtener mayor valor
(Si el criterio es performance) Primero construir la solución con desempeño normal y luego llevarla al alto desempeño
Eliminando el riesgo regulatorio o minimizando su impacto
Minimizar multas o sanciones
Lo que más ingresos me produzca
Lo que mínimo que me permita igualar uno o varios servicios de mi competencia.
En una migración: lo más usado y luego lo menos

Hasta acá este pequeño compartir, si encuentran más criterios no dudes en hacer su aporte en la zona de comentarios, los citaré respectivamente.

Bienvenido el feedback

Saludos Ágiles
Jorge Abad

Notas, Referencias, Comentarios, Aclaraciones

Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html

lunes, octubre 31, 2016

Sí, Mínimo Producto Viable ¿Pero en qué contexto?

La definición de Producto Mínimo Viable es muy conocida tanto en el mundo del agilismo como en el mundo del emprendimiento y es allí donde quiero poner foco el día hoy, pues para ambos significan cosas completamente diferentes. En palabras de Eric Ries, el Gurú de Lean Startup:

Minimum Viable Product; is a product with just enough features to gather validated learning about the product and its continued development(1)(2)

Y en palabras de Martín Salias y Martín Alaimo, referentes en la comunidad ágil latinoamericana:

Minimum Viable Product ( MVP) es la versión mínima de un producto, tal que nos permita recolectar la mayor cantidad de información de nuestro mercado y clientes con el menor esfuerzo posible.(3)

Y esta definición es muy acorde con la imagen del artículo, pues existe una clara diferencia entre ambas y es el momento del tiempo.

Miremos el ejemplo de Dropbox ellos crearon un vídeo con lo que sería Dropbox - https://youtu.be/7QmCUDHpNzE - , no lo habían implementado, y lo publicaron en Youtube para facilitar su acceso, necesitaban validar su idea - La primera definición de MVP de este post, y primer momento del tiempo - para atraer usuarios e inversores, la propuesta de valor: “funcionaba y era simple” y pasaron de 5.000 a 75.000 personas en la lista de espera para su beta una vez se hizo el vídeo, considerando que adicionalmente crearon Votebox, un espacio en su web donde los usuarios iban dando ideas de funcionalidades que incluir. Luego en otro momento del tiempo para Drobpox determinaron cual era la versión mínima de producto para su version beta, o sea la versión que iba a funcionar inicialmente en el mercado - la segunda definición de MVP de este post y el segundo momento del tiempo -.

Por tanto, es importante que identifiquemos en que momento del tiempo estamos, si estamos en la definición de producto buscamos aprendizaje validado y clientes, o si es en el segundo momento, con producto y clientes definidos, y es requerida una versión mínima de lo que vamos a entregar.

Aunque es de aclarar, que no dudo que hayan contextos en que lleguen a ser lo el mismo producto ambos MVP, pero observo que desde el punto de vista del desarrollo a la medida por lo general estamos en el segundo momento.

Saludos ágiles

Jorge Abad

Referencias Aclaraciones, Notas y Comentarios

https://en.wikipedia.org/wiki/Minimum_viable_product
https://es.wikipedia.org/wiki/Producto_viable_m%C3%ADnimo
"Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos (Spanish Edition)"

jueves, septiembre 22, 2016

Algunos tweets sobre Agilidad y Scrum

"la gente no va a extrañar lo que no tiene" @camilohenao1 #lean #agile #ProductOwner #scrum #mvp
— Jorge Hernán Abad L. (@jorge_abad) 22 de septiembre de 2016

"Los equipos son inmutables, cada vez que alguien entra o sale es un equipo nuevo, no uno modificado" @richardadalton #Agile #scrum #Genial pic.twitter.com/V1jz9ohaJw
— Jorge Hernán Abad L. (@jorge_abad) 22 de septiembre de 2016

#PreguntaPoderosa de @pmejia7 sobre #MVP

"¿Cómo puedo resolver progresivamente el problema de negocio del #ProductOwner?" #agile
— Jorge Hernán Abad L. (@jorge_abad) 21 de septiembre de 2016

El #ScrumMaster es el responsable de la fluencia de su equipo, de disminuir y eliminar la fricción Sprint tras Sprint #Agile #Scrum
— Jorge Hernán Abad L. (@jorge_abad) 21 de septiembre de 2016

Cambio en preguntas del #daily con @cafegifo

Qué logre ayer
Qué voy a lograr hoy
Qué me lo está impidiendo pic.twitter.com/DmrpjAfffP
— Jorge Hernán Abad L. (@jorge_abad) 17 de septiembre de 2016