Mostrando las entradas con la etiqueta valor de negocio. Mostrar todas las entradas
Mostrando las entradas con la etiqueta valor de negocio. Mostrar todas las entradas

domingo, agosto 25, 2019

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)


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

Resultado de imagen para leer mark twain

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)


viernes, marzo 29, 2019

Entendiendo el Costo del Retraso - Cost of Delay

Hola a todos

Debido a la explicación recurrente que últimamente hago de este concepto, les comparto esta presentación que me ha ayudado bastante en este propósito

Espero les sirva tanto como a mí.






Para la comprensión rápida del ejemplo he extraído algunas unas imágenes
------

------
------
------
------
------
------
------




Saludos ágiles

Jorge Abad









miércoles, agosto 22, 2018

MiniManual para la Gestión por Valor

miércoles, noviembre 16, 2016

Demostrando el Valor Económico de Ejecutar Proyectos de Manera Ágil (Datos Hipotéticos)





Hola a todos


Hace poco alguien me preguntaba como demuestro el valor económico de ejecutar un proyecto en ágil versus uno tradicional. Dado este reto me dí a la tarea de crear este ejemplo hipotético basado en la experiencia de muchos proyectos ejecutados en ágil y en tradicional.

Datos de entrada


  • Proyecto Tradicional (fila 1 a la 10 de la tabla)
    • Tiempo formulado: 10 meses 
    • Costo inicial: $500
    • Tiempo adicional: 10 meses (por lo general los proyectos grandes fallan en grande y toman el doble del tiempo y del costo)
    • Costo adicional : $500 (en color rojo)
    • Valor total proyecto $1.000.
    • Salida a producción: Mes 21
    • Luego de estar el proyecto en producción alguien determinó que el beneficio era por 80 mensual
  • Proyecto Ágil (fila 13 a la 24 de la tabla)
    • Tiempo formulado: 10 meses
    • Costo inicial: $500
    • Tiempo adicional: 4 meses 
    • Costo adicional : $200(en color rojo) (se decide ir un poco más allá del presupuesto para hallar todo el valor de negocio esperado)
    • Valor total proyecto $700
    • Salida a producción Release 1: mes 5. Beneficio producido 30
    • Salida a producción Release 2: mes 8. Beneficio producido y acumulado 50 
    • Salida a producción Release 3: mes 15. Beneficio producido y acumulado 80



Descargar Excel - Clic Aquí


Resultados obtenidos


  • Los indicadores de TIR, Punto de Equilibrio, Ingresos netos en tres años, son mucho más favorables en Ágil que en Tradicional.
  • En ágil se puede generar el mismo impacto con menos valor en producción debido a que el alcance construido en ágil se enfoca en solucionar un problema de forma incremental y no en resolver el problema con un alcance definido al inicio que no se sabe si cumplirá con las expectativas del cliente.


Aclaraciones


Es importante aclarar que he estado en proyectos donde:

  • El valor de negocio se ha encontrado antes del presupuesto y fecha esperada, y para esto es clave un excelente Product Owner orientado por el valor de negocio, el ROI y no por satisfacer un alcance.
  • Y tambien he fallado haciendo ágil en escenarios donde:
    •  el cliente no entendía la metodología 
    • y donde bajo un proyecto con alcance, tiempo y costo fijo y un contrato desventajoso, montamos ágil para mitigar riesgos pero aun así no logramos cerrarlos


En conclusión


  • El éxito de un proyecto ágil esta dado por la estrategia para construcción del producto definida por el Product Owner, (Sin descuidar la excelencia técnica -Sin excelencia técnica no hay agilidad).
  • Aunque este solo fue un ejercicio académico, el resultado de hacer ágil no es solo económico, existen entre otros:


10th State of Agile 2015 - Versionone


Y para cerrar una idea

Ya le hemos dado muchas oportunidades a la forma tradicional - o cascada-  de hacer proyectos de software y hemos perdido, tiempo, dinero, clientes, amigos, trasnochos, ingenieros que han renunciado y familias que se han desintegrado(1), entonces ¿qué te impide hacer tu próximo proyecto de forma ágil?

Aclaraciones


  1. Este dato lo he comprobado en dos ocasiones, en los que el ingeniero desarrollador me compartió que no estuvo por más de un año en su hogar, pues trabajaba de continuo sábados, domingos y festivos  en un proyecto, siendo esta  una de las causas raíces para que se generara el divorcio y por ende la desintegración de su familia.





