Gestión de riesgos en agilidad

La gestión de riesgos es una de esas áreas más clásicas y típicas de la gestión de proyectos. Raro es que alguien de un curso de gestión de proyectos y no le dedique su tiempo a la gestión de los riesgos, sobre lo que hay mucho escrito, siendo esta una disciplina de las más clásicas y estudiadas.
Yo en mis tiempos, tuve que gestionar riesgos siguiendo las pautas de la gestión de proyectos tradicional, pensando en posibles cosas que pudieran pasar, con sus probabilidades, mitigaciones, posibles planes de contingencia, etc., en fin, un plan de riesgos, que en mi caso, en aquellos tiempos, hacíamos con una hoja excel (quizá a alguno esto le suena).

Scrum no gestiona los riesgos… ¿seguro?

Como en Scrum no se explicita un plan de riesgos mucha gente piensa que los riesgos no se gestionan en Scrum, pero… ¿eso es cierto?
Claro que no, que no te hable de “plan de riesgos” no quiere decir que no los tenga MUY presentes. De hecho, la propia guía de Scrum habla de que este es un modelo para la gestión de riesgos. De hecho, como cualquier ciclo de vida iterativo (e incremental), y los ágiles son un tipo especial de ellos, se definen para el control de riesgos.
Las iteraciones cortas, entregar incrementos potencialmente entregables, revisión muy frecuente del trabajo por parte de los usuarios, las prácticas técnicas, énfasis en Test, control de deuda técnica, todo eso, ya de por sí está mitigando riesgos. Lo que lleva a que no sea necesaria una gestión de riesgos predictiva, tipo un plan frecuentemente documental.
De hecho, es más, los ya muy antiguos ciclos de vida en espiral (el de Boehmn del 88), y sin ser exactamente ciclos de vida que podamos considerar ágiles, se denominaban orientados a minimizar riesgos mediante la liberación frecuente de prototipos.

Predictivilidad vs Adaptabilidad… también en riesgos

Al igual que hacer un Gantt a largo plazo, un plan a largo plazo, algo con previsión de ser hecho de una y no cambiarse… no tiene mucho sentido en agilidad (ni en la mayoría del mundo software), por aquello de evitar desperdicios, no orientarse por la documentación, ir a lo empírico en vez de a lo teórico, potenciar la adaptabilidad frente a la predictibilidad, etc. (cosas de las que ya hemos hablado mucho y no aplica extenderse), todo eso, igualmente, aplica a hacer un plan de riesgos.

Risk Burndown y otras opciones

No obstante, hay quien hace uso de los llamados “Risk Burndown Chart”. No está muy claro su necesidad en un buen y bien usado modelo ágil, pero, yo te lo cuento para que sepas que ahí están.
Otra opción, más común, es añadir una sección de «riesgos» a los tableros Scrum, similar a la que se deja para impedimentos.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

