A principios de año empecé a colaborar con el Grupo MASMOVIL, donde tenían el gran reto de escalar agilidad a toda la empresa.
Me gustaría contaros mi experiencia sin rodeos, echando un poquito de prosa quizá pero sin rodeos, y sin mencionar los nombres de mis compañeros, pues no hay rockstars, hay equipos, esto es fundamental. Hay algún hater pero no rockstars.
¿Qué sería de la vida de producto sin un par de trolls y un par de haters que nos reten? Feedback rápido y mejora continua.
Escalar agilidad a toda la organización es una labor titánica a muchos niveles, quizá el reto más grande de todos es escalar agilidad sin perder agilidad.
Entre marcas, procesos, verticales y productos, entre negocio, operaciones y sistemas, entre squads, chapters y tribus, entre toda esta amalgama organizacional lo que prevalece siempre (y no me cansaré de repetirlo) son las personas.
Personas por encima de procesos. Concretamente "Individuos e interacciones sobre procesos y herramientas" dice el manifiesto. Es uno de los valores que nunca se debe olvidar, pues conquistando individuo a individuo, corazón a corazón, se gana el pulso de movilizar una compañía hacia un cambio de mentalidad clave para lograr la transformación.
Indudablemente hubo que trabajar y empujar, no bottom-up, ni top-down, más bien hubo que hacer un bocata de los de toda la vida, empujar desde arriba y desde abajo, con firmeza, paciencia pero sobretodo con perseverancia y mucha ilusión. Este trabajo llevado a cabo por el Chapter Agile y el departamento de Transformación y Metodología ha sido y es, desde la definición de la misión/visión y valores hasta los steercos y las presentaciones a Meini, un camino de constante crecimiento y aprendizaje.
Uno de los aprendizajes que quiero compartir es la herramienta que, en mi opinión, ha favorecido la rápida integración y colaboración con los equipos en la mejora de su productividad diaria desde un enfoque agile y además nos ha permitido en el Chapter tener un roadmap claro de trabajo con palancas y accionables, visibilidad y grado de avance.
Esta herramienta es el Modelo DIAS.
¿Qué es el Modelo DIAS?
El modelo DIAS es una Guía de Actuación para fomentar el proceso de maduración de los equipos buscando mejorar su capacidad de auto-organización generando urgencia comunicando explícitamente que nuestro acompañamiento es temporal.
Cuando trasladamos este mensaje a los equipos hacemos previsible nuestro paso a modo reactivo en el acompañamiento con el objetivo de provocar ese abandono del nido y primer vuelo cuanto antes.
Otro tema para otro artículo es el síndrome del nido vacío que nos queda al verlos volar, hacia el horizonte, tan maduros, tan auto-organizados... nosotros que los hemos visto crecer desde detrás de las cascadas y los gantts.
He buceado mucho hasta encontrar referencias sobre el Modelo DIAS. La primera referencia es un tweet de David Roncero sobre las notas que tomó de la charla del Modelo DIAS en la CAS2016:
De ahí llegué a la propia charla de la mano de Florentino Romero y Cándido Alcaide.
En esta charla, llamada "Modelo DIAS Hacia la autonomía en la persona y en los equipos", nos cuentan cómo funciona este modelo emergente y nos trasladan la importancia de dos objetivos (obsesivos) clave para los agentes del cambio: transformar y desaparecer.
El primero es obvio, el segundo no lo es tanto, pues es frecuente encontrarnos con equipos de transformación que acaban convirtiéndose con el tiempo en departamentos vinculados a los mismísimos cimientos de la compañía por los siglos de los siglos.
Este modelo permite saber si nos estamos acercando o alejando de estos objetivos, nos va a permitir adaptar nuestras relaciones para acercarnos a los equipos y conocer en qué punto estamos aportando valor a la organización y en qué punto.
Nos cuentan que es un modelo emergente que han experimentado trabajando con equipos, organizaciones y personas. Florentino y Cándido nos animan además a pensar en este modelo no sólo desde un punto de vista laboral relacionado con nuestro propio sistema en nuestra propia organización, sino también desde el plano personal.
En esencia el modelo DIAS no sigue un patrón de transformación para empresas únicamente, puede ser un modelo usado por personas en su ámbito personal.
En la charla exploran cada una de las fases que componen el modelo cuyas iniciales forman el nombre: Descubrimiento, Inmersión, Acompañamiento y Supervisión. Más que contaros ahora qué dicen Cándido y Florentino sobre estas fases, os voy a contar cómo en el Chapter Agile del Grupo MASMOVIL lo hemos adaptado y cuál ha sido mi experiencia.
¿Cómo usamos el Modelo DIAS?
El modelo que proponían Florentino y Cándido no dejaba de ser una aproximación experimental que estaban iterando y cambiando, como una estructura básica desde donde empezar a trabajar. Hablando con mi compañera y Chapter Lead, Claudia Bravo, sobre cómo llegamos al modelo tal y como lo conocemos hoy me explicaba el contexto:
Florentino y Cándido hablan de las fases pero no tenían hitos marcados, por lo que era difícil saber cuándo avanzar. La necesidad que teníamos estaba más orientada a los hitos y objetivos que ahora tenemos en cada fase, no tanto el modelo en sí.
Antes de definir nuestra versión del modelo, cuando hablábamos del equipo al que estábamos ayudando nunca sabías realmente bien en qué fase nos encontrábamos, así que según avanzaba el tiempo nos decíamos “ya estaremos en acompañamiento, ¿no?" Finalmente dejamos de usarlo.
Cuando empezamos a crecer como área de transformación y a trabajar a nivel de compañía, nos dimos cuenta de qué necesitábamos. En los steercos el feedback sobre el acompañamiento se interpretaba y siempre nos decían “pero, ¿cuánto tiempo estáis con ese equipo? Por lo que quisimos hacer algo que nos facilitara en ese sentido:
1. Dar visibilidad objetiva a nivel de dirección.
2. Ayudar al Chapter a tener pequeños objetivos para avanzar con los equipos.Muchas veces era difícil encontrar el punto de salida, llevando a los equipos sin un horizonte claro. Ahí, pensando en los pequeños objetivos, recuperamos la estructura del Modelo DIAS, las fases nos parecían acertadas, salvo la última que nos parecía demasiado “waterfall” y la cambiamos por seguimiento. ;-)
Esta adaptación se puso al servicio de todos los tipos de equipos diferentes en la casa con un espíritu constructivo-evolutivo.
Lo hicimos transparente a los equipos con los que trabajamos desde el primer minuto para trasladar esa temporalidad (flexible pero finita), el roadmap de trabajo, el punto del roadmap en el que se encontraban y que era necesario para avanzar a la siguiente fase.
Es importante decir que los tiempos marcados son aproximados, cada equipo tiene sus propias necesidades y se trabaja de forma personalizada.
No es importante el número de semanas o meses, lo importante es que exista una temporalidad, que se haga transparente y adaptarnos según el contexto y las circunstancias llegar a esos tiempos o que esos tiempos lleguen a nosotros.
Otro de los aspectos más importantes a destacar antes de profundizar en cada una de las fases del modelo, es conseguir hacerlo cuantificable, medible para, desde un punto de vista analítico, establecer un grado de madurez a los equipos y así tener un atlas a ojo de halcón de todos los equipos de componen la compañía.
Esto se ha conseguido introduciendo los roadmaps de trabajo de cada equipo en Jira con un tablero básico de forma que al avanzar y documentar el estado de los hitos se establece un porcentaje de madurez respecto a las expectativas de la compañía.
Como veremos a continuación, cada fase se compone de una serie de hitos generales definidos que adaptamos a los equipos.
Después, entre cada fase existe una transición con un checklist que nos permite comprobar con el equipo si estamos o no preparados, si nos sentimos cómodos, para avanzar a la siguiente fase. Para ello también tenemos una serie de assesments que hacemos de forma personal e individual a los miembros del equipo.
Descubrimiento (acercarnos)
En esta fase se pretende entender y coger contexto del equipo, además de entender y conocer los puntos de dolor del equipo. Por otro lado, trabajamos en "quick-wins" que permitan ir ganando la confianza de dicho equipo.
El tiempo estimado es de 2 semanas (una vez más: flexible pero finito).
En el descubrimiento entramos como cuando sale un gato que sabe que ha hecho algo mal, despacio y sin llamar la atención, asistiendo a los eventos, observando las dinámicas, comportamiento del equipo, conociendo a cada miembro y sus relaciones, sus procesos, despliegues, tableros, etc.
Además, en esta fase es importante comenzar a generar confianza conociendo cuáles son su puntos de dolor y ejecutar al menos un Quick-Win, como puede ser un tablero en torno al que hacer la daily si estas son largas y sin objetivo, o creando un proyecto en Jira con filtros para ver avances y que entiendan que tienen wip antes de empezar algo nuevo cuando hay mucha gente diferente trabajando en proyectos sin visibilidad del progreso.
Además, identificamos formaciones necesarias en el equipo y hacemos un evento de tipo kick-off si el equipo es de nueva formación.
Para poder realizar la transición hacia la Inmersión es necesario validar lo siguiente: ¿Hemos empezado a facilitarles los eventos?
¿Estamos planteando preguntas que les ayuden a focalizar y a replantearse cambios? ¿Hemos realizado los assesment y les hemos mostrado los resultados de las primeras mediciones? Si la respuesta a todas las preguntas es afirmativa, ¡avanzamos!
Inmersión (yo lo llevo)
En esta fase ya empezamos a formar parte de sus vidas. Hemos introducido una forma de trabajar acorde a sus necesidades pero siempre pensando en los principios ágiles.
Tenemos suficiente confianza con ellos como para que entiendan que estamos ahí para ayudarles y que los cambios que vamos a proponer les van a ayudar en su trabajo diario. Además damos ejemplo en la aplicación de dichos principios en el día a día.
El tiempo aproximado en esta fase es de 2 meses.
Facilitamos los eventos que tenga el equipo y les proponemos aquellos eventos de su metodología favorita que no estén usando y que creemos les pueden ayudar.
Analizamos con ellos si las reuniones a las que acude el equipo aportan o no aportan valor, y les ayudamos a integrar principios de reuniones eficaces.
Les ayudamos a que sus interacciones con los demás sean prácticas y directas (en muchos casos creando espacios o foros de comunicación para que la gente implicada pueda tener contacto directo).
Medimos si los cambios son de ayuda y si no podemos medir disponemos de assesments y feedback.
Generamos cambio cultural hacia la mejora continua, la transparencia y poner foco en cerrar cosas antes que abrir.
Trasladamos al equipo la información y contexto sobre el modelo de escalado que seguimos, el modelo operativo y de negocio de la compañía (estrategia, organización, OKRs).
Si creemos que podemos transicionar hacia la siguiente fase y el equipo se siente cómodo, reflexionamos sobre lo siguiente:
¿Hemos dejado de ir algún día a las dailies y hemos comprobado que ellos se autoorganizan? ¿Hemos dejado de dirigir las dinámicas, de hablar en los eventos y al dar feedback lo hemos hecho después del evento? ¿Les estamos compartiendo los resultados de lo que vamos midiendo sobre los puntos de mejora aplicados?
En caso afirmativo, go go go!
Acompañamiento (vamos juntos)
Cuando llegamos al acompañamiento es porque el equipo ha adquirido ciertos hábitos y ha interiorizado los principios ágiles como parte de sus vidas, y por ello ya podemos ceder el testigo.
La idea es que o bien alguien del equipo asuma el rol de facilitador o bien el rol se reparta en el equipo, y que nosotros todavía estemos en sus vidas pero desde las gradas.
Aquí la principal labor es dar feedback y ayudar a que los nuevos hábitos adquiridos no se pierdan.
El tiempo aproximado en esta fase es de 1 mes.
En esta fase nos enfocamos en ceder el testigo de la facilitación de eventos a alguien del equipo, dar feedback de las cosas que vemos pero siempre desde la barrera (les guiamos para que los nuevos hábitos no se pierdan), seguir midiendo para seguir empujando la mejora continua y hacer coaching al equipo.
En esta fase ya hay suficiente confianza como para que el equipo entienda que muchos de los puntos de dolor o bien ya se han corregido, o tienen que seguir pensando que se pueden cambiar, o bien el problema está en ellos mismos y hacemos sesiones individualizadas.
Transicionar hacia la última fase requiere, al menos, ir muy de vez en cuando a los eventos (vamos desapareciendo casi sin que se den cuenta), feedback enfocado a cada persona del equipo, y pedir al equipo que nos enseñen los resultados de lo que se va midiendo.
Seguimiento (sigue tú)
En lugar de supervisión, como proponían Cándido y Florentino en la charla, nosotros nos hemos bajado al terrenos de los mortales, sin superpoderes, y lo llamamos Seguimiento.
En esta fase ya el equipo no nos necesita y puede que sea incluso cuando más nos quieren, al mismo tiempo es el momento en que los principios de verdad han calado en el equipo y ellos mismos van a seguir trabajando en mejorar su propio equipo.
Es la fase Reactiva.
Aquí ya quedamos como persona de referencia cuando tienen alguna duda o necesitan algo concreto. También revisamos cada cierto tiempo que no se ha perdido la inercia y seguimos midiendo la mejora continua del equipo, aunque en este caso se autoevalúan.
Esta fase va desde 2 semanas hasta infinito, pues al quedar reactivos y ser referentes pueden o no necesitarnos y deben saber que estamos ahí, en algún lugar, orgullosos de nuestros polluelos.
Por último, documentamos el proceso para mostrar los casos de éxito dentro del atlas de la compañía.
Mis conclusiones usando el Modelo DIAS
Mi experiencia con este modelo ha sido totalmente enriquecedora. Al tener una perspectiva más operativa, secuencial, casi como un algoritmo, se puede seguir desde un punto de vista analítico el crecimiento y la evolución de los equipos, algo que caía siempre del lado cualitativo, y ver cómo se van iluminando en el atlas los equipo que alcanzan la madurez y auto-organización.
En este caso se produce un efecto cadena de montaje adaptativa que permite ayudar al mayor número de equipos, en el menor tiempo, desde la necesidad del equipo sin perder la importancia y el valor que aporta cada persona.
Ahora os pregunto, ¿cómo podría ayudarnos este modelo desde un mindset de producto? ¿Quizá a la hora de incorporarnos como Product Managers como consultor?
¿Quizá como nuevos Product Managers a la hora de conocer al equipo de producto y el estado del producto en el que no hemos participado desde su creación? Incluso, ¿quizá a la hora de evolucionar desde un rol de Product Manager a uno de Lead Product Manager?
Todo esto claro está, desde mi punto de vista. ¿Qué opináis?
Para saber más: descarga el libro Agile Product Management
Foto de Will H McMahan en Unsplash