lunes, abril 11, 2016

La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum?

Hola a todos

Hace unos días discutía con mi estimado amigo Lucho Salazar (@luchosalazarc) sobre la forma de medir el progreso en proyectos ágiles y él me exponía de forma muy radical de acercarse al concepto:


  • Ajá Jorge, como dice el principio del manifiesto: "El software funcionando es la medida principal de progreso"(1), y para de contar, por lo tanto, cuando el Product Owner -PO- diga llegamos al valor de negocio, pues llegamos, antes no. (2)


Wow, reconozco que es una posición muy radical y liberadora, que no dudo que existan escenarios y empresas donde esta se puede aplicar, pero, mientras logramos generar (o encontrar) esos contextos liberadores, para adentrarnos en el concepto que quiero compartir de "zona de valor de negocio" es necesario poner ciertas bases:


Concepto de Valor de Negocio

Es el propósito para el cual fue creado el software que cumple con una o varias necesidades dentro del entorno en que fue creado (3).



La ley de Pareto se Cumple para los Productos de Software

En general solo empleamos entre el 20 y el 50 por ciento del software que creamos (ver la siguiente imagen) (4), por lo que si nos enfocáramos en lo realmente esencial, construiríamos software más rápido, con menos desperdicio y menos funcionalidades a las cuales darle soporte y mantenimiento.

Tomada de SlideShare (5)

Asociado a cada Release debe estar Asociado un Objetivo de Negocio (Capacidad de Negocio) a Cumplir

Como norte para un equipo scrum y aun más para un Product owner (con todos sus stakeholders / interesados) debe estar asociado un objetivo o capacidad transversal y usable a cada liberación del producto (6) , de esta forma cuando el PO esté solicitando funcionalidades que no le aportan al objetivo de negocio, tanto el Team como el Scrum Master puedan cuestionar al PO y evitan construir producto desperdicio. Por lo general, sugiero que se busque una capacidad de negocio a cumplir. Por ejemplo en un sistema de gestión de salas de cine, podríamos tener el siguiente listado de releases:

  • Release Cero, Walking Skeleton o Minimo Producto Viable (MVP): Poder realizar reservas en el sistema telefónicamente con el DI (documento de identidad) y registrar ventas y asignación de sillas en el punto de atención antes de la entrada a las salas de cina.
  • Release 1: Poder realizar las reservas de asientos de salas de cine online. Aun sin pago.
  • Release 2: Poder reservar sillas y comprar de cine via internet
  • Release 3: Poder realizar compra de comida en la tienda del teatro de cine
  • Release 4: Poder acumular y redimir puntos por compra de boletería y consumo de alimentos vendidos por la sala de cine.
  • Release 5: Generar boleteria QR, para ingreso a la sala.
  • etc.


La Zona de Valor de Negocio

La zona de valor de negocio es aquella zona donde creemos que vamos a lograr la capacidad de negocio esperada para un Release, es decir, el equipo puede lograr llegar a esa capacidad:
  • antes del sprint planeado
  • luego del sprint planeado
  • antes de la cantidad de alcance inicialmente estimada
  • con mucha más cantidad alcance de la estimado
El llegar o no en el tiempo y con un alcance identificado dependerá de dos variables:
  • de la velocidad del equipo de generar alcance
  • y de la capacidad de priorización del PO, que haga que el equipo sea productivo y realmente construya producto con valor que le aporte a la necesidad de negocio (7)




Si el PO hace una priorización adecuada, con seguridad llegaremos antes de lo identificado  al valor de negocio esperado, y podamos exponer como dice mi estimado:




Concluyendo

  • Es una buena práctica asociar a los Releases un Objetivo de Negocio (Capacidad de Negocio) a cumplir
  • La zona de valor de negocio puede encontrarse antes o después (tanto en tiempo o como en alcance) del punto estimado al inicio de la planificación del Release
  • La labor del PO puede ayudarnos a encontrar el valor de negocio antes (cumpliendo Pareto)
  • Las discusiones con el estimado Lucho son bastante enriquecedoras y generarn post valiosos ;)

Saludos ágiles

Jorge Abad





Notas, comentarios y referencias

