Master Class: Desde la Visión hasta las Historias de usuario

Enlace a Mural - Clic aquí -

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

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

1. A Guide to the Project Management Body of Knowledge PMBOK® GUIDE. Seventh Edition
2. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum? (clic aquí)
3. ¿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?) 
4. Esto lo explico ampliamente en el libro: Nuevas Aguas, Nuevos Navíos, Nuevos Navegantes: Business Agility con notas sobre Transformación Digital (clic)

De Colección: De la Idea hasta las Historias de Usuario del Sprint Backlog - Un Ejemplo Completo

Hola a todos

Les comparto un ejemplo que desarrollé desde la Idea hasta el Sprint backlog de los primeros tres sprints. Los artefactos elaborados son;

• Elevator Pitch (Visión)
• Product Vision Board
• Ideación de posibles funcionalidades
• Asignación del valor usando la serie de Fibonacci modificada. 
• Asignación del esfuerzo usando la serie de Fibonacci modificada
• Uso del Modelo Kano de priorización para identificación de funcionalidades clave
• Elaboración del User Story Map
• Visión End-2-End
• Cálculo de la relacion Valor / Duración de cada funcionalidad
• Priorización de funcionalidades usando MoSCoW
• Identificacion del Producto Minimo Viable (MVP)
• Plan de Releases
• Roadmap del producto
• Explicacion del cálculo del tiempo y costo
• Product Backlog vertical, donde cada realese esta priorizado por la relación Valor/Duración
• División de historias de usuario de las primeras tres funcionalidades o épicas
• Identificación de los primeros tres sprints donde la velocidad promedio del equipo es aproximadamente 20 puntos de historia por sprint.

La imagen la pueden descargar en alta resolución de:

• formato png - clic aquí 
• formato pdf - clic aquí

Actualización 2022-11-10


Enlace a Mural - Clic aquí -

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.

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í)

Mi Encuentro con NoProjects - Una Cultura de Valor Continuo

Hola a todos


Desde que comencé a caminar en el mundo ágil vi como poco a poco el concepto de proyecto de software iba perdiendo fuerza en el mundo corporativo y comenzaba a tomar fuerza el concepto de producto de software (a continuación un tweet de hace unos años)

Veo cada vez más en la industria del software, el concepto de Producto mucho más fuerte que Proyecto.

— Jorge Hernán Abad L. (@jorge_abad) November 15, 2017

Aclarando sobre Proyectos y Productos

Pero para entender mejor en que nos estamos metiendo, comencemos por las definiciones:

Proyecto: "Es un esfuerzo temporal realizado para crear un producto, servicio o resultado único". (1)

La anterior es la definición técnicamente aceptada y elaborada por el PMI  -Project Management Institute . www.pmi.org, pero para producto la definición no es fácil de hallar, acá comparto algunas definiciones que tienen sentido en el propósito de este post:

Producto: Cosa producida ( tipica definición de la RAE)(2)
Producto: Un producto es una cosa o un objeto producido o fabricado, algo material que se elabora de manera natural o industrial mediante un proceso, para el consumo o utilidad de los individuos.(3)
Producto: un producto es un objeto o sistema disponible para uso del consumidor; Es todo lo que se puede ofrecer a un mercado para satisfacer el deseo o la necesidad de un cliente. (4)
Producto:

• algo que es fabricado, cultivado para ser vendido, usualmente es algo que es producido por un proceso

• Un servicio que los clientes pueden comprar de una organización financiera para invertir o ahorrar dinero

• algo que está disponible para la venta(5)

Producto: Del latín productus, se conoce como producto a aquello que ha sido fabricado (es decir, producido). Esta definición del término es bastante amplia y permite que objetos muy diversos se engloben dentro del concepto genérico de producto. De esta manera, una mesa, un libro y una computadora, por ejemplo, son productos. (6)

Producto: Cualquier bien material, servicio o idea que posee un valor para el consumidor o usuario y sea susceptible de satisfacer una necesidad.(7)

