Ejercer el liderazgo Agile y ser un Servant Leadership presenta en ocasiones situaciones y coyunturas cambiantes, para las cuales no existen, ni pueden existir, respuestas unívocas. Está en nosotros reconocerlas y salir adelante sin renunciar a nuestros principios(…)
En una ocasión tuve la oportunidad de trabajar como Agile Coach junto a un Scrum Master que estaba haciendo su viaje de peregrinación desde el mundo de la jefatura de proyectos rumbo a convertirse en un Servant Leadership.
En ese camino de peregrinación, en donde una muy delgada línea separa las actitudes que pueden considerarse de micromanagement de las actitudes que pueden considerarse propias de un Servant Leadership, las contradicciones inevitablemente comienzan a aparecer.
Estas contradicciones por supuesto que son normales, sobre todo por la sencilla razón de que enfrentamos constantemente situaciones y coyunturas cambiantes, para las cuales no existen, ni pueden existir, respuestas unívocas.
Estábamos haciendo frente a un problema estructural con la parte de automatización de pruebas que no nos permitía llegar a un modelo de continuous delivery: nuestro proyecto había heredado una plataforma que carecía de pruebas automatizadas y que obligaba a pasar pruebas manuales(incluso de regresión) tras cada cambio que se hacía. Un modelo, claramente insostenible. El desgaste y la desesperación de la persona que hacía las pruebas manuales era cada vez más preocupante. Había que hacer algo.
Debíamos hacer frente a cuatro escenarios: había una fuerte presión interna por parte de la organización para automatizar las pruebas; la tecnología con la que contábamos para hacer las pruebas estaba inmadura; los objetivos de entrega del proyecto no dejaban espacios para invertir tiempo en automatizar; y la más preocupante, los desarrolladores no tenían el conocimiento ni las ganas para hacerlo. Estaban desmotivados con respecto a este tema.
La organización en donde estábamos trabajando se encontraba en los inicios de su proceso de transformación, por lo cual el contexto y el margen de maniobra que teníamos era bastante escaso. Una tarde, tras salir de una de las reuniones de comunicación de impedimentos a la capa directiva (que dicho sea de paso, realmente eran reuniones de reporting), nuestra preocupación comenzó a tornarse en desesperación. ¿Qué hacer para poder solucionar los problemas que teníamos en los cuatro escenarios? ¿Qué solución había para automatizar las pruebas a la par de poder entregar valor de negocio en cada sprint? ¿Qué podíamos hacer para motivar al equipo de desarrollo a implementar las pruebas automáticas?
Por más que queramos reprogramar nuestras mentes con nuevas filosofías, tarde o temprano, las situaciones difíciles nos llevan a distorsionar nuestro rumbo y nos hacen creer que existen soluciones más efectivas, generalmente basadas en experiencias del pasado que, creemos, nos han funcionado y nos pueden volver a funcionar. Esto fue lo que nos sucedió, y agobiados con la situación, de forma inconsciente intentamos volver al Command and Control y «obligar» de alguna manera al equipo de desarrollo a implementar las pruebas automáticas como fuera. Aunque no lo hicimos explícito, se iba haciendo cada vez más evidente que los debates con el equipo sobre el tema, iban tomando cada vez más un tinte de ofrecer respuestas obligatorias en lugar de ayudarles a encontrar su camino (que no tenía porque ser el que nosotros queríamos).
Estábamos perdiendo el rumbo.
Afortunadamente las personas tenemos la capacidad de reflexionar. Y una noche caminando al salir del trabajo, el Scrum Master y yo abordamos el tema. Fue difícil reconocer que nos estábamos equivocando, que estábamos alejándonos de nuestra labor de Servant Leadership. ¿Pero qué hacer entonces? Había que buscar una solución pronto. Nosotros íbamos a terminar siendo los responsables de que no se automatizaran las pruebas. También los responsables de la calidad del producto. ¿Qué íbamos a decirles a los directivos en la próxima reunión? ¿Que el equipo no quería hacer las pruebas? ¿Cómo íbamos a justificarnos y salvar nuestras espaldas?
¡Bingo! Allí precisamente estaba el problema.
Lo último que teníamos que hacer como Servant Leadership era salvar nuestras espaldas. Habíamos caído en la trampa: mientras más asumes la labor de Reporting hacia las capas directivas, más te involucras, caes en la presión e inmediatamente la trasladas al equipo. Tergiversas y perviertes totalmente tu rol.
¿Y qué hacíamos entonces? ¿Dejábamos las cosas así incluso cuando eso pudiese poner en riesgo nuestro trabajo? La respuesta es sí.
Pero también la respuesta es no.
En primer lugar, sí porque hay que actuar como Servant Leadership en todo momento. Es como dedicarse —salvando por favor todas las distancias— a ser rescatista, en algún momento, cuando aceptas el trabajo, eres consciente de que tarde o temprano quizá debas dar tu vida por salvar la de alguien. Acá es algo parecido, cuando aceptas ser un Servant Leadership, debes aceptarlo hasta sus últimas consecuencias. Eso incluye el riesgo de que te despidan de tu trabajo. Sino, no lo seas, ya hay muchos otros puestos de trabajo que pueden ahorrarte esas molestias. Pero también decíamos que la respuesta es no, porque existen mecanismos para evitarlo y para que a su vez se consigan que las cosas salgan adelante. Es, simplemente, elegir entre hacer las cosas bien y hacer el bien.
Hacer las cosas bien significa hacer lo que te piden en tu contexto, lo que te piden quienes te contratan y te pagan. Sea lo que sea; hacer el bien, por el contrario, significa discernir entre cuándo debes hacer lo que te piden y cuándo debes conseguir lo que te piden por otros medios que no tergiversen tus valores y tu rol en la empresa. Es, entre otras cosas, un cambio importante de mentalidad: ya no se trata de trabajar para tus jefes, se trata de trabajar para tu organización. Algo que parece lógico, pero que difícilmente se puede apreciar hoy en día.
Liberados de esta presión, entonces pudimos actuar como creímos que correspondía. Lo que decidimos hacer para dar respuesta a los cuatro escenarios, y dar respuesta sin caer en actitudes lejanas a lo que se esperaba de nosotros como líderes Agile, fue lo siguiente:
- Aceptar la presión del banco pero no hacernos partícipes de ella. En las siguientes reuniones que tuvimos, fuimos dejando en claro poco a poco que simplemente éramos voceros del equipo, no los responsables (se podrán imaginar a la jauría de leones preguntándose a quién iban a culpar ahora). Esto nos ayudó mucho a enfocarnos más en el proceso que en el proyecto. En ayudar al equipo a buscar las respuestas y no a dárselas de antemano bajo presión.
- Promover en el equipo la necesidad de evaluar las herramientas que habían disponibles para automatizar con el fin de reducir la incertidumbre.
- Conversar con la Product Owner acerca de la necesidad de buscar tiempo en los Sprints para estudiar y hacer las pruebas automáticas y el valor de negocio que éstas tenían de cara a reducir la deuda técnica en el futuro.
- Organizar workshops para los desarrolladores sobre las pruebas automáticas y las herramientas que las soportan. Al final, incluso hasta salieron encantados y con ganas de automatizar.
¿Cómo no volver a caer en la trampa?
Hicimos, además, un pequeño pacto entre el Scrum Master y yo: podrían aparecer todas las coyunturas que el destino quisiera(y así fue), y podríamos decidir cosas más o menos mejores con respecto a lo que nuestro rol de líderes Agile exige. Pero mientras siguiésemos pensando y, peor aún, siguiésemos intentando adoptar alguna decisión que traicionase los principios de nuestro trabajo, no nos volveríamos a llamar Agile Coach ni Scrum Master. No volveríamos a decir que estábamos trabajando en un proyecto bajo Agile. Al menos, hasta que recuperásemos nuevamente el rumbo.
Nos funcionó. Fue un recordatorio que siempre tuvimos presente y que nos ayudó en más de una ocasión a decidir lo mejor para la situación que enfrentábamos.
El liderazgo Agile, no es como una prenda de vestir que podemos lavar y volver a usar. Es más bien como una vela: tiene un tiempo de vida y se apaga. Y es nuestro deber renovarla en todos y cada uno de los miembros del equipo. Todos los días, comenzando por la nuestra. Esto nos ayudará a navegar entre las distintas soluciones, cuando tengamos que elegir entre hacer las cosas bien o hacer el bien.
Image: (c) 2014, Elment, Creative Commons 2.0
