Mostrando las entradas con la etiqueta Deuda de Valor. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Deuda de Valor. Mostrar todas las entradas

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.





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