¿Cómo gestionar riesgos con ROAM?

Tablero para ROAM - Thanks to Philippe Garin

El objetivo de la gestión de riesgos con ROAM es ayudar a los equipos y trenes (ARTs) a asegurarse de que todos los riesgos potenciales se aborden de forma adecuada. Se trata de una técnica muy simple para identificar y gestionar los riesgos de forma transparente, eficaz y proactiva.

Es una gestión esencial que puede marcar la diferencia entre el éxito y el fracaso; la falta de una gestión de riesgos puede hacer descarrilar a los equipos y trenes aún habiendo efectuado excelentes planificaciones.

ROAM es el acrónimo de Resolved, Owned, Accepted y Mitigated y se refiere a los cuatro tipos de acciones sobre cómo manejar un riesgo potencial.

La técnica comienza por agrupar riesgos de acuerdo con las cuatro acciones:

• RESOLVED riesgos detectados pero que no son una amenaza, no necesitan una acción
• OWNED: riesgos sobre los que alguien toma la responsabilidad de gestionarlos a posteriori
• ACCEPTED riesgos que simplemente se asumen y se traten según vaya siendo necesario
• MITIGATED: riesgos para los que se ha decidido un plan de acciones mitigantes concretas

Una vez organizados los riesgos en estas categorías se realiza una votación para decidir en qué riesgos vale la pena trabajar y cuales no, y con cuales empezar. Habrá responsables de ejecutar acciones de mitigado y de gestión cuyos resultados se trataran de forma periódica en el foro correspondiente.

Los riesgos más pequeños se gestionan a nivel de equipo mientras que los riesgos más grandes, que afecten a los trenes, se tratan a nivel de programa. Cada equipo debe tener un foro regular para tratar los riesgos ante un tablero a tal efecto, una excelente solución es incluir la gestión de los riesgos en la daily.

Para el tren tenemos un tablero a nivel del programa, donde recogemos los riesgos y que permite discutir abiertamente todos los factores que pueden obstaculizar el progreso del tren. El tablero se informa por primera vez durante la PI Planning, cuando equipos individuales descubren riesgos potenciales que pueden afectar al tren. La responsabilidad de asegurar que los riesgos se gestionen es del RTE, quien conoce quién es responsable de mitigarlo o quién es dueño de gestionar qué riesgo.

El foro donde se gestionan los riesgos a lo largo del PI es la PO-Sync; se mueven riesgos de un área a otro en función de los que haya ocurrido, por ejemplo si acciones de mitigado han resuelto el riesgo este se mueve a resolved. Resaltar que a lo largo del PI pueden surgir nuevos riesgos que haya que gestionar y que se incorporan al tablero.

Mis agradecimientos a Philippe Garin y os invito a leer su post sobre ROAM "Gestion des risques: Le tableau ROAM"

¿Introducir elementos de proyectos en una PI Planning tiene algún beneficio?

En algunas realidades de compañías que vivo seguimos intentando conciliar dos mundos con objetivos divergentes: los proyectos cerrados, que se focalizan en cumplir con el alcance, coste y tiempo, y la entrega incremental de valor con Scrum.

Llegada la PI Planning les pedimos a los equipos crear un plan a partir de una mezcla de requisitos de proyectos cerrados y elementos de una pila de producto.

La regla que definimos para ello parecía simple y de sentido común:

1. Planificar todo el trabajo proveniente de los proyectos
2. Rellenar con elementos de la pila de producto hasta que se haya agotado la capacidad

Sobrecarga en cada una de los sprints

Los beneficios esperados eran:

• Un equilibro de lo planificado con la capacidad del tren (ART)
• Identificación y resolución inicial de dependencias entre equipos
• Una visión sistémica y factible de todo el trimestre, visión que antes no teníamos
• Al conocer los requisitos de los proyectos antes podíamos efectuar una mejor preparación previa

Esperábamos que si hubiera más carga que la capacidad del tren proveniente de los proyectos, el plan se limitara a los elementos de los proyectos que fuera posible construir.

La realidad fue muy distinta. Las personas nos comportamos como nos miden; los equipos, aunque tuvieron la consigna de no sobrecargase, se sobrecargaron con el ánimo tradicional de "que hay que trabajar en todo lo que nos piden en un proyecto". En la imagen de la derecha vemos un ejemplo real, todos los sprints están sobreacargados, por ejemplo una carga de 55 puntos de historia cuando la capacidad es 46, ¡179 cuando la capacidad es 33!...

Las disfunciones que detectamos en la "PI Planning" fueron:

• Los elementos provenientes de proyectos cerrados eran muchos mas que los de la pila de producto
• La cultura de los "Propietarios de Producto" fue algo así "hay que cumplir con todo lo de los proyectos"

En conclusión no podemos dar objetivos divergentes (la de los proyectos cerrados y la de entrega de valor) a los equipos. Quizá podamos incluir algún proyecto menor en la PI Planning, quizá sea inevitable, pero la mentalidad de una compañía que quiera ser competitiva en el mercado y focalizarse en la entrega de valor, tiene que basarse en los valores y principios Lean-Agile.

Para cerrar el post quiero añadir que el segundo día de la PI Planning fue un infierno. La consigna de no sobrecargarse siguió siendo válida, aunque la de terminar los proyectos también... con lo que los equipos replanificaron para sobrecargarse de nuevo. Al cabo de tres meses tuvimos una lectura interesante y positiva: el hecho de haber realizado una PI Planning y haber "implementado SAFe®" provocó que con solo una entrega del 43% de los puntos de historias planificados, entregamos un ¡91% de valor!

¿En la planificación de sprint se limita la carga al 80% de la capacidad?

80% gracias a Pixabay

Hay algo de confusión cuando en Scrum decimos que se recomienda que los equipos no se carguen más allá del 80%, pero ¿del 80% de qué?

Si fuera de la carga (la cantidad de puntos de historia que un equipo pone en su pila de sprint) con respecto a la capacidad (la cantidad de puntos de historia que el equipo puede acometer en un sprint) algo no encaja... Al fin y al cabo la capacidad se basa en la velocidad (media de puntos de historia finalizados/entregados en los últimos sprints), que es una métrica objetiva a final de sprint que incluye todo lo que sea singular en ese equipo.

Para quién le interese podéis encontrar en mi post "Cuál es la diferencia entre velocidad, capacidad y carga en Scrum?" la definición de estos conceptos.

En otras palabras, si hemos medido en los tres últimos sprints que el equipo ha entregado digamos 31, 29 y 32 puntos de historia, podemos llenar el siguiente sprint con alrededor de 30 puntos de historia y estar razonablemente seguros de la entrega de todo lo planificado. Aquí no aplica el 80%...

Dónde si aplica este 80% es en el nivel más alto de desempeño de los equipos, desempeño que éstos alcanzan cuando la ocupación es del 80% de su tiempo.

En project management los jefes de proyecto aplican algo llamado factor de enfoque o Focus Factor; generalmente no planifican más de entre 6 y 6,5 horas diarias (de las 8) de cada persona para ejecutar un proyecto. Por tanto el factor de enfoque no es más que la capacidad de los equipos para mantenerse enfocados sin ningún impedimento en los objetivos del sprint.

Cuando trabajamos con horas se obtiene la "capacidad real" multiplicando la capacidad total, en horas, por el factor de enfoque. Por ejemplo, con un factor de enfoque de 80%, la capacidad real en horas de una persona por semana es de 40*80% = 32 horas.

Por tanto planificar una pila de sprint, teniendo en cuenta que no supere el 80% del tiempo disponible del equipo, es un excelente punto de partida. Una vez que el punto de historia se haya interiorizado y hayamos obtenido la velocidad hemos de obviar ese 80%, ya que la experiencia de sprints anteriores permite planificar con mucho más acierto.