AGILE no es solo SCRUM, y esto parece que cuesta, porque poco se ha publicado, y me temo que, trabajado, en AGILE sin SCRUM, a pesar de que sabemos que hay otras muchas herramientas que encajan en la agilidad. Si la agilidad es útil, que lo es, debería tener un cierto grado de totipotencia, que lo tiene, esto seguro de ello.
Es fácil identificar una convergencia entre la agilidad y la seguridad; entre la necesidad de seguridad y la necesidad de agilidad. El mundo de la seguridad y de la gestión de riesgos, que ha avanzado notablemente desde los terribles atentados de NY, pero ha estabilizado esa progresión, en los últimos años y puede que la agilidad sea un revulsivo para esta imprescindible actividad empresarial.
Vamos a tratar de trazar unas líneas entre ambos marcos, la gestión de crisis y emergencias y la agilidad. No se trata de hablar de riesgos «dentro» de un proyecto agile, sino de usar agile en la gestión de crisis y en especial en la gestión de emergencias. Dejaremos para otra ocasión la reflexión entre AGILE y su aplicación a la gestión riesgos, en su sentido más preventivo. Esta traza seguramente conlleva alguna blasfemia agílica y algún anatema scrúnico Pero ¿Hay algo más AGILE que explorar, qué inventar, que arriesgar? Pues vamos a ello. Creo que puede ser bueno empezar recordando que «hay proyectos que no podemos controlar, pero si gestionar» como nos dice Jose Manuel Beas
Equipos
La gestión de riesgos utiliza habitualmente dos equipos. El equipo tipo “comité de crisis” que aborda el control de una situación de emergencia del tipo que sea y el equipo tipo “comité de seguridad” que está dedicado al análisis y mejora en función de lo ocurrido y a la prospectiva en seguridad. Creo que ambos pueden trabajar en agilidad, en especial el primero al que dedicaremos este post, haciendo una adaptación del marco de trabajo a unos tiempos muy cortos que, aunque no tengan un límite definido, es decir que no sean estrictamente “time box”, su propio y reducido tamaño lo hace equivalente a tener esos límites, pero con una presión mayor.
El Comité de Crisis, espejándose en un equipo agile (bueno valeeeee, en un equipo SCRUM) requiere las siguientes características:
- Ser multifuncional, es evidente…. Necesita reunir todos los conocimientos necesarios para analizar el problema, proponer las soluciones, aplicarlas y comunicarlas adecuadamente. En la mayoría de las empresas es impensable un comité que no recoja a personas de TIC, de comunicación, de procesos, etc.
- Ser autónomo en sus decisiones, estar “empoderado” (siento el palabro), porque ¿Se imaginan a un comité de crisis pidiendo permiso para hacer cosas en medio de una emergencia?
- Tener un tamaño capaz de permitir la eficiencia, ergo 5-9 personas
Espacios
La gestión de crisis suele utilizar un espacio físico concreto, la sala de emergencias, dotado de los medios necesarios para que la información llegue, se analice y se remita. Estas salas suelen, al menos deben, de duplicar las vías de entrada y salida de la información, según el tipo de emergencia a tratar (por ejemplo, en un incendio es más que probable que la red interna se pierda y se deba usar otros accesos como modem con tarjetas de datos móviles.
¿Por qué no disponer en la sala de algo parecido a un scrum board? Desde luego, las ventajas de la gestión visual de estos tableros han sido demostradas. Cada ítem puede ser un problema o parte del problema de la emergencia y de ellos derivar las acciones necesarias. Con los clásicos pos-it se puede ir describiendo el avance de cada acción desde el pendiente (to do), lo que está en marcha (doing) y lo acabado (done)
En él se puede ver de un vistazo todo lo que es necesario hacer, en que estado está, como se ha comprobado, quien son los responsables. Se puede construir a mano, pero se puede fotografiar.
De acuerdo que la velocidad puede ser endiablada, pero, puñetas, ¿No hablamos de agilidad?
Planificar
No se puede planificar una emergencia, es un sinsentido, pero una gestión de crisis ágil permite además la realización de ensayos, de simulacros, con mayor eficiencia, porque el scrum board estará ahí delante de todo el equipo, como una foto de grado de desarrollo y de la selección de acciones. Además, no tenemos un product backlog, éste se crea casi al mismo tiempo que el scrum board por la necesidad y urgencia del proceso, pero no tiene una existencia previa independiente.
De alguna manera estos ensayos van o pueden sustituir a la panificación (sprint planning) que en gestión de crisis no tiene sentido (si entiendo una crisis como una situación en la que las medidas normales no son capaces de controlar la situación) El entrenamiento hará posible que el equipo desarrolle a una velocidad adecuada un primer grupo de ítem que ordenará por criterios, estos sí, pre establecidos según su impacto en la emergencia.
“Daily” pasaría a “hour”
Con una fábrica ardiendo no tiene sentido usar un “daily meeting”, pero ¿Por qué no un “hour meeting”? Cada 60 minutos en equipo del comité de crisis, para, se planta durante, por ejemplo, cinco minutos ante el scrum board, y pone en común qué han hecho, que van a hacer y en donde están teniendo los mayores problemas (para elevarlos allá a donde sea necesario)
Esta reunión proporcionaría los mismos beneficios que su antecesor, es decir aumenta la coordinación del equipo, el conocimiento global de la situación y la capacidad de reordenar prioridades y de solucionar problemas, todo ello con una visión “desde fuera”, es decir, desde una posición en la que, a pesar de la catástrofe, el equipo para para mirar y mejorar, aunque sea solo cinco minutos
Revisión
Pierde peso el sprint review, pero no desaparece. El final del sprint es sin duda el cese de la emergencia, pero en ese cese el equipo tiene que presentar sus resultados: que daños se han producido, cuales se han podido paliar cuales no, etc. La revisión la recibirá la dirección o la propiedad, actuando en este caso como propietarios de producto.
La retro
Gana peso, por el contrario, la retrospectiva, en donde el equipo debe de preguntarse ¿Qué hemos hecho bien? ¿Qué hemos mal? Las lecciones aprendidas, la mejora continua es clave en la gestión de crisis precisamente porque las crisis no son procesos continuos, gracias a Dios, y cuando se producen lo principal es salvar los muebles lo primero, y lo segundo aprender, aprender todo lo posible.
Roles
Ya hemos visto que el equipo de desarrollo sería el equipo de gestión de crisis ¿Y quién sería el product owner? Seguramente no podría estar tan presente en el proceso como en un equipo scrum clásico. Coincidiría con la propiedad, a la que equipo de crisis debe reportar, al menos en ultimo extremo (no pedirle permiso) Si bien no contamos con en para el product backlog, pues tampoco existe, si es nuestro cliente de la revisión y en buena parte de la retro.
¿Y el scrum master? Creo que debería de ser un agile coach, con experiencia en seguridad y análisis de riesgos. En mi opinión no debe de ser un miembro del equipo de crisis o al menos no debería estar “sumergido” en la emergencia, para poder tomar la distancia necesaria que le permita aconsejar al equipo en cada momento, pero muy especialmente en los “hour meeting”
Ya estamos todos…. Podemos empezar.
Publicado bajo licencia de Creative Commons en: https://www.eoi.es/blogs/serafincarballo/se-puede-ser-agile-en-gestion-de-crisis-y-emergencias-no-se-puede-se-debe-ser-agile/
