Esta semana he perdido ritmo con la bitácora. Sin embargo, el martes comenté algo que creo que merece traer al blog con más detalle. Se trata de un taller con el que los equipos de las apps nativas de eDreams ODIGEO y yo probamos a diseñar la hoja de ruta que vamos a seguir juntos. En este artículo voy a describir el taller y mis conclusiones, tanto sobre mi experiencia ejecutándolo como sobre el propio proceso de diseño.
Descripción del taller
Voy a describir el diseño de este taller por si te interesa reproducirlo y compartir conmigo tu experiencia.
Objetivos
- Que los asistentes decidan cuáles deben ser los objetivos a medio y largo plazo para su propia transformación ágil.
- Que los asistentes reconozcan los cambios ya realizados hasta la fecha.
- Que los asistentes decidan cuáles deben ser las siguientes acciones de mejora que deben suceder en el corto plazo y las prioricen.
- Que los asistentes se comprometan en la ejecución y seguimiento de esas acciones de mejora.
Introducción
Durante las dos horas del taller trabajamos en cuatro áreas estratégicas que yo mismo elegí durante el diseño del taller:
- «Construir lo correcto» (el clásico «Build the right things»), en la que pretendía agrupar todas aquellas conversaciones relacionadas con los procesos de desarrollo de producto y que surgieran conceptos como User Story Map, Lean Startup, etc.
- «Construir correctamente» (el «Build the things right»), en la que trataba de que pensaran en prácticas de ingeniería, tipo TDD, código limpio, microservicios, etc.
- «Mejora continua», con la que deseaba que se centraran en mejorar las prácticas de Kanban que están haciendo actualmente,
- y finalmente «Alegría y Compromiso», en la que esperaba que encontraran fórmulas para fortalecer el espíritu del equipo. En mi cabeza resonaban referencias a las 5 disfunciones de un equipo o cosas por el estilo.
Como facilitador del taller y como Agile coach de estos equipos, intenté influir lo menos posible en lo que yo esperaba que sucediera, pero mi tendencia natural al control me empujó, en varias ocasiones, a dar algo más que pistas sobre mis preferencias. No debería sentirme culpable, al fin y al cabo el mundo está girando hacia los autoritarismos.
Pasado y futuro
Para empezar planteé una dinámica en la que los asistentes debían explicitar los cambios que han sucedido en los últimos meses. El objetivo era, por un lado, que pudieramos hablar, con ejemplos concretos, sobre el significado de las diferentes áreas. Por otro lado, quería poder referirme más tarde a un proceso de mejora continua que ya comenzó hace meses, y para el cuál no hemos tenido un plan explícito. De esta manera pretendía adelantarme y desactivar las resistencias a seguir planes incompletos.
Esto último lo reforcé pidiéndoles que completaran la historia con aquellos cambios que deberían suceder durante el próximo año. El resultado fue una numerosa nube de ideas, cada una de ellas una oportunidad de mejora para el grupo.
NOTA: En este punto debería haberles preguntado sobre fortalezas e impedimentos, pero el tiempo se me estaba echando encima y decidí prescindir de ello. Así que pasé directamente a explicarles que lo que tenían en la pared era casi un plan. Les hablé del User Story Mapping y cómo estabamos a punto de hacer algo muy parecido. Las ideas más factibles y que aportaban más valor eran las que estaban más cerca en el tiempo, mientras que las menos factibles, más difusas y que quizás no estaba claro que aportaran valor estaban más lejos. De hecho, la mayoría de las que estaban lejos eran apenas deseos.
En la pared teniamos una narrativa visual que hablaba del pasado y del futuro del grupo. Lo mejor de todo es que esa historia la habían escrito entre todos los presentes. Ahora sólo quedaba hablar de lo que debe ocurrir a partir de ahora.
Llamada a la acción
Entonces les pedí que, por grupos, hicieran propuestas (cuantas más mejor) con la siguiente estructura:
- Título descriptivo del cambio que proponen.
- Escenario de partida: es la situación que queremos cambiar.
- Escenario deseado: centrándose en el qué y no en el cómo.
- Voluntarios. De momento sólo uno.
A continuación les instigué para que «vendieran» las propuestas a sus compañeros y que las hicieran atractivas, porque si no conseguían al menos un voluntario que les acompañara, la idea no pasaría a ser un experimento para la mejora. Sí, llegados a este punto les expliqué que debemos tratar estas acciones de mejora como experimentos; de esta manera les pretendía programar las neuronas para que a partir de ahora no tengan miedo a obtener resultados inesperados.
Además, les pedí que aclararan cuál debía ser mi nivel de implicación en cada uno de los experimentos, si acaso me necesitaban para algo. Utilicé el modelo Shu-Ha-Ri pero creo que no funcionó bien. Etiquetar un experimento como Shu implicaba que necesitaban mi ayuda como mentor y ellos se comprometían a probar lo que yo les propusiera. Ha significaba que probarían ideas de otras fuentes, y que apenas me necesitaban como profesor y coach. Las acciones etiquetadas como Ri implicarían que apenas me necesitarían como coach. Francamente, creo que esto no funcionó. Al menos no como esperaba. La mayoría se limitaba a decir si me necesitaban o no, y para qué en particular. Tendré que estar atento por si es necesario redefinir mi implicación.
Conclusiones
Sobre el diseño
La motivación original para diseñar este taller surgió de los propios miembros de los equipos. «Ya hemos recibido la formación inicial, creado los equipos y puesto en marcha unos procesos básicos de trabajo. ¿Y ahora qué? ¿Cuáles son los siguientes pasos?»
Estuve valorando diferentes enfoques. Desde luego, de entrada descarté darles un plan diseñado por mí mismo, como por ejemplo un modelo de madurez o algo similar. Podría aceptar usar un modelo de madurez como éste para un área muy concreta, como el aprendizaje de Kanban, tal y como están haciendo muchos de los equipos de eDreams ODIGEO, pero no lo veo útil (sino contraproducente) si hablamos de incorporar la mentalidad Lean y Agile a un grupo. Si lees sobre Cynefin (la primera parte de este artículo de Martín Alaimo se explica muy concreto y muy fácil de entender), verás que éste no es un problema del dominio de lo complicado sino del dominio de lo complejo. Como bien explica Jerónimo Palacios en este articulo, para resolver los problemas en el dominio de lo complejo debemos «Probar, Percibir y Responder». O en un lenguaje más Agile: Inspeccionar y Adaptar.
Así pues, decidí facilitar que ellos diseñaran su propio plan. Para esto decidí que debía usar alguna técnica similar a la que usamos para planificar el desarrollo iterativo e incremental de nuestros productos. User Story Mapping resonaba todo el rato en mi cabeza. Mi mayor inconveniente en este punto era pensar en qué debían escribir los participantes del taller en esos post-its. Todo el rato pensaba en ofrecerles opciones: una nube infinita de opciones era mi ideal. Hasta que en un conversación con otra Agile coach, Maica Trinidad, di con la clave: ellos debían encontrar, en la medida de sus conocimientos y necesidades, las acciones que debían formar parte de ese plan. Luego, con el feedback recibido al poner el plan en práctica, tendremos oportunidad de replanificar. Igual que cuando planificamos el desarrollo de cualquier producto: no sabemos bien lo que puede ser necesario hacer y ni siquiera si sabremos hacerlo cuando llegue el momento. Inspeccionar y Adaptar. Genial.
Sobre la ejecución
Curiosamente, no conseguí seguir mi plan y no tiene pinta de que hayamos conseguido algo que se pueda llamar «hoja de ruta». Sin embargo, estoy satisfecho y sorprendido por el resultado.
Satisfecho porque hemos salido con un backlog magnífico, y en algunos casos ambicioso, con varios experimentos para la mejora y grupos de voluntarios comprometidos con sacarlas adelante. El éxito está asegurado. Entendiendo por éxito que ejecutaremos los experimentos y aprenderemos de ellos. Para ello pretendo usar A3 Thinking. El objetivo es que ellos mismos vayan practicando la técnica y, llegados al punto, comiencen a usarla sin ayuda, e incluso prueben a usar otras, como Improvement Kata, Story Telling Canvas, etc.
Estoy sorprendido porque el proceso que ha quedado como resultado es extraordinariamente parecido al que hace un par de años traté de que fuera adoptado por parte del management de ING Direct España. Lógicamente, el contexto aquí es muy diferente. Trataré de trabajarlo un poco y compartirlo de manera más estructurada.
Como siempre, cualquier comentario será más que bienvenido.