¿Cómo utilizar el cono de incertidumbre para evangelizar?

Una de las situaciones más complicadas que puede encontrarse un Scrum Master, o un coach ágil, es tener que explicar a un directivo o mando intermedio, que sólo ve que está contratando un proyecto del que entiende un alcance cerrado, porqué con Scrum, sin cerrar el alcance, resultaría en algo que le aportaría más beneficio. Una herramienta para hacerlo es utilizando el cono de incertidumbre.

Aplicado a la gestión de proyectos, el cono de incertidumbre describe la evolución de la medida de incertidumbre durante la realización de un proyecto. Cuando se inicia un proyecto, es poco lo que se sabe sobre el producto, el entorno, el cliente, etc. Resaltar que en un proyecto con metodología predictiva (tradicional) los requerimientos se recogen justo en ese punto, en el de mayor incertidumbre y por tanto el de mayor ignorancia. En ese punto la incertidumbre se sitúa entre un X4 y un /4 de la estimación hecha, y se va reduciendo conforme pasa el tiempo. A medida que se haga investigación, avance el desarrollo del producto, mayor será el conocimiento aprendido y la incertidumbre disminuirá proporcionalmente, llegando incluso a 0%, lo que ocurre usualmente al final del proyecto.

Cono de incertidumbre

Podemos dibujar un cono de incertidumbre, como el de la imagen, e ilustrar como sería un proyecto con metodología predictiva (tradicional). Situamos el resultado de la toma de requerimientos del analista de negocios en el punto 1 y trazamos una línea recta hasta la diana, esta representa el desarrollo del producto en base a los requerimientos del punto 1. El punto de impacto, el punto 2, muestra el producto obtenido, que está dentro de la diana, pero no en el centro. Obtendríamos un producto de relativa calidad en el que habría transacciones que no cubrirían del todo las necesidades, serian operativas pero mal resueltas, y lo que es más alarmante, una serie de transacciones fuera del cono, localizadas en el área 3, que no servirían para nada y serían puro desperdicio. En un post sobre el desperdicio que puede ahorrarse bajo Scrum se puede ver los resultados de un caso real en el que participé.

Para ilustrar como sería el proyecto bajo metodología evolutiva (métodos ágiles) podemos dibujar los sprints, las cajitas verdes con el 4, y mostrar que al finalizar cada uno de ellos por el hecho de inspeccionar y adaptar, vamos corrigiendo el avance del proyecto para llevarlo exactamente al centro de la diana. Gracias al feedback en la revisión de sprint de clientes e interesados aprendemos, a medida que avanzamos, lo que estos realmente necesitan. Con metodología predictiva (tradicional) llegamos al punto 2, que representa lo que el cliente pensaba que quería, y mediante metodología evolutiva (métodos ágiles) llegamos al punto 4, que representa lo que éste realmente necesita.

Esto también puede verbalizarse con la siguiente pregunta: ¿que es preferible, obtener un producto que cumpla con el alcance descrito al principio del proyecto, con desperdicio y calidad relativa, o un producto cuyo detalle no se conozca hasta el final pero que garantice que cubre las necesidades realmente prioritarias, lo que dé valor al cliente? Una buena definición de valor para el cliente es aquello para lo que está dispuesto a pagar, aquello que dé solución a sus problemas.

Conos de incertidumbre de los sprints,
thanks to Silvana

Añadir que con la participación del cliente este vive al finalizar cada sprint la evolución del proyecto, y tiene sensación de que se le escucha y de que realmente se le está construyendo una herramienta que cubrirá sus necesidades.

Para visualizar como Scrum minimiza los riesgos derivados de la incertidumbre podemos dibujar el cono de incertidumbre de la derecha. En este se ve que la incertidumbre "viva" sólo es la del sprint en curso. Acabado el sprint esta será 0, y volvemos a tener otro cono, muy pequeño comparado con el de un desarrollo tradicional, cuyos riesgos e incertidumbres resolveremos dentro del mismo sprint. Resaltar que a medida que vamos construyendo el producto este actúa como elemento que despeja incertidumbres y hace que los conos de incertidumbre de los sprint posteriores sean menores a medida que avancemos en el proyecto.

Este post lo dedico al Zorro Gris, alguien que aprecio mucho y espero incorporar en algún momento en uno de los equipos ágiles que lidere :-)