Caso de éxito: BBVA Extended Solutions

Acostumbrados a leer sobre grandes gestas de Vietnam y startups exitosas creadas en garajes, hoy me dispongo a rememorar sin complejos la que hasta la fecha ha sido mi experiencia profesional más gratificante. Tiramos de nostalgia.

Mayo de 2015. Tras varios meses con algo de infortunio en Paradigma -por aquel entonces, Tecnológico- recalo en BBVA dentro de un grupo de élite destinado a desarrollar un proxy de seguridad inverso. Sintiéndome algo desubicado (ya confesé mis andanzas como desarrollador) el producto empieza a coger vuelo y, al hacer concesiones a los distintos peticionarios, acaba por desviarse de su cometido original. Además, no estamos siendo ágiles a la hora de atender estas peticiones -en muchos casos por considerarse distracciones-, ni a a la de evolucionar el producto a la velocidad deseada.

Es así como en marzo de 2017 surge una suerte de spin-off y se me brinda la posibilidad de ser su Scrum Master, tanto por mis propias pulsiones profesionales como por el apoyo del Scrum Master del equipo, a quien ya había hecho sustituciones. De esta manera, del Core del producto surge una ramificación con clara orientación al cliente, un bendito y por momentos desconcertante cajón de sastre bautizado como Extended Solutions -sí, Soluciones Extendidas…- liderado por un manager con una mente preclara y zambullido en el barro en un inicio en que lo primordial es priorizar un backlog de peticiones al producto vitaminado. Por el camino, en la que será una de las tónicas generales de ahora en adelante, absorbemos un mini equipo desahuciado de criptografía, encajando su propio roadmap y rotando entre los distintos miembros del equipo para romper el silo que se había generado.

En estos primeros pasos como agilista, una de las primeras cosas que hice fue reforzar el marco, en este caso Scrum, que es con el que habíamos venido trabajando aunque de aquella manera. Y no porque considerase necesaria la adscripción canónica al framework (pues me consta que al contemplar las distintas particularidades del entorno algún teórico se seguiría tirando de los pelos), sino como medio para reforzar valores y disipar las incertidumbres que entonces afloraban. No obstante, los miembros del equipo habían sido designados de una forma un tanto arbitraria y cada uno interpretaba el cambio como buenamente sabía y podía.

De esta manera, se propició desde el inicio una comunicación horizontal fluida entre las capas de negocio y la de desarrollo, que perduró en el tiempo y se hizo extensible a la de producción, jugando en este caso un papel reseñable la figura del Facilitador a la hora de acercar la oficina al cliente. Así, sumado al clima colaborativo que ya había entre empresas, surgió un respeto y confianza mutuos que permitió que se pudieran garantizar algunos de los pilares básicos del agilismo, como pueden ser el aprendizaje mediante el error, el empoderamiento en la toma de decisiones técnicas o la transparencia, por citar algunos.

Para ello, hay que reconocer que el ecosistema en que nos movimos en la compañía fue envidiable. Y es que, si bien Spotify creó su modelo iterando como solución a su casuística concreta, lo hizo sobre los cimientos de una cultura agile tan fuertemente arraigada que, aunque sea cierto que no baste únicamente con organizarse en tribus y squads, sí exige un respaldo corporativo en su implantación que significó un buen punto de partida a la hora de poner en marcha un proyecto como este.

Pero vayamos al grano. ¿Scrum funcionó? A nivel de equipo hay indicadores que así lo atestiguan, como la bajísima rotación, la cohesión del grupo (esas hamburguesas del Alright) o la escuela que supuso el proyecto para muchos de nosotros. En cuanto a negocio, hablaríamos de una productividad alta y una entrega constante, a pesar de que el equipo tuviera ciertas dudas sobre el valor y el propósito del trabajo entregado, como veremos más adelante. Pero, sobre todo, se puede medir en la flexibilidad para adaptarse diariamente a un proyecto que iba adoptando distintas líneas de negocio en torno a la autenticación, con el consiguiente soporte y mantenimiento en producción de sus diferentes productos. Ni que decir tiene que ello no hubiera sido posible sin todas las mejoras que se fueron introduciendo a golpe de Retrospectiva.

Estado del equipo: margen de mejora en el valor y el propósito del trabajo desarrollado

Abril de 2019. Como parte del programa de formación en cliente (sí, se nos acercaban las formaciones a cliente) recibimos una amena charla sobre Clean Code y a muchos de los compañeros que habían ido creciendo exponencialmente como profesionales y que ya tenían preocupación por la materia les pica de lleno el gusanillo: las PR comienzan a ser exhaustivas y el equipo de desarrollo adquiere un nivel de exigencia alto, llevándose a cabo delicados refactors. Estaríamos hablando de un engranaje engrasado, un reconocimiento y un respeto palpables en el ambiente en el que se asume que un chaval que no llega a los 30 exponga sus disquisiciones técnicas en foros de management mientras gira las caras de un cubo Rubik. No estamos en la Vela ni en el Centro de Innovación, estamos, pese a todos los esfuerzos por modernizar y adaptar ese antiguo CPD, en el rocoso acorazado Potemkin; y casi que nos mola.

Por supuesto, no todo el monte es orégano: el desgaste comienza a hacer mella y el equipo siente que los proyectos vienen pero nunca se van, sin visión estratégica ya no sólo de los productos sino del departamento. A medida que hemos ido creciendo se ha ido engrosando la capa de negocio, cada vez más ocupada y diseminada, queriéndose acortar esta distancia premiando la trayectoria de ciertos miembros del equipo, creándose jerarquías.

Además, las nuevas incorporaciones no se integran al ritmo adecuado. Y es que no es fácil, ya que la curva de aprendizaje al haberse absorbido tantos proyectos comienza a ser inasumible, amén de la pérdida de foco que supone para los subequipos lidiar con el soporte o incluso con sus propias rotaciones.

Por otro lado, la documentación se revela como un punto deficiente. Y no es que no haya, de hecho, haber hay mucha y dispersa. Pero no termina de servir para su cometido y nos dificulta enormemente la implantación, el soporte y la integración en los distintos países. Tal es el desbarajuste (cuidado con que Agile no requiera documentación) que se promueve internamente un Docutón. Además, en el CI/CD tenemos una gestión más que mejorable de versiones y su flujo de promoción.

Mencionar que un punto crítico fueron las guardias en producción con distintos proveedores (y, por tanto, con distintos grados de implicación y remuneración), viéndome en ocasiones en un incómodo e ingrato rol de portavoz del equipo a modo de delegado sindical.

En cuanto a Paradigma, también se detectaron problemas que se intentaron abordar, tales como el sentido de pertenencia y un plan de carrera profesional acorde a los méritos. Para ello, pusimos en práctica varios meetups en la oficina por iniciativa propia para dar a conocer nuestra labor, participamos en la gamificación del ADN de la compañía -obteniendo premios en varias categorías-, mantuvimos un contacto estrecho con People y promovimos varias dinámicas de equipo.

En todo caso, varios entre los cuales me incluyo, sentíamos cierta desazón seguramente acentuada por una pátina de fin de ciclo personal. Y es que cualquier tiempo pasado fue mejor y hay muchos mundos ahí afuera por descubrir. Y como aquí nadie es imprescindible sino que todos somos contingentes, uno mismo marchó con la satisfacción de haber podido contribuir a establecer una inercia y unos hábitos positivos de trabajo, que no es poco.

Desde aquí, desde este mi humilde blog, saludar a mis compis. En cuanto la situación lo permita, ¿hace una reunión de antiguos alumnos?

Inspiraciones: