 |
| Tablero para ROAM - Thanks to Philippe Garin |
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"
No puedo estar más en desacuerdo con esto. El ROAM originalmente está pensado para el Project Manager o Product Manager. Simplificar un proceso como el ROAM es como decir que un programa son solo unas líneas de código.
ResponderEliminarLos desarrolladores son profesionales, y tienen muy claro que están construyendo y a las dependencias a las que se enfrentan.
En que momento introducimos el ROAM? Otra reunión más? Venga.... reuniones, horas de una supuesta producción.
Cuando programo, tengo clarísimo que posibles dependencias se pueden crear a la hora de realizar el trabajo.
Scrum, ya tiene una reunión corta, donde se aborda mi trabajo, el seguimiento y de ahí puede partir una comunicación efectiva con el resto de los compañeros para detectar una implicación y un impacto de lo realizado. Nunca un riesgo. Somos profesionales, basta ya de intentar proteger, controlar, reducir algo que está implícito en lo que se hace y que se tiene la capacidad para afrontarlo.
Me a decir usted que en Inter Grundig S.A., donde desarrollaba necesitaban horas para analizar dependencias del producto realizado? No era usted lo suficientemente profesional para que su analítica a la hora de escribir su código no tuviera en cuenta lo que estaba haciendo? De verdad no sabemos el principio de los tipos de relaciones entre tablas, datos? reutilización... y otros muchos más aprendizajes a la hora de programar?
Buenos días,
EliminarQuizá haya que poner las cosas en su contexto. Lo que describo en el artículo es una técnica, con un irradiador visual asociado, que solo tiene sentido cuando afecta a muchas personas.
Cuando era programador en Inter Grundig eramos literalmente 4 personas, simplemente hablabamos y los riesgos estaban ahí, los conociamos y los gestionabamos sin más. En los equipos de Scrum pasa algo parecido, normalmente he visto en el tablero una zona con un par post-its que recogen los riesgos y hablan de ellos en la daily, sin más.
¿Pero que pasa cuando tienes 3, u 8, equipos trabajando en un mismo producto? ¿Cuando hablamos de 50 personas qué hacemos? Allí es donde entra esta técnica, al igual que del tablero de dependencias (encontrarás algun post en mi blog). Sin las técnicas y los tableros no visibilizas, y ante la complejidad de tantas personas, si no visibilizas estás perdido.
Lo que hacemos nosotros es hacer seguimiento de los riesgos que afectan a todos en una reunión semanal llamada PO-Sync. Es una especie de daily (weekly) con todos los Propietarios del Producto de esos equipos y otros expertos relacionados. En esta reunión se mira entre otros la evolución de esos riesgos.
Yo lo que puedo contar, desde mi perspectiva de Agile Coach que acompaña a alrededor de 70 personas, es que la técnica que describo les es muy últil para gestionar los riesgos.
Ya no hay heroes programadores como cuando yo programaba, hoy en día lo que importa es la suma de todos, ¡la colaboración es el diferencial! Y estas técnicas y sus tableros dan un referente comun.
Gracias por escribir,
Alex
Entiendo la postura y el proceso que indica.
ResponderEliminarHace un par de días, ante un proyecto nuevo, en el análisis de las historias de usuarios, se estaban contemplando los procesos a realizar. No voy a decir nada que no sepamos todos ya.
Gestión de cliente, gestión de solicitudes, gestión de servicios y todo derivaba en la creación del presupuesto. (entiéndase gestión como CRUD). Al desarrollar las historias de usuarios y plantear el roadmap para generar el sprint, se tuvo como premisa la creación primero de la gestión de cliente, en paralelo con la gestión de los servicios, pues sin esos puntos prioritarios no se podía llegar a la solicitud y mucho menos al presupuesto (dependencias).
Todo eso en la época más temprana de la visión del trabajo, ya estaba asumida por los desarrolladores entendiendo que es el ciclo fundamental para las buenas prácticas.
Bajo esa premisa, a la hora de la planificación, independientemente a la cantidad de participantes y todo ello regado con una documentación concisa y abierta a todos los integrantes, sientan las bases para minificar posibles "deudas técnicas", que a posteriori conlleven a retrabajo.
Si que en el proceso de coordinación de equipos, en un nivel superior, se puede hacer referencia a las premisas que se han tenido en cuenta a la hora de realizar un proceso en concreto sea del tipo que sea y de la complejidad que requiera el producto.
Pero digo yo, en la reunión técnica donde hay varios encargados de equipos y donde seguro hay más de una persona del tipo arquitecto, no se planifica una línea de trabajo conjunta donde el tema de las dependencias no estén contempladas?
Como siempre, si algo puede suceder, sucederá. Ley de Murphy
Pero me gustaría saber que en el proceso más temprano, se ha planteado esas posibilidades y se ha contemplado un posible ROAM ante estas circunstancias, y no, en el proceso de trabajo del día tener que atender estas situaciones que implican reuniones, tiempo, refactorización y retrabajo, que desembocan en tiempo que no se dedica a entrega de valor al cliente.
Un saludo.