Mejorando nuestro proceso Ágil en tiempos de COVID-19
Ya han pasado más de seis meses desde la llegada del COVID-19 a Colombia y finalmente, tal como lo solemos hacer los humanos, nos hemos adaptado. Hemos empezado a convivir con el virus, los casos en el país poco a poco han bajado y la vida vuelve a la normalidad( o como algunos dicen en una frase trillada “la nueva normalidad”). Muchas cosas cambiaron y quiero contar cómo las afrontamos en La Haus y cómo pudimos sobrevivir a trabajar remotamente de un día para otro.
En La Haus trabajábamos desde nuestras oficinas y remotamente antes de la pandemia, teníamos ingenieros en varias ciudades y creíamos dominar el arte de poder hacer las dos cosas, lo cual, después de unos días de pandemia, resultó no ser cierto. Nos defendimos por unas semanas y los comentarios que escuchábamos de la mayoría de las personas eran: “Estoy trabajando más”, “Me está rindiendo mucho el tiempo en mi casa”, “No regresemos nunca a la oficina, rindo mucho más en la casa”. Yo también sentí lo mismo, en las primeras semanas fue difícil organizarme en un ambiente 100% remoto; pero después, todo fluyó.
Sentir y tener intuición es algo muy bueno, pero generalmente podemos caer en errores, en sesgo confirmatorios o en observaciones no tan claras de la realidad. Si eres de los que pensaba que trabajar desde casa iba a ser más productivo, quiero que te tomes un tiempo para medirlo y ver si tenías razón. Para nosotros en La Haus, no fue así. Para explicarlo me gustaría usar el algoritmo del profesor Richard Feynman. Recomiendo su libro “Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character
Es el algoritmo más simple del universo, pero creanme que muchas personas pasan a la solución sin tener claro el problema. He visto esto muchas veces.
El problema
La caída del impacto de nuestro equipo de ingeniería después de pasar a trabajar remoto se puede evidenciar en el siguiente gráfico.
Esta es nuestra gráfica en el impacto del equipo de ingeniería y producto de casi 50 personas (Todos ellos muy profesionales y de los que puedo garantizar, muy talentosos). Entendemos ese impacto como la magnitud de los cambios en el código base durante un período de tiempo, es decir, tiene en cuenta variables como la ubicación de los edits, el tipo de código que se está escribiendo (por ejemplo, código nuevo vs actualizaciones de código existente), la proximidad de las ediciones entre sí, y la naturaleza específica del cambio en una línea (por ejemplo, los cambios de formato son más simples que los cambios lógicos).
Nuestra misión como equipo de ingeniería de tener un continuous delivery que nos permita dar el mayor valor al usuario, iterando rápidamente y manteniendo los más altos niveles de calidad, estaba en peligro.
Análisis
Después de hablar en varias ocasiones con el equipo, todos manifestaron que estaban trabajando más desde sus casas, que pasaban más tiempo al frente del computador, y lo raro, era que su productividad estaba disminuyendo. Hicimos varias encuestas anónimas y algo que se evidenció en muchas respuestas era la cantidad de reuniones. Esto tenía sentido. Comenzar a trabajar remoto 100% implicaba crear reuniones para poder conversar sobre un tema particular. Encuentros e interacciones que antes eran espontáneos y naturales necesitaban de una reunión.
Otro de los temas que salieron en nuestra encuesta es que a veces la semana se quedaba corta para cumplir con nuestra iteración, y mucho más, en uno de los países con más días festivos en el mundo. En el momento de la encuesta, en La Haus trabajábamos en sprints de una semana, teniendo muy en cuenta poder entregar valor rápidamente al usuario, semana tras semana. Un libro muy bueno que habla sobre cómo hacerlo de esa manera es Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results.
Además, el proceso de ingeniería estaba corriendo muy parecido desde hace un año, sin tener en cuenta el incremento en sus personas en casi un 400%. La comunicación entre muchos es exponencialmente mayor y más compleja debido a las conexiones que se crean una vez crecen los equipos.
Por todo lo anterior, tomamos el camino de crear un nuevo proceso ágil para toda la empresa y no sólo para el equipo de ingeniería y producto. Porque si juntos estábamos en esto, todos como empresa debíamos cambiar radicalmente nuestra forma de trabajo, debía permear nuestra cultura y que todos encontráramos el beneficio, personal y laboral.
Investigación
Hay varias nuevas profesiones en las que me es difícil confiar: “agile coaches”, “consultores de transformación digital”, “consultores SEO”, entre otros. Es un mercado del que se habla mucho, pero muy pocos conocen. Teniendo en cuenta lo anterior, estaba muy dudoso de contratar a alguno de los anteriores para que me ayudara a liderar el cambio.
Fue así como comencé una investigación profunda, en la que sostuve conversaciones con algunos agile coaches recomendados con mucho cuidado, amigos y con otros CTOs. Después de estas conversaciones, llegué a la conclusión de que debíamos tener un champion dentro de la empresa para liderar todo el proceso. Definitivamente una fuente externa iba a tomar mucho tiempo, y corríamos con el riesgo de no ajustarse a lo que queríamos.
Como una vez escuché en este podcast How to take on Goliaths and win, Drew Houston, fundador de Dropbox, lo primero que hacía cuando no sabía sobre un tema, era buscar en Amazon y comprar el primer libro que aparecía en los resultados. Por mi parte, alguna vez tuve una certificación de scrum master, pero estaba oxidado y definitivamente no era suficiente para este problema. Lo que se vino adelante fue buscar y consultar, hablar con expertos, y triangular información. A continuación listo los principales hallazgos y lo que terminamos implementando.
Kanbanized Scrum
No nos casamos con ningún framework. Creemos que debemos implementar lo que mejor se adapte a nuestros problemas y situaciones. De Kanban nos pareció que lo mejor que podíamos adoptar era su tablero y seguimiento de las tarjetas en nuestro workflow. WIP (Work in Progress) tiene mucho sentido para evitar el intercambio de tareas o multitasking.
De scrum quisimos mantener el concepto de estimaciones y de iteración para cada sprint. Veníamos acostumbrados a iterar de esa manera y nos parece que funciona para tener entregables semanales. Nos llama mucho más la atención la medición al Cycle Time y es algo que venimos haciendo pero queremos tener claridad en el alcance de cada Sprint. En el futuro está abierta la posibilidad para tener sólo Kanban.
Sprint de 2 semanas
El miedo principal acá era perder velocidad. Quisimos correr el riesgo porque tenía sentido para nosotros ganar un día completo de ejecución al quitar reuniones que se repetían semanalmente y podían hacerse cada dos semanas. Para ganar seguimiento agregamos dos reuniones de refinamiento durante todo el sprint. Estos son los mejores momentos para conversar sobre el progreso del sprint y elaboración en equipo de las historias de usuario. También agregamos las reuniones de retrospectiva y demos al final del sprint. En el antiguo proceso, de una semana, también las teníamos pero en muchas ocasiones las saltábamos debido al poco tiempo de la semana. Grave error.
User Stories
Todos creemos que sabemos definir historias de usuario. La idea acá es tener un entendimiento total sobre la metodología y saber qué aplicar y qué no. Nos sirvió mucho que hubiera claridad sobre qué eran las historias de usuario y más que fijarnos en su correcta escritura, lo importante es saber cómo contar el cuento de lo que necesita el usuario y habilitar la comunicación fluida entre todo el equipo.
Club House
Trello no es suficiente para todos nuestros equipos, pero Jira nos parece muy sofisticado y complejo. Nos fuimos por una opción en la mitad, con la que siempre hemos trabajado llamada Clubhouse. Lo que hicimos mejor fue definir el estándar y forma de uso de la herramienta para todos los equipos.
Creamos workflows diferentes para cada equipo funcional y dentro de cada equipo se tienen proyectos, que a su vez conforman epics, y estos milestones. Integramos el equipo de marketing al proceso para tener sincronía y alineación con su trabajo de gran importancia para nuevos lanzamientos de productos digitales.
Reuniones de toda la empresa
Cambiamos las reuniones de toda la empresa. Se procura que las reuniones se den en la mañana, así todo el tiempo de la tarde queda libre para la ejecución de los equipos, y sobre todo la de los makers, personas que se enfocan 100% en ejecución (diseñadores, programadores, y hasta tech leads).
Así luce una parte de nuestras reuniones la primera semana del Sprint.
Quiero destacar las reuniones diarias generales para toda la empresa. En una hora conocemos los problemas de toda la empresa de manera transversal y vertical. Primero, ocurre un daily de equipos; después, los líderes funcionales de los equipos conversan con su líder; y al final, los líderes de áreas (tecnología, marketing, producto, comercial), saben qué ha pasado en toda la empresa y toman decisiones oportunamente.
Resultados
Los resultados hablan por sí solos. Después de un mes de implementación vemos mejoras en todas las métricas del proceso. A continuación está la métrica de impacto que había mostrado al principio del artículo. El arranque oficial del nuevo proceso se dio donde está la marca Sprint 2 weeks, semanas antes ya veníamos probando y organizando el nuevo proceso.
La comunicación en la compañía ha mejorado, los ingenieros después de otra encuesta agradecen el cambio. Hemos mejorado la productividad, número de commits, cycle time, pushes e impacto a niveles mucho mejores que antes de la pandemia. Los equipos comerciales, de oferta y mercadeo también están en el proceso y han resaltado el mejoramiento en acuerdos precisos y articulación. Creemos con toda convicción que ahora estamos mejor trabajando remotamente. En otro post hablaré sobre los cambios principales que deben adaptar las organizaciones para que el trabajo remoto sea más efectivo. Queda el reto de conservar y mejorar sobre el trabajo realizado.
Reconocimientos
Quiero reconocer la colaboración en la creación de nuestro proceso a Jorge García (nuestro Head of Design) y Thomas Floracks (nuestro CPO). Gracias por hacer de la integración de todos nuestros equipos una máquina de producto, calibrada y lista para un nuevo trimestre. Quiero agradecer a todo el equipo de La Haus, por su ética de trabajo inquebrantable y entre todos, haber mejorado el proceso y nuestra forma de trabajar, en estos tiempos tan difíciles para la humanidad.
Ñapa (Los libros que más me gustaron en todo mi estudio)
Si quieres hacer parte nuestro equipo o conversar un poco más sobre este artículo o lo que quieras, me puedes escribir a santiagogarcia@lahaus.com. También escríbeme si tienes recomendaciones para leer y que puedan ayudar a hacer nuestro proceso mejor. En La Haus y LaHaus.mx seguimos trabajando incansablemente para ser los mejores en producto y tecnología en Colombia y Latinoamérica. Cualquier contribución a este post es recibida con mucha gratitud.
