Gestión de riesgos en Scrum

La gestión de riesgos en Scrum, está integrada en su propio ADN. Cuando hablamos de un marco de gestión ágil como Scrum, estamos pensando en un modelo que ve el proyecto, no como un esfuerzo continuo del equipo sin tener contacto con el cliente, sino todo lo contrario. De hecho, a través de Sprints –iteraciones cortas de entre 2-4 semanas-, el equipo de proyecto va entregando al cliente (representado por la figura del Product Owner) “trozos” del proyecto, de forma que tenga oportunidad de validarlos y asegurar que el proyecto va por el camino adecuado.

El 11 de octubre de 2018 tuve la suerte de poder participar en el capítulo oficial de PMI® en Singapur, como ponente en una jornada con el nombre de gestión de riesgos en entornos predictivos y ágiles. Estuve comparando y analizando cómo se afrontar los riesgos según los diferentes enfoques. Fue realmente interesante, y con la participación activa de los asistentes, pudimos identificar los factores clave para ser exitosos en la gestión de los riesgos de nuestros proyectos.

¿Qué pasa con los riesgos en Scrum?

Según afirma Edzreena Odzaly (Project Manager Practitioner), Scrum integra gestión de riesgos. Ya que los ciclos iterativos cortos minimizan cualquier impacto imprevisto en el desarrollo del producto. De la misma forma, el SBOK® (Scrum Body of Knowledge, editado por ScrumStudy®) indica cómo Scrum, a través de su propio funcionamiento minimiza los riesgos teniendo en cuenta lo siguiente:

• La flexibilidad reduce los riesgos relacionados con el negocio: Ya que, en cualquier momento se pueden introducir o eliminar requisitos, y el nivel directivo/cliente está involucrado desde la perspectiva del negocio.
• El Feedback periódico reduce los riesgos relativos a expectativas: Así, frecuentemente, se puede responder a la pregunta “¿Hay algún requisito que ha sido mal-entendido?.
• La propiedad del proyecto por parte del equipo de desarrollo y su responsabilidad colectiva respecto al éxito o fracaso del proyecto, reduce los riegos de estimaciones: al crear un mayor compromiso del equipo en alcanzar sus objetivos.
• El principo de transparencia reduce la no detección de riesgos: El artefacto clave el tablero de Scrum o Kanban, en el que se indican las actividades a realizar por el equipo y que todos pueden consultar. En él se incluyen los impedimentos –impediments-, que el equipo va encontrando y que pueden afectar al resultado del sprint. Es el rol de Scrum Master quien tiene que gestionarlos para evitar que impacten en la eficiencia del equipo.
• La entrega iterativa reduce los riesgos de inversión: De forma que al ir disponiendo de productos “usables” muy pronto, se detecta antes las posibles incongruencias con el mercado y así ser capaces de reorientar el producto y la inversión asociada.

No hace falta gestionar riesgos de forma tradicional en Scrum. ¿O sí?

De lo expuesto en el punto anterior, podríamos pensar que no hay que realizar ninguna tarea especial para gestionar riesgos. Ni crear perfiles específicos, como ocurre en PMP-PMI.

Pero la realidad y la práctica nos dicen que no es suficiente. De hecho, me gustaría recomendaros leer el artículo de Martin Tomanek and Jan Juricek (Department of Systems Analysis, University of Economics, Prague, Czech Republic), denominado Project Risk Management model based on PRINCE2® and Scrum frameworks. Es un trabajo muy interesante, ya que, además de realizar un paralelismo entre PRINCE2® y Scrum, también realizan una encuesta a diferentes directores de proyectos sobre cómo gestionan sus riesgos y recopilan diversos estudios relativos a la propia gestión de riesgos en marcos ágiles.

Me gustaría resaltar las siguientes:

• Existe falta de formalidad en la gestión de riesgos en metodologías ágiles.
• Controlar los riesgos en proyectos de desarrollo de software es considerado como uno de las mayores contribuciones al éxito del proyecto.
• Muchos de los problemas –relativos a la gestión de riesgos-, pueden ser solucionados aplicando y alineando las técnicas y buenas prácticas, aplicadas a riesgos y usadas en la gestión de proyectos que podríamos denominar “tradicional”.
• La falta de una adecuada gestión de riesgos es uno de los principales factores por los que un proyecto fracasa.

Es necesario –imprescindible- sistematizar la gestión de riesgos

Efectivamente, independientemente del proyecto y del marco elegido para su gestión, es necesario identificar la mejor manera de cómo gestionar los riesgos. Existe un consenso bastante aceptado sobre cuáles son los pasos a seguir, como se puede apreciar en el siguiente esquema:

Así, el equipo de proyecto puede usar un registro de riesgos, la lista de impedimentos, o lo que considere oportuno, pero, en cualquier caso, dichos artefactos deben estar incluidos en la estrategia de gestión definida para cada proyecto en concreto.

Usemos la pila del producto – product backlog –

Un enfoque que personalmente me gusta mucho cuando se desarrollan proyecto con scrum, es el incluir los riesgos –y las acciones que se deban realizar para atacarlos- como historias de usuario. De forma que el equipo las incorpore como parte del trabajo del sprint.

En el siguiente esquema se puede ver un ejemplo esquemático:

Donde vemos dos columnas iniciales; la PBP (Prioritized Product Backlog) y la de los riesgos priorizados. Hay que tener en cuenta que no se pueden acometer todos los riegos en un solo sprint. Y además, no siempre se podrá responder a los riesgos de mayor severidad en un primer momento. Por lo que el equipo Product Owner será el que priorice qué riesgos serán gestionados en cada momento y, por tanto, incluidos en el sprint.

Así, en la cuarta columna, están localizados tanto los elementos iniciales del PBP como los riesgos priorizados.

En la planificación del sprint se decidirá qué historias de usuario incluir. En el caso expuesto la capacidad del equipo es de 31 puntos de historia para el sprint, por lo que al incluir los riesgos, dicha capacidad ha sido sobrepasada y será necesario volver a priorizar el PBP, como se ve en las siguientes imágenes:

De esta forma, el Sprint Backlog resultante incluye –de forma priorizada- y según la capacidad del equipo, las historias de usuario y los riesgos –también entendidos como historias de usuario-.

Los riesgos, riesgos son.

Los riesgos pueden poner en peligro la consecución de los objetivos del proyecto. Pero no son lo peor que nos podría ocurrir, ya que son los problemas –issues- los que no se pueden prevenir y que, al no haber sido identificados previamente, su impacto en el equipo en lo relativo a la aparición de crisis es mayor.

El mero hecho de identificar un riesgo, reduce su impacto y/o probabilidad, si se actúa de forma proactiva. Este hecho es incuestionable independientemente del enfoque o método de gestión de proyectos que queramos usar. Además, para que sea eficaz y realmente ayude al éxito del proyecto, se debe establecer una sistemática que los agentes participantes en el proyecto deben conocer y aplicar de forma consensuada y sólida. No quiere decir que haya que implementar procesos súper complejos, sino los mínimos necesarios para asegurar el control.

Si quieres conocer más sobre gestión de riesgos, te invitamos a que veas nuestro curso en el que, además, podrás certificarte como experto siguiendo las buenas prácticas de PMI®: RMP® Risk Management Professional.

Si te interesa la gestión ágil de proyectos, puedes acceder a nuestros cursos sobre Scrum y metodologías ágiles.