Gestionando el Riesgo en un Equipo Ágil

En contextos complejos el riesgo siempre está presente, entendiendo el riesgo como “La posibilidad de ser expuesto a una circunstancia adversa o no deseada”.

Y este hay muchos tipos de riesgos o formas de clasificar el riesgo en proyectos o iniciativas y esas clasificaciones son:

  • Riesgo Financiero: Asociado mas al presupuesto o inversión en una iniciativa y su ROI esperado. ¿alcanzara el presupuesto? ¿se pagará?
  • Riesgo del Negocio: Asociado a si las características o funcionalidades de un producto tendrán el resultado esperado ¿Sera usado? ¿proveerá el beneficio esperado? ¿resuelve el problema?
  • Riesgo Técnico: Asociado a la construcción del producto o iniciativa ¿se puede construir? ¿cumplirá las expectativas técnicas?

Al final todo el riesgo de una u otra manera tendrá una consecuencia en lo Financiero y es de allí la importancia de identificarlo y gestionarlo.

En este Post hablare de como gestionar el Riesgo Técnico y del Rol del Scrum Máster en esto, del riesgo del negocio hablare en un futuro Post.

¡Manos a la obra!

El riesgo técnico lo podemos sub-dividir en 3 conceptos más simples y aterrizados:

  • Puramente Técnico: Es el riesgo respecto del diseño de la solución y su arquitectura, por ejemplo, temas de performance, de seguridad. Temas que tienen posibilidades de fallar en ese ámbito, pero que el equipo tiene el poder de gestionarlos completamente (ya desarrollare esta idea)
  • Dependencias Externas: Este riesgo aparece cuando el proyecto, producto o iniciativa que esta trabajando un equipo, tiene dependencias de terceros, ya sean otros equipos dentro de la organización o proveedores, donde cualquier fallo en calidad y tiempo afectara al proyecto, producto o iniciativa.
  • Del Proceso: Este es el riesgo del día a día que afectara los objetivos del Sprint, por ejemplo, que se caiga un ambiente, que te borren los datos de QA, que se enferme o retire un miembro del equipo, etc.

¿Cómo Gestionamos cada uno de estos?

Primero entendamos por Gestionar el Riesgo actividades de identificación, análisis, plan de acción, monitoreo y control.

Identificación y análisis

Una buena técnica para identificar y analizar el riesgo es armar una matriz de impacto y probabilidad, esta en vez de ser un Excel guardado en alguna carpeta de la iniciativa, debe ser un artefacto de gestión visual y vivo.

El cual puede ser co-creado por el Scrum Team y los principales Stakeholders y de la misma manera debe ser un ciclo de revisión y actualización como cualquier artefacto ágil.

¿Por qué no te digo exactamente cual es el ciclo de revisión y de actualización de este artefacto?

Porque estamos en contextos complejos, no hay balas de plata, es un proceso empírico, debes experimentar un ciclo de revisión y actualización y quizás revisar en las retrospectivas si es el correcto. ¿Debería revisarlo en las Review?  Pues experimenta y recibe feedback de los stakeholders.

Plan de Acción Monitoreo y Control

Una técnica buena y ligera para generar planes de acción respecto de los riesgos es ROAM:

  • Resolved: Todos están de acuerdo en el riesgo ya no es más un riesgo, ya sea porque llego nueva información al equipo, se ejecutó el plan de mitigación.
  • Owned:  Alguien del equipo o stakeholder toma el riesgo para sí y se hará cargo de generan un plan de acción o mitigación.
  • Accepted: Es poco lo que se puede hacer respecto del riesgo en el equipo y fuera de él, por tanto, se acepta que sucederá y se debe pensar en que se hará cuando suceda.
  • Mitigated: Se genera un plan para mitigar el impacto del riesgo.

Ejemplos:

Si hablamos de un riesgo “Puramente Técnico” ( recuerden la subclasificación que hice mas arriba) por ejemplo, un tema de performance o de seguridad, este podría ser Owned por el equipo y planear hacer una prueba de concepto (POC) o un Spike, que se agregue al producto backlog para así dejar el Riesgo es Resolved o Mitigated.

Si hablamos de dependencias externas, un stakeholder podría hacer Owned de ese riesgo y hacer las gestiones para monitorearlo constantemente e informar al equipo o mitigarlo.

Si hablamos de algo que es del proceso, por ejemplo, que se caiga un ambiente, el equipo podría hacer Owned de ese riesgo y generar un plan de crear algún ambiente temporal que se use cuando el ambiente oficial se caiga de esta forma Mitigated el riesgo. Lo mismo puede pasar si alguien se enferma o se va del equipo, preparando un plan de generar conocimientos cross-funcionales en el equipo para que la falta de un miembro sea mitigada.

Para lo anterior crea un tablero del ciclo de vida del riesgo y podrías dividirlo entre los que tienen pocas posibilidades de ocurrencia por tanto debes accionar cuando el riesgo es Gatillado u Ocurre.

Y un tablero para riesgos con alta probabilidad y por tanto tu plan de mitigación debes ejecutarlo sí o sí.

¿Qué es clave?

  • Hacer los riesgos visibles.
  • Gestionarlos constantemente.
  • Involucrar al equipo y los stakeholders.
  • Comunicar y accionar.

Entender que el enfoque agil no le quita complejidad a los proyectos o iniciativas, si no mas bien nos permite navegar o avanzar mejor en esa complejidad, administrando más efectivamente el riesgo y no con prácticas necesariamente explicitas como las que describe este Post sino más bien implícitas, por ejemplo:

  • El riesgo técnico se maneja mejor retrasando decisiones técnicas, realizando pruebas de concepto o Spikes para disminuir esa incertidumbre y las probabilidades de riesgo. En el enfoque tradicional las mismas decisiones técnicas se toman al inicio con mucha incertidumbre.
  • En el riesgo de negocio se generan MVPs para validar la idea, se obtiene feedback temprano del cliente para corregir el rumbo y medir si efectivamente la solución tiene el outcome deseado, incluso a nivel de features es recomendable hacer MVPs. En el enfoque tradicional no obtienes feedback del cliente hasta el final, hasta que todo esta concluido y ya es tarde para corregir el rumbo.

Un Error común como Scrum Master es pensar que la gestión de riesgos depende de ti como Jefe de Proyectos, y que debes resolver todo, cuando realmente lo que debes hacer es facilitar su identificación y gestión, empoderar al equipo en la gestión de riesgos e involucrar a los Stakeholders para que entiendan los riesgos y se hagan parte de la solución.

Este y otros temas son parte de mi Workshop Scrum in Action https://fabianthinking.com/scrum-in-action/

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s