El pasado 21 de noviembre facilité la primera sesión de la simulación The Phoenix Project en Colombia. El evento fue patrocinado por Kessel Pok, ClickStudio y GFI Colombia y contó con la participación de funcionarios de TI y del negocio de empresas de los sectores salud, finanzas, servicios y logística que están llevando adelante iniciativas de DevOps, están preparándose para adoptar DevOps o están evaluando si DevOps es una alternativa viable para ellos.
La simulación
El contexto del ejercicio es el mismo del libro homónimo en el que está basado: los participantes asumen roles en Parts Unlimited, una empresa automotriz en serios problemas financieros, y deben sacar adelante el "Proyecto Phoenix" que es un programa de transformación empresarial habilitado por TI y crítico para que la empresa vuelva a ser competitiva y rentable. Los participantes de la simulación pueden ocupar roles de TI (pruebas, operaciones, desarrollo de aplicaciones, etc.) o del negocio (Operaciones de Retail - dueño del "Proyecto Phoenix", Talento Humano y Finanzas) de Parts Unlimited.
La sesión
En la sesión tuvimos la oportunidad de contar con representantes de unidades de negocio de las empresas participantes, de manera que aprovechamos para asignarles los roles de negocio de Parts Unlimited. El resto de participantes eran todos del área de TI y se les asignaron los roles de TI.
En la simulación los participantes experimentaron, en cuatro rondas, los beneficios que DevOps puede traerle a sus respectivas organizaciones. En la medida que se avanzaba en el juego, los participantes se fueron enfrentando a una demanda cada vez mayor (proyectos, iniciativas, problemas, etc.) que con frecuencia entraba en conflicto con el "Proyecto Phoenix". Cada ronda comenzó con la introducción de tareas y proyectos que se debían ejecutar durante la ronda y de herramientas que podían ser útiles al equipo para terminar la ronda de forma exitosa. Al finalizar cada ronda se facilitó una actividad de reflexión para que el equipo analizara los resultados de la ronda y su desempeño durante la misma e identificara oportunidades e iniciativas de mejora que debía implementar al inicio de la siguiente. Al finalizar la cuarta ronda, además, se extendió la reflexión a los aprendizajes de la sesión.
La primera ronda inició con un caos, los participantes comenzaron actuando de forma independiente y concentrados en las tareas individuales, lo que se tradujo en silos entre TI y el negocio y dentro del grupo de TI. Operaciones de TI, desarrollo, pruebas y negocio se dedicaron a sacar sus tareas por aparte, por ello, durante la reflexión, los principales temas a considerar para la mejora fueron trabajo en equipo, comunicación, colaboración y visualización; además decidieron implementar reuniones stand-up y un rol de facilitador/orquestador.
En la segunda ronda comenzó la experimentación con DevOps; el objetivo de esta ronda fue poner en práctica la primera vía de DevOps, por tanto, se hizo énfasis en el flujo de trabajo y se introdujo el tablero Kanban como herramienta de gestión. Al inicio de esta ronda el equipo implementó mejoras en las áreas identificadas al final de la ronda anterior, lo que arrojó como resultado que mejorara el trabajo en equipo, la comunicación y la colaboración dentro de TI para sacar trabajo adelante con base en los SLA, pero TI y el negocio se mantuvieron como silos apartes. La comunicación entre TI y el negocio fue limitada, el negocio comunicaba a TI sus proyectos e iniciativas y TI, eventualmente, solicitaba ayuda al negocio en la priorización; la colaboración entre TI y el negocio fue prácticamente inexistente. Al finalizar la ronda quedó en claro el impacto del trabajo en silos: hubo poco avance en el "Proyecto Phoenix" y cayeron tanto los ingresos como el precio de la acción. Durante la reflexión, el equipo evidenció lo importante de mantener un buen flujo y como herramientas visuales, tales como el tablero Kanban, pueden ayudar a mejorarlo. Las áreas de trabajo identificadas para mejorar en la siguiente ronda fueron: tablero Kanban, establecer un canal de comunicación con el negocio, construir y priorizar un backlog, utilizar el checklist de pruebas como medio de control para la liberación, organizar mejor al equipo de trabajo y publicar los requerimientos.
En la tercera ronda el equipo experimentó la segunda vía de DevOps y por tanto se resaltó la importancia de la retroalimentación. Al comenzar la ronda, al igual que en la anterior, se implementaron las mejoras pero lamentablemente ésta resultó ser la peor ronda para el equipo porque no lograron explotar los beneficios de la retroalimentación y, aún cuando implementaron un canal de comunicación con el negocio, se mantuvieron los silos: el negocio no participó en las reuniones stand-up, TI siguió enfocado en sacar trabajo adelante prestando atención solo a los SLA, el canal de comunicación con el negocio solo sirvió para que el negocio comunicara más rápido sus requerimientos y para que TI informara del avance o solicitara ayuda con la priorización, el backlog estuvo bajo control de TI y no hubo proactividad del negocio en la priorización. Como era de esperarse, en esta ronda no solo no se lograron los objetivos sino que empeoraron: la utilidad y el precio de la acción cayeron aún más y el "Proyecto Phoenix" sufrió más retrasos. Durante la reflexión se hizo evidente que el flujo había empeorado y que los beneficios que esperaban obtener con las mejoras implementadas no se materializaron por mantener los silos, así que para la siguiente ronda decidieron, además de explotar las mejoras ya implementadas, trabajar en reforzar la comunicación y el trabajo en equipo, aprovechar mejor las competencias del equipo, integrar al negocio en las reuniones stand-up, darle el control del backlog al negocio y lidiar con un cambio imprevisto en el equipo con la salida de uno de los participantes por situaciones personales. Algunos participantes, además, reconocieron que les resultaba natural trabajar en silos porque esa era la forma en la que se trabajaba en sus respectivas empresas.
En la cuarta y última ronda el equipo debía experimentar la tercera vía de DevOps, sin embargo, como era poco probable que se lograra mejorar los resultados alcanzados hasta el momento, enfocarnos en la tercera vía hubiese puesto en riesgo el logro del objetivo principal del juego que es experimentar y aprender DevOps. Además, de no lograr experimentar como las técnicas de DevOps aplicadas al juego podrían llevarnos a lograr mejores resultados de negocio, pudo haber dejado en los participantes la sensación de que DevOps no era para ellos o una sensación de frustración por haber perdido el tiempo en una actividad poco provechosa. Por esta razón, el foco de la introducción a la cuarta ronda estuvo en implementar las mejoras identificadas y explotar lo aprendido en las rondas 2 y 3. De esta forma, al inicio de la ronda el equipo se centró en mejorar y potenciar el tablero Kanban, en romper los silos y dar al negocio el control de la priorización del backlog, en enfocarse en los resultados de negocio en vez de los SLA y en ejecutar como un solo equipo multifuncional. De esta forma, el negocio tomó un rol fundamental en las reuniones stand-up y en priorizar el backlog con base en los resultados esperados lo que llevó a solo realizar aquella tareas que tuvieran el mayor impacto en el avance del "Proyecto Phoenix" y en los resultados financieros. Durante la ejecución el equipo prestó atención al flujo y a la retroalimentación para asegurar que avanzaban de forma fluida y acorde a las expectativas del cliente (el negocio) cuidando el trabajo en curso y las capacidades del equipo y utilizaron los scripts de prueba para gobernar las liberaciones. El resultado de aplicar estas mejoras se vio reflejado en los resultados del negocio: se logró liberar el 80% del "Proyecto Phoenix" lo que significa que se duplicó la capacidad de producción (al final de la tercera ronda se había logrado liberar menos del 40% del proyecto) y tanto la rentabilidad como el precio de la acción subieron un poco más del 220% con respecto a la ronda anterior. Al finalizar la ronda el equipo estaba "energizado" por la (impresionante) mejora experimentada y la reflexión se centró en los resultados obtenidos y en el impacto marcadamente positivo que estar centrado en los resultados del negocio, trabajar como un solo equipo, aplicar técnicas DevOps y trabajar con una mentalidad DevOps, tiene en los resultados del negocio.
El resultado
Aunque el equipo no logró sacar adelante el "Proyecto Phoenix" (que no es una tarea fácil dada la cantidad de asuntos que tienen que manejar) ni alcanzar los resultados financieros esperados, si pudieron experimentar y aprender como la adopción de DevOps puede generar beneficios en las organizaciones y en general pudieron:
Explorar y experimentar la esencia de DevOps.
Entender los aspectos culturales y de comportamiento relacionados con trabajar en un entorno DevOps.
Descubrir como DevOps puede ayudar a los equipos de trabajo a ser más eficientes y efectivos.
Experimentar como “implementar” los principios de DevOps en su propia organización.
Explorar los factores críticos de éxito para la adopción y el despliegue de DevOps.
Al finalizar el día, como parte de la reflexión final, se le pidió a los participantes que respondieran una encuesta de cierre que incluyó la pregunta ¿cuáles son los cinco aprendizajes más importantes de esta sesión? Entre sus respuestas, resaltan las siguientes:
El negocio y TI deben tener una excelente comunicación.
Todos debemos conocer la prioridad del negocio.
El éxito de los proyectos está ligado al trabajo en equipo TI-negocio.
Utilizar equipos multifuncionales facilita el logro de los objetivos.
DevOps no es solo automatización, se debe poner énfasis en la cultura para que tenga éxito.
DevOps no es un juego, embarcarse en una transformación DevOps representa una inversión importante de recursos y esfuerzo para las organizaciones que deciden afrontarlo y para muchas, mantenerse en el mercado dependerá en gran medida del éxito de sus iniciativas DevOps, éxito que además, dependerá de qué tan bien se entiendan, y se pongan en práctica, la esencia, los conceptos y las técnicas de DevOps. Para esto último es que fue diseñado el juego. "The Phoenix Project" es una forma divertida de experimentar y aprender sobre un tema muy serio para las organizaciones.
Nota final: la simulación tiene mucha más complejidad que lo reseñado en este post. Dos razones para omitir mucho de la complejidad: evitar "spoilers" sobre el juego y simplificar el post (que resultó bastante largo de todas maneras). Además, es importante aclarar que el objetivo del post no es hablar sobre la simulación en sí (para eso pueden seguir este enlace) sino sobre la experiencia de la primera sesión.
Commentaires