(1) Principio 7 del manifiesto ágil - http://agilemanifesto.org/iso/es/principles.html
(2) En lo posible léase este comentario con acento de Costeño colombiano.
(3) Concepto de elaboración propia y que se encuentra en revisión
(4) Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( https://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf  ) el cual cito textualmente:  "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "
(6) Ojalá el sistema cuente con al menos dos liberaciones y la primera máximo a los seis meses - es una buena práctica imponerse estas metas -.
(7) Productividad mejor que velocidad (ver más aquí)

jueves, enero 09, 2014

Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI

Una de las técnicas que tiene el PMI en el PMBoK para hacer seguimiento del avance del proyectos es la Técnica del Valor Ganado (earned value method  -EVM -) y esta consiste (de una forma muy básica) determinar cuanto alcance hemos logrado con respecto la linea base planteada de costos, o sea:


  • Imaginémonos un proyecto donde planteamos que al 75% del tiempo del proyecto, el valor del alcance logrado era de $100.000.0000, pero si para esa fecha el valor de alcance logrado es de $60.000.000, este último valor corresponde al VALOR GANADO a la fecha..


Lo triste es que si con  estos $60.000.000 y 75% del tiempo del cronograma  el equipo del proyecto se la pasó haciendo:

  • documentación, 
  • prototipos, 
  • tablas paramétricas
  • funcionalidades que no correspondían al core del negocio, 

Lo que hicieron pudo pudo haber sido "muy bueno - funcionar muy bien - ", "muy bonito" pero sino lograron avanzar en lo realmente importante de poco o  nada sirve.  (se cancela el proyecto por alguna razón externa extraña y ese tiempo y dinero invertido no aportaron a su propósito dentro del negocio del cliente)

En las metodologías ágiles nos enfocamos en el valor de negocio, o sea en las funcionalidades que permiten al cliente poner a funcionar su negocio lo antes posible (buscando cumplir siempre con el principio de pareto : 20% de las funcionalidades que aportan al 80% del negocio), documentando solamente lo realmente importante y aplazando funcionalidades:

  • nice to have (seria lindo / chévere que hiciera..)
  • o ya que...
    • "ya que" estamos haciendo esto.. hagamos aquello
  • que solo van a hacer usadas por una persona cada año (o similar) y que se obtienen con query a base de datos
  • Programar casos que en el proceso de negocio nunca se presentarán o que se resuelven diciendo "el sistema no soporta esta funcionalidad." o si se dá el caso miraremos si lo hacemos en una próxima versión.
  • que emulan al excel, perfectamente pudiendo exportar a excel y allí realizar el tratamiento de datos adecuado (he visto muchos sistemas así.. ¿¿¿ustedes no??? )
Por lo tanto VALOR DE NEGOCIO y VALOR según el PMI son distintos.

Y lo que sería más sensato llamar a la técnica del valor ganado(EVM), mejor como "TÉCNICA ALCANCE COMPRADO/LOGRADO", pues quizás ese alcance comprado/logrado sea o no sea de valor para el negocio y los índices de avance SPI, Y CPI servirán para determinar cuanto estamos cumpliendo con el plan, pero no realmente cuanto valor estamos generando para nuestro cliente.


Nota:
Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( http://versionone.com/assets/img/files/ChaosManifesto2013.pdf ) el cual cito textualmente:  "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "


viernes, octubre 25, 2013

Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR -

Hablamos mucho de deuda técnica dentro de agilismo (cosa sana y buena)

pero que tal hablar de la DEUDA DE VALOR!!!

Veamos..


Dentro de las necesidades de un PO - Product Owner, está el conocer el ROI de su producto (cosa que no es siempre fácil de calcular) y el PO cómo líder estratégico del proyecto  (el cual proporciona la visión y el direccionamiento del producto) debe trabajar en convertir el dinero / tiempo /esfuerzo invertido (el cual llamaré costo) del Team Scrum en un Release usable en producción lo antes posible.

No se trata de salir con un Release del sistema el cual no genere valor (ejemplo, un software repleto de administración de tablas maestras y de CRUDs). Se trata de que mientras el sistema no sea usado para el fin para cual fue creado (plasmado en la visión) y no haya un usuario final dándole clic, todo el esfuerzo de ser ágiles no tiene sentido y bajo este enfoque muy poco sirve:

  • ser equipo Scrum 
  • decir que somos Agile
  • predicar el desarrollo orgánico del software
  • cumplir los criterios DONE!!! de todas las historias de usuario
  • tener cero errores, y deuda técnica en cero
  • etc
El software cobra valor cuando es usado por los usuarios, antes no. (lo he leído, me lo han enseñado y lo he predicado, pero cuesta, a ratos plasmar esto cuesta, por múltiples razones y casuísticas - benditas heridas de guerra - )

En esa misma dirección y con la necesidad de tener herramientas para los PO con los que trabajo, pensé en esta tabla y gráficas, las cuales pongo a su consideración; y si les son útiles para mitigar el riesgo de quedarnos con "la papa caliente" de un software que noes liberado, implicando caer en una de las causas de fracaso de Scrum/Agile, habrán cumplido su misión. (si las usan y les sirven, me cuentan)


A continuación las gráficas y su explicación


Proyecto Ágil que no Genera Valor



Características principales:

  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 0% 
  • probablemente cumple con todo lo que pide el PO
  • pero su comportamiento es igual a un proyecto ejecutado bajo el esquema tradicional (Cascada o RUP), solo saliendo a producción al final del proyecto y poniendo en riesgo el presupuesto asignado y la reputación del PO.

Riesgos
  • Alta probabilidad de cancelación del proyecto
  • Alta probabilidad de cambio de PO
  • Alta probabilidad de cambio del SM - Scrum Master - por no hacerle Coach al PO y guiarlo en los principios ágiles (recordemos que Scrum es como las suegras: "Siempre esta señalando tus defectos")

Causas
  • Un Release Plan en el que existe alta dependencia de todas las funcionalidades según el PO,  Lo más seguro es que se argumente que se requiere un solo release para el proyecto.
  • Un mal pareto de software vs funcionalidad, o sea,  el  product owner no esta convencido del  80 / 20, en que con el 20% de software es capaz de cumplir con el 80% de necesidades de negocio.
  • Clasificación de funcionalidades como criticas y necesarias cuando estas en realidad no lo son.

Solución



  • Coach al PO por parte del SM.
  • Evaluar el Release Plan
  • Proponer en producción algo con valor lo antes posible

----

Proyecto Ágil que Tuvo una Tímida Salida a Producción




Características principales:
  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 13%
  • probablemente cumple con todo lo que pide el PO
  • Se tuvo una salida a producción, pero este afortunado evento no se volvió a repetir.
  • Su comportamiento es muy similar a un proyecto ejecutado bajo el esquema tradicional (Cascada o RUP), y su poco valor generado pone en riesgo la viabilidad del proyecto.

Riesgos
  • Alta probabilidad de cancelación del proyecto
  • Alta probabilidad de cambio de PO
  • Alta probabilidad de cambio del SM - Scrum Master - por no hacerle Coach al PO y guiarlo en los principios ágiles (y el mismo chiste sobre las suegras...)

Causas
  • Un Release Plan en el que existe alta dependencia de todas las funcionalidades según el PO,  Lo más seguro es que se argumente que se salió a producción con lo que se podía pero para cerrar el proyecto requiere el resto resto del producto.
  • Un mal pareto de software vs funcionalidad, o sea,  el  product owner no esta convencido del  80 / 20, en que con el 20% de software es capaz de cumplir con el 80% de necesidades de negocio.
  • Clasificación de funcionalidades como criticas y necesarias cuando estas en realidad no lo son.

Solución
  • Coach al PO,
  • Evaluar el Release Plan
  • Proponer salir a producción con algo lo antes posible
----

Proyecto Ágil que Tiene Salidas a Producción pero aún no Convierte todo su Costo en Valor





Características principales:
  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 50%
  • Se cumple con todo lo que pide el PO
  • Tiene salidas frecuentes a producción pero no logra poner todo el valor en producción.
  • Es un proyecto satisfactorio desde el punto de vista ágil aunque puede mejorar
Riesgos
  • No Aplica.

Causas
  • Existe una buena gestión del PO aunque no se cumple completamente el pareto de software vs funcionalidad.
Solución
  • Evaluar el Release Plan (SM, Equipo y PO) buscando con que elementos se puede salir a producción.
  • Identificar si se esta invirtiendo tiempo en funcionalidades innecesarias.

----

Proyecto Ágil que Tiene Salidas a Producción y Constantemente Convierte su Costo en Valor




Características principales:
  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 88% 
  • Se cumple con todo lo que pide el PO
  • Tiene salidas frecuentes a producción
  • Es un proyecto satisfactorio desde el punto de vista ágil  

Causas
  • Buena gestión del PO
  • Buen acompañamiento del SM y del Equipo

Solución / Recomendación
  • Seguir así y no bajar la guardia.

Quedo atento a su retroalimentación y/o comentarios.




Saludos Ágiles

Jorge Abad