Podría entonces basado en lo anterior entender que un producto es elaborado y es de valor para un usuario o consumidor.

Basado en las anteriores definiciones se entiende que los proyectos de software:

• son finitos
• tienen alcance, tiempo, y costo fijos (importante ver la nota 12)
• tienen recursos definidos (importante ver la nota 12)

Implicando por lo tanto:

• se desarrollan en ambientes de certidumbre
• su seguimiento y éxito esta basado en la gestión del alcance, tiempo y costo incurrido.
• la administración de estos esté enfocada en la administración y optimización de los recursos (insumos, tiempo de las personas) y no en el valor generado.
• su enfoque de alcance definido, genere definición previa del alcance, adicionalmente que su adaptabilidad sea lenta y requiera procesos adicionales de control de cambios.

Generando algunas veces que estos:

• cuenten con bajo involucramiento del negocio
• cumplan el alcance pero no generen valor
• usen sus recursos definidos pero no generen valor.

Mientras, los productos de software

• nacen
• no tienen una fecha de finalización prevista
• pueden ser construidos por uno o varios proyectos, o por un enfoque diferente
• pueden construirse en escenarios de certidumbre como de Altísima Incertidumbre
• pueden o no evolucionar
• morirá el día que deje de ser rentable su uso o existencia
• el alcance es un medio para generar valor
• pueden alcanzar valor antes o después de lo planeado
• están radicalmente enfocados en la generación de valor (o ¿Quién quiere hacer un producto que nadie va a usar?), por lo tanto validan si generan valor o no.
• Su éxito no se mide en cumplimiento o la gestión optimizada de recursos sino en el valor generado.
• Requieren de involucramiento del negocio

Algunas veces es posible no se construya el producto correcto, pero esto se puede solucionar con validaciones tempranas con Productos Mínimos Viables - o MVP por sus siglas en inglés-  propuesta por Lean Starutp, y liberaciones o releases frecuentes que permitan retroalimentación de los usuarios y el mercado.

Mi encuentro con #noprojects

Justo en esa búsqueda de entender más sobre:

• productos
• cadenas de valor (value streams)
• épicas de negocio (como las llamaría SAFe (8))
• o iniciativas

 y como su gestión se diferencia de la gestión de proyectos, (la actualmente no aplica para el mundo del desarrollo de software(9)), me encontré hace unos meses con #noprojects - https://noprojects.org -  y el minilibro publicado en infoq.com - #noprojects - A Culture of Continuous Value (clic aquí) de Evan Leybourn y Shane Hastie, que explica una cultura orientada a la gestión del valor y como podemos tener éxito en ese enfoque.

A continuación comparto dos imágenes que he traducido, y que son bastante útiles para entender este paradigma.

Referencia : https://twitter.com/rkasper/status/1032251628143882240

#noprojects

Triangulo de #noprojects (10)

Triángulo de #noprojects traducido

Queda entonces la tarea de quedarse con estas imágenes o ir leerse el libro.

Les dejo con esta frase de Mark Twain (o al menos se la atribuyen a él)

Saludos ágiles

Jorge Abad

Notas, Comentarios, Referencias y Observaciones

1. “It's a temporary endeavor undertaken to create a unique product, service or result.”.https://www.pmi.org/about/learn-about-pmi/what-is-project-management
2. https://dle.rae.es/?id=UH9P99t
3. https://www.significados.com/producto/
4. Traducido de wikipedia - https://en.wikipedia.org/wiki/Product_(business)
5. https://dictionary.cambridge.org/es/diccionario/ingles/product
6. https://definicion.de/producto/
7. http://www.diclib.com/cgi-bin/d.cgi#.XWNHs-j0nIU#ixzz5xfhGQ3il
8. https://www.scaledagileframework.com/epic/
9. Este tópico no lo resolveré acá, pues es justo la explicación de por qué hoy los métodos ágiles son más exitosos que los tradicionales y hay cientos de post en ingles y español sobre esto.
10. Referencia https://twitter.com/fbnkss/status/1133762339373813760
11. Adicionalmente el ciclo de vida de proyectos y producto es distinta
• proyecto = inicio, organización y preparación, ejecución y cierre
• producto = introducción, crecimiento, madurez y retiro
12. Felipe García compañero de la Ágiles Colombia me hacia la precisión que los proyectos tienen: alcance, costo, tiempo, riesgos, recursos y calidad, en total seis restricciones, cosa cierta, pero los esquemas de contratación tradicionales solo manejan estas tres variables (alcance, tiempo y costo) y penalizan al proveedor diciendo: "¡usted debe hacerse cargo de los recursos, la calidad y los riesgos, para eso los contratamos!",  - ¡hágame el bendito favor, que descaro!(clic aquí para regresar)

