by Ángel Sanz

Tres meses en Flywire


Este verano, Ángel ha venido desde Madrid para trabajar en Flywire iniciando un proyecto con un nuevo equipo. A continuación escribe cómo ha ido su experiencia.

Uno de los últimos días del pasado junio, llegué a Valencia para quedarme tres meses en Flywire. Me habían contactado algunas semanas antes para involucrarme en un proyecto un tanto… particular.

Se trataba de formar un equipo autónomo, integrado por tres trainees ajenos a la empresa, al menos dos seniors, una desarrolladora y un Product Owner. Tenía varios objetivos: por una parte, crear una oportunidad de aprendizaje, especialmente para los trainees, y de recruiting para Flywire. Por otra, construir una herramienta que mejorara la efectividad y la comodidad de algunos procesos internos. Y, más allá de todo esto, probar una forma de trabajar que aspiraba a mejorar la situación actual en la empresa.

Merece especial reconocimiento el atrevimiento de Flywire al plantear un proyecto así, pues tenía bastante riesgo: recibir a tres trainees, con experiencia limitada en el stack tecnológico de la empresa, integrar a un Product Owner que estaba iniciándose en una manera diferente de trabajar el desarrollo de producto, y dedicar a uno de sus seniors a tiempo completo y durante varios meses a este nuevo proyecto es una inversión elevada.

Más aún, la aparición de este proyecto suponía un desafío para el departamento de ingeniería que ha sido recibido elegantemente. Podrían haber surgido conflictos, recelos o malentendidos pero, al contrario, la respuesta ha sido muy buena, de apertura hacia el recién llegado. Me he sentido como uno más del equipo desde que entré. Hemos aterrizado con naturalidad, suscitando interés y aportando de diversas formas; por ejemplo: haciendo de nuestro trabajo una actividad pública que otros pudieran seguir, abriendo nuestras sesiones de review y de mob programming, y revirtiendo nuestro aprendizaje al juntarnos con todo el equipo.

Desde luego, a ésto ha contribuido que no hemos formado un silo, sino un squad que, aunque autónomo, se integraba con el equipo existente en Flywire. No tardamos en segregarnos por la oficina y siempre hemos participado en el standup diario, más allá de nuestros rituales, como nuestro propio standup, la sincronización semanal, o las reviews regulares.

La colaboración con otros departamentos, aunque ocasional, también ha sido fluida. Por ejemplo, en varias ocasiones hemos tenido necesidades de infraestructura y de diseño que hemos conseguido solventar sin bloquearnos. Además, contábamos con mucho conocimiento de negocio por parte de nuestro Product Owner, lo cual nos ha permitido entender a nuestros stakeholders con más facilidad.

Creo que, a nivel del departamento de ingeniería, el proyecto ha sentado un muy buen precedente, hacia el que la organización busca orientarse en el corto plazo. El modelo de trabajo en squads parece haber traído impulso al equipo.

En cuanto a nuestro squad, en pocas semanas hemos conseguido alcanzar un consenso que todos podemos explicar y defender. Es el resultado de decisiones tomadas en común, con las cuales no necesariamente estamos todos totalmente de acuerdo, pero que todos hemos convenido. Un consenso que es facilitado por un mecanismo de concerns, en virtud del cual las decisiones que aún no han sido consensuadas pueden ser desafiadas y propuestas para review, y tienen que ser defendidas o rebatidas. De este proceso nace un nuevo consenso. En consecuencia, no hemos tenido líderes técnicos, sino referentes técnicos en áreas concretas.

La efectividad del consenso se refleja particularmente bien en el alto nivel de propiedad colectiva del código que hemos alcanzado. Todos conocemos todo el código, porque paireamos la mayor parte de nuestro tiempo, rotando de pareja con mucha frecuencia y evitando especializarnos en partes concretas del sistema. No nos da pereza ni miedo tocar código que no hayamos escrito nosotros mismos porque estamos seguros de que podremos entenderlo con facilidad. Tenemos la confianza necesaria para cambiar, deshacer, borrar o cuestionar código que no hayamos escrito nosotros sin que eso sea percibido como una ofensa. Tenemos la seguridad de que nos cubrimos unos a otros, de que nos daremos un toque cuando no estemos respetando nuestro consenso, y de que podemos desafiar decisiones que aún no hemos consensuado por medio de los concerns.

Ha sido, en definitiva, un proyecto muy provechoso para todos los que nos hemos involucrado en él. Me voy de Flywire con muchos aprendizajes, y con mucho más por aprender. También con el deseo de que continúe invirtiendo en su equipo para seguir a la cabeza del desarrollo de software en Valencia.

¡Hasta la vista!

Ángel Sanz