La gestión del riesgo pretende detectar y mitigar el impacto de sucesos adversos. Con mentalidad tradicional tendemos a pensar que el alcance corresponde a una visión de negocio correcta, y que si entregamos un producto de acuerdo a esos requerimientos satisfacemos las necesidades de nuestro cliente o usuario. Por otro lado damos por hecho que el equipo resolverá los temas técnicos porque es el responsable de escribir un código que funcione. Con esta mentalidad obviamos los riesgos más importantes y más comunes, los riesgos relacionados con el cambio en los requerimientos, la falta de comunicación y el bajo rendimiento de los miembros del equipo. Justamente a estos riesgos es a los que Scrum da solución de forma implicita.
La mejor acción para mitigar y eliminar
Scrum, debido a su carácter iterativo, con entrega temprana y frecuente, inspección y revisión, hace que nos adaptemos cuando las cosas no van como deseamos. Reduce el coste de la asunción de riesgos truncando caminos infructuosos rápidamente con cada sprint. Scrum es una gestión de riesgos en si mismo y que ocurre en todo momento: en la daily, en las reuniones de planificación de sprint, en las reuniones de planificación de release, en las reuniones de revisión y también en la retrospectivas.
Existen otros tipos de riesgos que Scrum no gestiona implícitamente, como por ejemplo la falta de comprensión de Scrum por parte del cliente, productos de terceros que no funcionan como se esperaba, dependencias externas que no se resuelven a tiempo, Propietarios del Producto que no están comprometidos con su rol o cuyas agendas entran en conflicto con las necesidades del equipo... pero todos estos riesgos los visibiliza Scrum de forma temprana, como dice Rafael, un profesor mio, Scrum es como una suegra, pone sobre la mesa todos los puntos débiles e imperfecciones al primer contacto. :-)
Pensemos que el objetivo de cada sprint es que el equipo entregue el incremento con el que se han comprometido cumpliendo con DoD, de forma que sea potencialmente instalable en producción. Así, ya en el primer sprint aparecen gran parte de riesgos e impedimentos que se deben de resolver para el siguiente sprint. Usualmente resueltos los impedimentos al principio del proyecto habremos eliminado gran parte de los riesgos, que en un proyecto tradicional suelen aparecer a final cuando estamos a punto de entrega.
Nosotros aprovechamos las reuniones de refinamiento para hablar y detectar riesgos e impedimentos de sprints futuros. Como buena solución los añadimos como una historia especial a la pila de producto para que se tengan en cuenta y se hagan las acciones oportunas para mitigarlos o resolverlos a tiempo.
