Exprimiendo Scrum: Scrum y la gestión del riesgo

Un hombre en el vacio de Klein Este es el segundo de una serie de post, titulados Exprimiendo Scrum, dedicados a cómo esta metodología se acerca a ciertas cuestiones habituales en la gestión de proyectos. Anteriomente escribí sobre Scrum y la documentación y hoy le toca el turno a la gestión del riesgo en Scrum.

Uno de los aspectos de la gestión de proyectos que tradicionalmente las metodologías han tenido muy en cuenta es la gestión del riesgo. Por ejemplo, en MSF, la gestión del riesgo es uno de los pilares de la metodología. En CMMI la gestión de riesgos es un área de proceso con entidad propia y a la generalmente se presta mucha atención. En Scrum sin embargo la aproximación a la gestión de riesgo es menos explicita, pero esto no quiere decir que en Scrum no se preste atención a la gestión del riesgo, simplemente el enfoque es diferente. En Scrum la gestión del riesgo está implícita en la propia metodología no como una actividad paralela sino como una disciplina articulada de manera natural en todas las actividades que se llevan a cabo en el proyecto.

Gestionar el riesgo de los proyectos de manera explicita se ha demostrado una herramienta eficaz a la hora de atajar fallos de proyecto, es decir aquellas situaciones en las que un proyecto no cumple sus objetivos de manera clara. Pero también es cierto que este enfoque a la gestión del riesgo no funciona de manera tan eficiente a la hora de gestionar los problemas más pequeños a los que un proyecto se enfrenta día a día.

Tradicionalmente la lista de riesgos a sido el artefacto que los jefes de proyecto hemos utilizado para gestionar el riesgo. Básicamente consiste en una lista ordenada de riesgos según su impacto en el proyecto si llegasen a manifestarse y la probabilidad que estimamos de que realmente se lleguen a manifestar. Una vez hecha esta lista de riesgos, por una cuestión de economía de recursos, nos centramos en la parte de arriba de la lista de riesgos y hacemos una gestión activa de los N riesgos más considerables (donde N generalmente es igual a 10). Esta lista de riesgos se revisa de manera periódica, generalmente de manera semanal. Para estos riesgos más importantes se confecciona un plan de mitigación del riesgo, orientado a disminuir la probabilidad de que el riesgo se manifieste y un plan de contingencia, que define los pasos a dar para minimizar el impacto del riesgo si este se llega a manifestar. Este proceso aquí descrito es compartido con más o menos matices por todas las metodologías tradicionales. El problema de este enfoque es que no es ágil. Esta gestión del riesgo es pesada y burocrática y la experiencia me dice que rara vez se lleva con la disciplina necesaria y con la actualización adecuada para que sea efectiva. Además fruto de la pesadez de este enfoque de la gestión del riesgo ocurre que solo nos centramos en aquellos riesgos ‘gordos’ y evidentes, que son muy peligrosos si pero que son comunes a todo proyecto y que rara vez se manifiestan.

En Scrum la gestión del riesgo se aborda de manera diferente. Es un hecho sabido por todos los que hemos realizado un plan de gestión del riesgo y la gestión del riesgo en un proyecto que para la gran mayoría de los proyectos los riesgos que se detectan son los mismos y están relacionados con los mismas áreas del proyecto. En vista de esta situación en Scrum se sustituye la gestión del riesgo explicita por la gestión del riesgo continua. Una de las principales razones de ser del Daily Scrum, es la gestión del riesgo. Una de las preguntas que se responden en el Daily Scrum es: ¿Qué impedimentos has encontrado?. Responder esta pregunta día a día es sin duda una manera implícita de gestionar los riesgos del proyecto. Otro excelente momento para detectar riesgos es el Sprint Retrospective, que permite atajar todos los riesgos relacionados con la comunicación con el cliente y los requisitos. Para que esta manera de gestionar el riesgo sea efectiva el Scrum Master debe hacer hincapié en que no solo se hable de impedimentos actuales sino de también de aquellos impedimentos que se vislumbran en el futuro del proyecto. Esto cubre perfectamente la detección de riesgos, pero ¿que hacemos para mitigarlos?.

Una de las principales labores del Scrum Master sino la principal es actuar sobre los impedimentos y eliminarlos o mitigarlos en la mayor parte posible. Pero una cosa que debemos conocer es que a menudo hablar de un riesgo, detectarlo y tenerlo en cuenta es más que suficiente para mitigarlo. Scrum pone el peso en la comunicación continua de los problemas que acechan al proyecto como instrumento para atajar los riesgos del proyecto.

Para finalizar os dejo una lista de las 10 áreas de riesgos habituales en proyectos sacada de entre la que se propone en Rapid Application Development, biblia de la gestión clásica de proyectos escrita por Steve McConnell, y la manera en que, a mi modo de ver, Scrum trata de atajar ese riesgo en particular.




