16 comentarios en “Gestión de riesgos en agilidad”

  1. Hola Javier,
    Estoy totalmente en desacuerdo con tu sentencia «Lo que lleva a que no sea necesaria una gestión de riesgos predictiva, tipo un plan frecuentemente documental» porque parece transmitir que no es necesario realizar una gestión explícita de riesgos con Scrum, lo que desde mi punto de vista es un gran error.
    Los riesgos, sean amenzas u oportunidades, existen más allá de los que las buenas prácticas de Scrum mitigan, es decir, puede haber riesgos que no se vean afectados por esas buenas prácticas y que por lo tanto puedan impactar en el equipo y en el producto en caso de ocurrir.
    La gestión explícita de riesgos siempre debería hacerse, eso sí, adecuada a la situación en la que nos encontremos.
    Feliz año nuevo,
    Ángel

    1. La puedes hacer, sí, muchas veces se pengan riesgos en los tableros, pero no creo que sea necesario, ni recomendable, que sea tan «predictiva» y «documental» como lo es la tradicional.
      Feliz año!

  2. CARLOS ALFONSO RODRIGUEZ

    Los riesgos tienen origen en la incertidumbre y esto es algo inherente a todo proyecto indistintamente de la metodología usada. No gestionar los riesgos es sinónimo de insensatez o falta de capacitación.

    1. Yo creo que ahí estamos todos de acuerdo, siempre hay que gestionar los riesgos, tanto Scrum, agilidad, como en modelos tradicionales se gestionan, el debate es más… cómo es más adecuado hacerlo.
      Saludos!!!

      1. CARLOS ALFONSO RODRIGUEZ

        Pues una buena práctica profesional para gestionarlos es en colaboración con el equipo de proyecto, no de manera individual por el director. Identificarlos, analizarlos…. y monitorizarlos… Y en cada monitorización actualizarlos…ya que al igual que el proyecto su gestión y planificación es algo vivo y cambiante, no algo estático que se hace una sola vez.

  3. Viendo los comentarios, creo que se está malinterpretando el mensaje.
    Lo que yo entiendo es que la gestión de riesgos ya no es necesario que siga un enfoque tan formal como en una metodología clásica (sic) o en cascada, con sus fases de gestión de riestos (analisis, definición, detección, evaluación, etc. que no deja de ser una cascada), con su propia documentación y sobre todo, con un responsable de la gestión de riesgos.
    En un enfoque ágil (sea Scrum o no), lo primero es que el responsable de gestionar los riesgos es todo el equipo. Entonces, de forma natural, los riesgos se detectan, se hablan, se evaluan y se tratan de forma natural a como se llevan a cabo el resto de tareas.
    Luego diriamos que la gestión de riesgos es implícita, no necesita de todo un proceso aparte. Ya sabes: Individuos e interacciones sobre procesos y herramientas.
    Féliz Año!

    1. Hola,
      Implícito significa que no se habla explícitamente de riesgos y ese precísamente es el error y en lo que estoy en desacuerdo.
      Hay una idea equivocada de la gestión tradicional o predictiva a que se asocia calificativo como pesada y burocrática cuando no tiene por qué ser así.
      La gestión de riesgos tiene que ser explícita y tan sencilla o compleja como requiera el proyecto. Se ágil o «tradicional» nunca es un trabajo inidivual del project manager y no tiene que ir acompañada de una sobredocumentación.
      Feliz 2017

      1. Hola,
        Es que burocracia, y pesado, son características de gestión tradicional, quizá si esa gestión no es burocrática ni pesada es que no es tradicional….
        Integración continua, TDD, BDD, entregas frecuentes, diseño emergente, refactoring continuo, etc…. típicas prácticas ágiles, son gestión de riesgos explícita, compleja y dejan en un segundo plano una gestión explícita clásica de gestión de riesgos basada en típicamente en documentación y en mucha predictibilidad (y que no pase lo contrario). Lo cual reduce mucho la gestión de riesgos clásica, hasta, típicamente, a enumerar los riesgos más previsibles en los próximos sprints.
        Saludos

  4. Javier,
    Ni la Guía del PMBoK ni PRINCE2 que son los dos principales paradigmas de gestión predictiva, si son bien entendidos y bien aplicados, son burocránitos ni pesados. Otra cosa es que no se entiendan bien y se apliquen fatal.
    Sin duda hay grande malentendidos sobre la gestión predictiva y sobre todo muy mala aplicación de la misma.
    Feliz 2017.
    Ángel

    1. Por qué una fase de riesgos ímplícita tiene que significar que no se hable de riesgos? La fase de test también va implícita en ágil y se habla de tests continuamente.
      Cuando hablo de una fase de riesgos explícita, me refiero a, pej, los días D a la hora H hacemos gestión de riesgos. Venga, saca la excel de riesgos, evaluamos los que tenemos, es necesario modificar alguno? Las acciones que hemos realizdo han surtido efecto? Hay algún riesgo nuevo?
      Mientras que por implícita, y así es como lo hacemos nosotros, en cualquier momento alguien dice:
      – Oye me he dado cuenta de R, qué hacemos?
      – Tienes razón, esto podría suponer un problema. Crea una tarea para documentarlo y de momento vamos a hacer la acción A. Cuando se lleve a cabo, volvemos a hablarlo y actualizamos la tarea o creamos otra.
      Por supuesto que puedes decir que dependiendo de cómo apliques una metodología la gestión de riesgos puede ser lígera y tener poca documentación. Pero siempre va a ser una fase o proceso y siempre va a tener documentación.

    2. Por qué una fase de riesgos ímplícita tiene que significar que no se hable de riesgos? La fase de test también va implícita en ágil y se habla de tests continuamente.
      Cuando hablo de una fase de riesgos explícita, me refiero a, pej, los días D a la hora H hacemos gestión de riesgos. Venga, saca la excel de riesgos, evaluamos los que tenemos, es necesario modificar alguno? Las acciones que hemos realizdo han surtido efecto? Hay algún riesgo nuevo?
      Mientras que por implícita, y así es como lo hacemos nosotros, en cualquier momento alguien dice:
      – Oye me he dado cuenta de R, qué hacemos?
      – Tienes razón, esto podría suponer un problema. Crea una tarea para documentarlo y de momento vamos a hacer la acción A. Cuando se lleve a cabo, volvemos a hablarlo y actualizamos la tarea o creamos otra.
      Por supuesto que puedes decir que dependiendo de cómo apliques una metodología predictiva, la gestión de riesgos puede ser más o menos lígera y tener más o menos documentación. Pero siempre va a ser una fase o proceso y siempre va a tener documentación.

      1. Hola @jcesarperez,
        Las retrospectivas son obligatorías y de forma explícita se identifican mejoras.
        ¿De verdad crees que si está búsqueda de mejora fuese implícita y se dejase a lo que cada uno se le ocurre tendrían los mismos resultados?. Pues lo mismo con los riesgos.
        Feliz 2017,
        Ángel

  5. Hola Ángel:
    Lo de que las retrospectivas son obligatorias, tal cual, es bastante discutible (metodología, frecuencia, objetivos, forma, etc.) pero nos saldriamos del tema.
    Si no te entiendo mal, lo que defiendes es que siempre debe existir una fase explícita de gestión de riesgos porque es la única forma de gestionar los riesgos de forma eficaz.
    Pero para mí, depende del proyecto. Es posible que para algunos proyectos lo mejor será tener una fase explícita. Aunque no es mi experiencia.
    Toda metodología debe adaptarse a sus circunstancias de aplicación. En concreto, debe buscarse agilizarla lo máximo posible para que la gente pueda centrarse en desarrollar. La mejor manera que conozco para ello es eliminar liturgias, reuniones, procesos y documentación que no sea indispensable.
    Insisto: Individuos e interacciones sobre procesos y herramientas.

    1. Hola Javier,
      En el fondo estamos de acuerdo y no estamos perdiendo en las formas y matices y podrías estar así eternamente.
      «Individuos e interacciones sobre procesos y herramientas», POR SUPUESTO, pero «sobre» es distinto de «sin».
      Abrazos.
      Ángel

      1. Opino igual! Pensamos muy parecido. Quizás uno le da más valor a una opción frente a la otra. Fruto de la experiencia de cada uno y su visión parcial del mundo.
        Un placer discutir contigo, Ángel.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *