¿Cómo lidiar con la incertidumbre inherente a los proyectos/productos?

Los principios de un proyecto son una situación de gran incertidumbre, conocemos los problemas de negocio más urgentes de forma general pero no al detalle, no tenemos aún sentido de su evolución en el tiempo, aún estamos sin experiencia en el mercado y por tanto desconocemos las necesidades reales, realmente es un momento en el que se puede saber muy poco.

En gestión clásica se suele tener la convicción de que existe una solución única e ideal y que esta se puede conocer al principio, y la tenemos en ese momento de máxima ignorancia. En gestión ágil si observamos el comportamiento de Scrum a lo largo del cono de la incertidumbre vemos que con cada sprint hay un punto de aprendizaje que nos permite reconducir la construcción hacia la mejor solución posible.

Recordemos el método INVEST para medir la calidad de una historia de usuario, en concreto la N de negociable: los detalles de una historia deben de ser acordados con el cliente o usuario durante la fase de conversación, poco antes de su inclusión en un sprint, en el último momento responsable, cuando la información es más fresca. De la misma manera debemos de decidirnos por diseños o componentes en el último momento posible, ya que de esta manera tendremos la opción más adecuada.

La Agilidad se basa en realidades, la variabilidad es inherente a todo producto y si eliminamos la variabilidad demasiado temprano limitamos ganar experiencia de lo que funciona y lo que no.

A través de puntos de aprendizaje terminamos en la solución óptima

SAFe incluye entre sus principios el tercero, el que nos habla de "asumir variabilidad y preservar opciones", este nos hace considerar un abanico de opciones en las soluciones de diseño y no pretender determinar las opciones al principio, los puntos de aprendizaje a lo largo del proyecto nos enseñarán cuál es la opción ideal:

• Refinamientos y planificaciones de sprint en las que ganamos comprensión de lo que hay que construir.
• Puntos de integración y puntos de feedback como las revisiones.
• Retrospectivas.
• Tareas de exploración de soluciones (Spikes/Enablers).

Por ejemplo; como Propietario del Producto debemos de buscar la mejor solución funcional posible a una necesidad de negocio, y a veces hay varias soluciones posibles de las que de antemano no sabemos cual es la mejor de ellas. En ese caso podemos añadir tantas historias de usuario a la pila de producto como soluciones posibles veamos. A medida que avancemos en el proyecto iremos ganando información y aprendizaje, y así descartando las historias menos adecuadas. En el momento de la inclusión de la historia de usuario en un sprint, lo haremos con la que es la mejor solución posible.