El pasado 12 de febrero facilité una sesión ejecutiva de la simulación The Phoenix Project en conjunto con ClickStudio en Bogotá. Para esta sesión quisimos contar con una audiencia muy variada para que la sesión fuera lo más enriquecedora posible para los participantes al formar un equipo multifuncional (con los diferentes roles del juego/Parts Unlimited) y multidisciplinario (con participantes de diferentes áreas de sus respectivas organizaciones). Así, invitamos a participar a personas con roles/cargos en las siguientes áreas:
Dirección (gerencia general, administrativa, mercadeo).
PMO y gerencia de proyectos.
Transformación digital, innovación, DevOps.
Infraestructura y operaciones de TI.
Cambio organizacional.
La simulación The Phoenix Project es un ejercicio que nació como un medio para que los participantes pudieran experimentar con conceptos, técnicas y métodos de DevOps y entender como llevarlos a la práctica para facilitar su adopción en sus respectivas organizaciones. La simulación permite también que los participantes puedan evidenciar la necesidad y los beneficios de colaborar, comunicarse efectivamente, trabajar en equipo (multifuncional), visualizar el trabajo, mejorar el flujo/la fluidez de trabajo, centrarse en el cliente, experimentar y mejorar continuamente, etc., desarrollando competencias en estas áreas, competencias que son necesarias no solo para la adopción de DevOps sino también para otros contextos como la transformación digital, la agilidad escalada, la agilidad en el negocio y el método Kanban.
Como se describe en este post, la simulación se desarrolla en cuatro rondas en las que los participantes se ven enfrentados a una demanda cada vez mayor y más variada que deben priorizar y atender mientras intentan sacar adelante el proyecto Phoenix para lograr mejorar la salud y los indicadores financieros de Parts Unlimited.
La primera ronda de la simulación es una ronda de prueba para que el equipo entienda y practique la dinámica del ejercicio a través de unos pocos proyectos asociados al proyecto Phoenix y de talento humano. Esta ronda resultó en un pequeño caos, como es de esperarse, por el desconocimiento de la dinámica. En esta ronda cada participante se enfocó en su rol y no en el flujo, apareciendo los silos que dificultaron la comunicación y la colaboración por lo que el equipo tuvo dificultad para entender y priorizar toda la demanda presentada, resultando en poca atención a las iniciativas del negocio y en foco en el trabajo operativo. Hacia el final de la ronda el equipo introdujo el tablero kanban para visualizar y controlar el trabajo pero esto tuvo poco impacto en el resultado final. Una vez terminada la primera ronda se realizó la reflexión/retrospectiva de la ronda, en la que el equipo expuso sus dificultades, aciertos, observaciones, recomendaciones e iniciativas para mejorar. Este espacio de reflexión también permitió aclarar la dinámica del juego, aclarar e introducir algunos conceptos base de DevOps y dar respuesta a preguntas como ¿qué es DevOps?
Las siguientes rondas se ejecutaron siguiendo el ciclo de mejorar-planear-hacer-reflexionar, aprovechando las reflexiones para que el equipo discutiera qué hicieron bien, qué debían dejar de hacer, qué debían seguir haciendo, qué debían comenzar a hacer y qué debían mejorar. Las reflexiones también abrieron el espacio para introducir y discutir conceptos, métodos y técnicas de DevOps (según las 3 vías, por ejemplo) y de métodos conexos como el método Kanban y, de ser el caso, como estos eran útiles para la transformación digital y para la adopción de nuevas formas de trabajar en contextos de agilidad escalada y agilidad del negocio. Como resultado de la aplicación de estos ciclos durante las rondas dos a cuatro, el equipo se fue consolidando como un equipo multifuncional con responsabilidad de extremo a extremo y comenzaron a surgir patrones y comportamientos asociados a competencias claves para el éxito de las transformaciones DevOps, como por ejemplo:
Product Owner: Operaciones de Retail y Talento Humano asumieron el rol una vez identificada la necesidad de contar con un rol encargado de la construcción y priorización del backlog durante la reflexión de la primera ronda.
Reuniones "stand-up": aparecieron de forma espontánea cuando los Product Owners estaban organizando el backlog en el tablero durante la segunda ronda y los participantes comenzaron a acercarse a colaborar con ellos.
Visualización del trabajo: el primer tablero se construyó en la primera ronda y luego fue mejorando y tomando mayor importancia durante las siguientes rondas. La última ronda prácticamente se realizó por completo frente al tablero donde el equipo podía ver todo el trabajo pendiente, priorizarlo y controlar su ejecución. Adicionalmente, sirvió como punto central para las reuniones "stand-up" al inicio de las rondas tres y cuatro.
Experimentación y aprendizaje: el equipo realizó experimentos con varias formas de visualización en el tablero, iterando con base en la retroalimentación y el aprendizaje, manteniendo/mejorando lo que estaba funcionando bien y cambiando aquello con lo que no se sentían cómodos, les dificultaba el trabajo o no daba los resultados esperados.
Orquestación: durante la segunda ronda el equipo de pruebas comenzó a utilizar el checklist de pruebas y el tablero como medio para orquestar y controlar el trabajo del equipo.
El Cordón de Andon y "swarming": en la tercera ronda se presentó un asunto que afectaba considerablemente el flujo por lo que Operaciones de Retail "tiró del cordón", paró el trabajo y concentró a todo el equipo en la resolución.
Mejora continua y mentalidad kaizen: además de experimentar la mejora continua a través de las reflexiones al finalizar cada ronda, el equipo también comenzó a mejorar la forma de trabajar con pequeñas acciones durante la ejecución de las rondas.
Liderazgo: se presentó de forma natural a través de los Product Owners quienes asumieron el liderazgo del backlog y de la priorización y a través del equipo de pruebas que tomó el liderazgo del tablero y del control del flujo.
Trabajo en equipo y colaboración: durante las rondas dos a cuatro el equipo fue tomando cada vez más conciencia del flujo y de la necesidad de trabajar como un solo equipo, eliminando los silos e incrementando la colaboración.
Foco en los resultados y objetivos compartidos: en la medida que se avanzaba en el juego y se afianzaba el trabajo en equipo, la priorización se fue orientando cada vez más a los resultados de negocio, discriminando el tipo de trabajo en "swim lanes" del tablero y decidiendo qué trabajo debía sacarse adelante con base en el impacto que generaba en los resultados del negocio. Esto abrió el espacio, por ejemplo, para sacar adelante trabajo táctico de talento humano que luego permitía mayor ejecución de trabajo de valor (proyecto Phoenix) e implementar el concepto de clases de servicio según el método Kanban: el equipo identificó un tipo de trabajo que debía acelerarse y estableció una "swim lane" en el tablero para este tipo de trabajo al que llamaron "fast track".
Evidenciar y discutir todos estos patrones y comportamientos durante las reflexiones y las actividades de cierre, permitió que se cumplieran los objetivos generales de la simulación dado que los participantes tuvieron la oportunidad de aprender y experimentar como:
Aplicar los principios de DevOps a un situación de la vida real.
Encontrar el balance adecuado entre cumplir con los SLA y sacar adelante los proyectos de TI de acuerdo a lo planeado.
Generar beneficios y valor para el negocio a través de DevOps.
Incrementar la eficiencia y la efectividad del departamento de TI en la producción del valor al negocio.
Crear un mejor flujo de trabajo en los equipos.
Desarrollar habilidades en el personal para que se desenvuelvan con éxito en un entorno DevOps como parte de un equipo multifuncional con responsabilidad extremo a extremo.
Mostrar al negocio cuál es su rol y cuáles son sus responsabilidades en lograr que los proyectos de IT derivados de las iniciativas del negocio sean exitosos.
Al cierre de la sesión, como acostumbro hacer, pasé una encuesta a los participantes para que me dieran, desde su perspectiva, cuáles habían sido los cinco aprendizajes más importantes de la sesión. A continuación listo algunos de ellos:
Para que las intenciones de transformación generen los resultados esperados, es necesario alinear a cada uno de los frentes involucrados con el fin de comunicar las expectativas de negocio y sincronizar las actividades conforme a la priorización.
Es clave orquestar las acciones para traducir las necesidades y los objetivos del negocio en acciones de TI.
La visibilidad transversal en los distintos niveles organizacionales ayuda a que los equipos estén alineados hacia un mismo objetivo.
La comunicación y la colaboración son esenciales y factores claves en el logro de resultados del negocio.
La importancia de la mejora continua como parte de la cultura de la empresa y de los colaboradores.
La importancia de lograr equipos multifuncionales unificados que tengan el mayor contexto posible sobre objetivos, retos y roles.
Colaboración no es lo mismo que cooperación.
La importancia de visualizar el trabajo, controlar el WIP y gestionar las capacidades (de trabajo).
Para cerrar, respondo a una pregunta que dejó uno de los participantes a modo de reflexión en la encuesta de cierre: ¿cómo hacer que la cultura DevOps sea parte del ADN organizacional, si el día a día absorbe a los líderes de negocio y no dan el ejemplo que corresponde?
Fácil: hagan como hizo Operaciones de Retail, tiren del cordón, hagan un alto en el camino, e inviten a los líderes a participar en una sesión de la simulación! :o)... y si necesitan contar con mas respaldo para conseguir el espacio de participación de los líderes, permitan que Christian Klug (Gerente General de Procalidad) y Alejandro Muñoz (Director Corporativo de Mercadeo de DISAN SA) les cuenten sobre su experiencia durante la simulación:
Christian Klug, Gerente General de Procalidad.
Alejandro Muñoz, Director Corporativo de Mercadeo de DISAN SA.