Riesgo Cómo lo controla Scrum
Ampliación descontrolada de características En Scrum se parte de una lista ordenada por retorno de la inversión de las características del proyecto. Esta lista es gestionada por el Product Owner y puede ser establecida al pricipio del proyecto. Aunque siempre esta abierta a la inclusión de nuevas características, esto siempre implica, de manera explicita un aumento en el número de Sprint, en la magnitud del proyecto. Esto ataja los problemas habitualmente relacionados con la ampliación descontrolada de características, pues en Scrum nunca la ampliación de características es descontrolada sino el fruto de un proceso explicito de priorización y evaluación.
Captura de requisitos mal realizada Ninguna metodología protege de una captura de requisitos mal realizada. Pero una metología si puede proteger del losriesgos más habituales en lo relativo a la captura de requisitos: no realizarla en absoluto, realizarla de una mánera demasiado exhaustiva, no asumir que cambiaran y no detallarlos suficientemente antes de la implementación. En Scrum estos riegos se atajan respectivamente con la construcción del product backlog, evitando detallar los requisitos en una fase temprana de proyecto y detallandoles adecuamente, durante el Sprint Planning Meeting, cuando se va a realizar su implementación.
Calidad insuficiente La imposición que Scrum realiza de demostrar de la funcionalidad implementada durante el Sprint Review actua como fusible de seguridad ante la calidad insuficiente. Ningún equipo que desarrolle software de baja calidad podrá salir airoso de un Sprint Review.
Plazos optimistas impuestos En Scrum el equipo es el último responsable de aceptar los plazos y de comprometerse con la cantidad de características a implementar durante el Sprint. Nadie puede imponer plazos que no sean realistas pues el equipo tiene la postestad para no aceptarlos, con lo que los riesgos relacionados con la imposición de plazos optimistas no realistas se zanja de raiz.
Diseño inadecuado De nuevo el Sprint Review y la demostración que realizamos durante el mismo actua aquí como una valvula de escape que nos alerta rápidamente de las carencias en lo relativo al diseño inadecuado. Si el diseño de la aplicación no es adecuado, las carencias se harán patentes durante el Sprint Review. Durante la Sprint Retrospective también el equipo detecta a menudo partes del diseño de la aplicación que deben ser refactorizadas.
Síndrome de “la bala de plata” Scrum no acepta las balas de plata. Scrum incide en que el progreso del software desarrollado demostrado Sprint tras Sprint es lo único que asegura que el proyecto sigue un buen camino hacia el existo. De nada sirve confiar en balas de plata y no tener avance que demostrar en el Sprint Review.
Desarrollo orientado a la investigación El concepto de ‘Hecho’ es clave en Scrum. Solo se demuestran las características que estan completadas, por lo tanto si investigamos y no logramos resultados la situación se hace patente de manera clara y rápida al no verse avances en el Product Burndown Chart y durante los Sprint Review. Scrum tiene sitio para el desarrollo orientado a la investigación pero siempre deja patente si esta investigación optiene resultados o no.
Personal inadecuado Ninguna metodología actua de maner explicita en este aspecto. Scrum minimiza las posiblidades de que en el equipo haya personal inadecuado al incidir mucho en que los miembros del equipo sean multidisciplinares y que se produzca una continual comunicación y transmisión de conocimientos entre ellos mediante el Daily Scrum. De cualquier modo este es un problema más relacionado
Fallos de los proveedores Scrum no aborda este apecto de ninguna manera hasta donde yo se. La única metodología que lo hace de manera explicita es CMMI.
Fricción con los clientes Scrum como metodología ágil que es sigue el manifiesto ágil y por tanto el pricipio de poner ‘la colaboración con el cliente sobre la negociación de contratos’. Para ello Scrum pone en todo proyecto un representante de los intereses de cliente, el Product Owner y además permite y persigue la colaboración y la comunicación con todos los involucrados en el proyecto durante los Sprint Reviews.

Espero que ya nadie más me diga que Scrum no se preocupa de gestionar el riesgo de los proyectos 😉

4 comentarios en “Exprimiendo Scrum: Scrum y la gestión del riesgo”

  1. Scrum como metodología ágil que es sigue el manifiesto ágil y por tanto… […]

    Quizás es mucho dogmatismo técnico, pero Scrum por su genericidad no es una metodología propiamente dicha, sino solo un marco de trabajo que puede ser extendido y re-implementado por quien vaya a usarlo, respetando las cosas ya establecidas por el manual de Scrum y agregándole otras. Es muy común que la metodología utilizada sea el marco Scrum combinado con XP.

Deja un comentario

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