La transformación digital requiere de la transformación ágil (resumen)

Imagen de la película Minority Report

Hola a todos

Llevo varios días tratando de escribir este artículo, sustentarlo con una buena cantidad de referencias reconocidas y entre más escribo más me convenzo que se parece más a un ensayo que a un pequeño artículo de fácil y corta lectura.

Pero mientras sale el "casi ensayo",  quisiera dejar evidencia de este importante asunto sobre el que quiero poner foco, pues he observado que muchas empresas quieren hacer su Transformación Digital sin a la par trabajar en su Transformación Ágil, muy seguramente la empresa no esta lista para el cambio (que no es opcional por estos días de cambio acelerado, discruptivo o VUCA) pero quiere empezar "para ayer" - como decimos en Colombia- con este cambio, que ya le esta quitando clientes o pronto se los quitará. Lo simpático es que cuando comienzan con este tipo de proyectos:

• de IoT
• en la Nube
• de BigData
• con IA
• robotics
• customer centric
• etc, 

Sus personas, cultura, mindset y procesos, aun no están listos para gestionarlos- es decir, no tienen el mindset ágil- , correspondiendo al mindset de la gestión predictiva, en el cual toda su cultura esta ubicada - y que es de reconocer, les ha dado éxito hasta el momento- generando problemas como:

• creer que es un proyecto tradicional 
• no verlo como un experimento que puede ser exitoso o fallido
• no considerar hipótesis a ser validadas
• no medir el resultado esperado
• no priorizar alcance por valor
• contratar la construcción con los parámetros de cascada
• quieren presupuesto fijo
• el alcance es fijo con requerimientos detallados
• el tiempo para la ejecución es fijo
• utilizar métricas de cascada para proyectos ágiles
• al proyecto ágil se le asignan ANS o SLA de cascada (¿¡en serio!?)
• las personas no tienen tiempo para ejecutar los roles con el involucramiento que se requiere (ej: Product Owner)
• quieren en la primera versión todo el sistema y no comprenden que es un Producto Mínimo Viable (MVP - Minumum Viable Product)
• no se acompañan de gente que tiene experiencia gestionando este tipo de proyectos
• al gerente de proyecto que no tiene experiencia, pero que hizo un "curso de Scrum Master" le entregan la misión de sacar "el proyecto" adelante.
• los procesos de aprobación de "cualquier cosa" requiere demasiadas aprobaciones y comités
• entre muchas otras cosas

Haciendo que la iniciativa "Digital" muera sin haber nacido.

Es aquí donde veo que es necesario el asesoramiento, el acompañamiento y crear las condiciones para el éxito o para el fracaso (pero que este fracaso o fallo sea rápido).

Estimad@ gerente:

"El tiempo sigue avanzando y usted sigue esperando que el proceso organizacional apruebe su proyecto digital, de forma que salga a buscar a su mejor proveedor en cascada, a decirle que haga ágil, pero con las condiciones de cascada, luego entre a negociar el alcance y las estimaciones - proceso interminable y desgastante -, perdiendo ROI y aumentando el costo del retraso de forma significativa, ¿En serio, va a seguir perdiendo mercado y costo de oportunidad, y permitiéndole a su competencia que le tome ventaja de su proceso lento? o ¿va a generar las condiciones de éxito para este piloto, que va a ser la puerta de entrada a esta nueva forma de trabajo? La decisión está en sus manos, nos vemos la próxima reunión"

