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

1 comentario:

  1. Jorge, interesante post. Justo hoy conversaba con un amigo sobre esto. Y mi duda, ¿cómo crees que el PO puede ir monitoreando el progreso del valor aportado al negocio por cada sprint (imagino algo como: (Valor aportado al Negocio)/(Sprint))?.. ¿tendrá sentido algo así?..además, puede que algún PBI priorizado como medio, que aún no ingresa a un Sprint, en algún momento tome mayor importancia "para el negocio", entonces, además de "cambiar su prioridad", cambiaría su "Valor para los Objetivos del Negocio".. ¿se podría realmente seguir un progreso del Valor?. Por otro lado, el "Valor al Negocio" que otorga cada PBI, es una asignación arbitraria del PO, ¿o no?. Muchas gracias!

    ResponderEliminar