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

[Scrum] El Valioso "NO" del Product Owner

Hola a todos

Según la Guía de Scrum(1), el Dueño de Producto o Product Owner (PO). lo define como:

• El responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo (2)
• Es la única persona responsable de gestionar la Lista del Producto (Product Backlog)
• Expresa claramente los elementos de la Lista del Producto;
• Ordena los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible;
• Optimiza el valor del trabajo que el Equipo de Desarrollo realiza;
• Asegura que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación;
• Asegura que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.
• Es una única persona, no un comité. El Dueño de Producto podría representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiarla prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.
• Para que  pueda hacer bien su trabajo, toda la organización debe respetar sus decisiones
• Durante el Sprint el alcance puede clarificarse y renegociarse entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
• Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint
• El Dueño de Producto hace seguimiento de este trabajo restante total al menos en cada revisión de Sprint.
• Decide si libera o no el incremento

Lo anterior podríamos parafrasearlo un poco como

• Es alguien con empoderamiento y capacidad de decisión sobre el producto
• Es el responsable del  ROI -return on investment-
• Es voz del cliente ante el equipo
• Define, refina y prioriza el Product Backlog
• Esta disponible para el equipo
• Hace seguimiento del avance y la construcción del producto
• Decide cuando cancelar el sprint 
• Decide cuando salir a producción.

Pero este post se enfoca en que le corresponde Product Owner respecto al producto y al alcance decir

• qué se hace 
• y qué se posterga para próximas versiones (un NO PARCIAL, o sea hoy te digo que NO, mañana tal vez lo hagamos)
• y qué definitivamente NO SE HACE

Esto se alinea perfectamente con el décimo principio ágil (3) en donde se refleja el pensamiento Lean:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo para el mundo del software

Nos esforzaremos al máximo en NO crear ni software, ni alcance, ni trabajo de desperdicio o que no sea necesario (o hacer algo que terminará siendo inútil)

Por lo tanto, es clave que el Product Owner aprenda de a DECIR NO, y al negociar con sus interesados para ciertas funcionalidades les dirá:

• eso NO se puede hacer aún, 
• es que necesitamos generar valor con lo mínimo posible
• eso va para otra versión o release
• eso aun NO tiene prioridad
• eso NO agrega valor
• eso definitivamente NO se hará

Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de alcance requerido y de esa manera se alcance prontamente el máximo ROI.

Cerrando

Un buen PO sabe:

• Que cada sprint tiene software funcionando y potencialmente liberable (punto a favor del PO y de la organización)
• Pero que si se permite decir que SÍ todas las funcionalidades que se le ocurran tanto a el como al negocio, NUNCA va a salir a producción, pues a mayor alcance más cantidad de sprints se van a requerir para salir a producción, y a mayor tiempo menor ROI (un peligroso circulo vicioso)
• Que si se demora mucho en salir a producción el impacto en el ROI y en el negocio puede ser nefasto dado lo disruptivo y cambiante del entorno actual.

Recuerdo mucho una frase que le escuche a Ángel Medinilla.

NUESTRO TRABAJO NO ES HACER SOFTWARE, ES HACER LA MENOR CANTIDAD DE SOFTWARE POSIBLE QUE MAXIMICE EL VALOR DE NEGOCIO DE NUESTROS CLIENTES.

Por lo tanto cuando vayas a escoger a un PO, cerciórate de que el o ella tienen claro los siguientes aspectos respecto al alcance:

1. Que conoce que problema de negocio está resolviendo
2. Que tiene claro cual es la solución que debe entregar al negocio para resolver ese problema
3. Que dice NO, pues esta interesad@ en salir a producción lo antes posible
4. Que comprende que el NO es de las mejores formas de controlar el ROI

Bienvenido el Feeback

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Guía de Scrum - clic aquí para descargarla. De igual forma les recomiendo leerla encontrarán elementos que de seguro estaban ocultos a su primer entendimiento (como me pasó a mí).
2. El nombre del Equipo de Desarrollo crea por lo general confusión en la industria del software, se debería llamar Equipo Solucionador
3. Principios ágiles - http://agilemanifesto.org/iso/es/principles.html
4. Este post está altamente relacionado con: La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?

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