Hasta áca este corto compartir

Saludos Ágiles

Jorge Abad

Algunas Referencias

1. Is Digital a Priority for Your Industry?. https://www.gartner.com/smarterwithgartner/is-digital-a-priority-for-your-industry/
2. El mundo ya cambió. https://www.youtube.com/watch?v=pPzS6gza9KQ
3. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
4. Economía Colaborativa - https://es.wikipedia.org/wiki/Consumo_colaborativo
5. Transformación digital, reto de empresas líderes globales - https://www.portafolio.co/negocios/empresas/transformacion-digital-reto-de-empresas-lideres-globales-524943
6. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?- http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html
7. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. http://www.lecciones-aprendidas.info/2017/08/como-elegir-el-proyecto-piloto.html

De Colección: Algunas frases que sirven para el desarrollo de productos

"No hay nada más inutil que hacer eficientemente aquello que no debería haberse hecho en absoluto" [Peter Drucker]

— Lucho Salazar (@luchosalazarc) November 12, 2018

---

"La perfección no se alcanza cuando no hay nada más que añadir, sino cuando no hay nada más que quitar" Antoine de Saint-Exupéry

— Jorge Hernán Abad L. (@jorge_abad) November 13, 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?

[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

[Scrum] Una queja común en algunos Scrum Masters: Mi Product Owner no es bueno

Hola a todos

En sesiones de mejora con Scrum Masters (SM) con frecuencia me encuentro con las siguientes quejas acerca del Product Owner (PO):

• no tiene tiempo para el equipo
• no escribe bien las historias de usuario 
• no está priorizando el product backlog
• no hay un plan de releases
• no se tiene un Producto Mínimo Viable (MVP).
• no se tiene una herramienta de seguimiento de releases como un Burn Up Release (por ejemplo)
• entre otras preocupaciones

Es allí donde les solicito que me compartan que saben del rol del Scrum Master y me responden palabras más palabras menos, lo que que está a continuación (-que se interpreta en la guía oficial de Scrum- ):

Luego de esto, comienzo una ronda de preguntas y respuestas de más o menos este estilo:

• ¿Quién es responsable de que se tengan buenas historias de usuario, el P.O., el Team o el SM? 
• Rpta/. Es el SM como experto del marco es el encargado de garantizar que el equipo tenga los ítems de backlog adecuados para trabajar, y es su deber como coach del PO de enseñarle y verificar las historias de usuario para que estas cumplan con un estándar mínimo de calidad (las tres CCC e INVEST). ( leer tambiém :El Product Owner "NO" Necesariamente Escribe las Historias de Usuario o Ítems de Backlog - clic aquí)
• ¿Quién es el responsable de que no se tenga un buen Product Backlog, Plan de Releases, Producto Mínimo Viable (MVP), un Burn Up Release?
• Rpta/. Pareciera que inicialmente es el PO, pero similar al punto anterior, el SM como coach del PO debe enseñarle y ayudarle a mantener los artefactos de scrum, hasta que estos sean los adecuados para construir un producto exitoso.
• ¿y que podríamos hacer con respecto a la falta de tiempo del PO?
• Rpta./. El SM debe buscar como lograr más tiempo de la organización para el PO - al menos medio tiempo-, o encontar la forma de que esto se resuelva con otro PO, o un PO Proxy, pero recordemos que el SM es un agente de cambio para la organización y es responsable de que la organización comprenda como funciona Scrum y los requisitos para que sea exitoso.

Es importante comprender que el Scrum Master es el responsable de Framework de Scrum, debe trabajar por su funcionamiento exitoso, que debe convertirse en Responsable en vez de Víctima,  haciendo que las cosas pasen, si su PO, equipo o algo no funciona pues debe moverse para que las cosas sucedan.

Hasta acá este corto compartir

Saludos ágiles

Jorge Abad

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

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

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

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

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

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 

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

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