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
No hay comentarios.:
Publicar un comentario