Nota del editor: Este es el segundo de una serie de artículos centrados en Mujeres en Producto e Ingeniería. Priyanka Mazagaonkar, directora de ingeniería en Selligent, comparte su experiencia como scrum master (facilitadora de proyectos).

En mi entrada de blog anterior, conté mi experiencia general desempeñando los diferentes papeles de directora de equipo, scrum master/lider y jefa de producto de forma paralela. Ahora, me gustaría centrarme en una de estas funciones. Aunque he aprendido (y todavía aprendo) muchísimo del desempeño de todas estas funciones, el recorrido más edificante es el que he tenido como scrum master.

Fui hábilmente introducida en esta labor por personas que ya estaban desempeñando estas funciones para los demás equipos y, si algo hizo fácil esta experiencia, fue la detallada orientación que recibí. También sabía que las cosas nunca funcionan igual en el área local que en producción. (Sí, habla la ingeniera que llevo dentro; y sí, ¡esa parte de mí nunca podrá llegar a acallarse!)

Me di cuenta de que ser scrum master podría entrar y entraría en conflicto directo con mi otra labor como superior inmediata del equipo. Este fue un tema que traté ampliamente con Dimitri Vanderhaeghe, uno de los miembros de nuestro sólido equipo de scrum masters, y mi mentor en la materia. Al empezar a desempeñar este papel, me dejé guiar por dos principios fundamentales:

  1. Ser facilitadora

    El equipo debería mantener debates pertinentes y llegar a una decisión.

    A algunas personas esta cualidad les sale de forma natural, mientras que a otras no tanto. Yo pertenezco a la segunda categoría, ya que siempre me he considerado parte del equipo y, por tanto, quiero contribuir plenamente a todas las conversaciones. (Todavía) estoy aprendiendo a guiar cuidadosamente los debates para que no se salgan del tema ni del ámbito en cuestión, ni se pasen de tiempo, sin tener necesariamente que contribuir al contenido de la conversación.

    Descubrí que la clave para conseguir este equilibrio era formular preguntas abiertas, una estrategia que tomé prestada de mi caja de herramientas de gestión. Por ejemplo, si veo que el equipo ha estado debatiendo determinadas dependencias de bloqueo para un asunto, en lugar de proponer directamente enfoques para eliminar tal dependencia, una pregunta abierta sería «¿Creéis que podría haber un modo de eliminar esta dependencia?”; o aún mejor, «¿Qué creéis que está haciendo que esta dependencia suponga un bloqueo?»

  2. Ser amiga y aliada del equipo 

    El equipo debería sentirse cómodo acudiendo a ti con asuntos que no les resultaría cómodo tratar con su superior.

    El primer reto fue ser capaz de infundir confianza en el equipo, de modo que acudieran a mí estrictamente en calidad de scrum master (y no de jefa). Mi estilo general de gestión se convirtió en un importante activo a este respecto, y mi relación profesional abierta con el equipo permitió que esa confianza se generara con bastante rapidez.

    El segundo reto fue, por supuesto, conseguir equilibrar estas funciones eficazmente en mi cabeza. Era peligroso sencillamente asumir que sabría marcar los límites adecuados en cada caso o conversación y necesitaba implantar un proceso coherente y bien definido. A tal fin, busqué algo de inspiración en el concepto de procesamiento en serie y en paralelo. Aunque la mayoría de los que trabajan en tecnología entienden el procesamiento en paralelo como un modo de funcionamiento informático, este resulta también muy pertinente en la codificación neuronal y en cómo los humanos procesamos la información. El cerebro puede combinar a la perfección múltiples aspectos de los estímulos entrantes, compararlos con los recuerdos almacenados y ayudarnos a entender un acontecimiento de la mejor manera posible.

    No hace falta decir que no existe una solución de hardware para el tipo de categorización que necesitaba y, por tanto, intenté introducir software firewalls, de modo que la conexión con determinados recuerdos almacenados (esto es, la memoria de «manager» registrada en mi cerebro) estuvieran supeditados a las circunstancias concretas o fueran según demanda respecto a estas.

    En términos sencillos, esto quiere decir que cada vez que un miembro del equipo quisiera hablar conmigo en mi calidad de scrum master, yo no debía dejar que la jefa que llevaba dentro se colara en la conversación. Después, del mismo modo en que un scrum master informaría de algo a un superior, haría el seguimiento necesario o tomaría medidas sobre determinadas cuestiones sobre la base de una información filtrada o generalizada. Sé que esto es más fácil de decir que de hacer y admito que a menudo me he decantado más hacia un lado a lo largo de este camino; pero estas leves transgresiones me han servido para conseguir adaptar mejor las circunstancias.

    La lección más importante que he aprendido de mi trabajo como scrum master es saber cuándo y cómo hacerme a un lado, así como cuándo intervenir y facilitar. Paradójicamente, esta es también una de las cualidades más sutiles de un buen manager, con una pequeña diferencia: cuando es necesario intervenir, lo haces y diriges el equipo.

Aunque es mi equipo el que realmente tiene que juzgarlo, creo que mi labor como scrum master también me ha hecho mejor jefa; y tengo la sensación de que estas dos funciones han creado una sinergia que hace que me adapte y mejore continuamente. ¡Esto me hace ágil!

Priyanka Mazagaonkar es directora de ingeniería en Selligent Marketing Cloud. Ha trabajado en el sector de la tecnología de software durante más de 15 años, habiendo iniciado su carrera como ingeniera de software para pasar poco después a funciones directivas. Lleva años dirigiendo equipos de ingeniería por todo el mundo y ha mostrado un gran interés en explorar cómo pueden introducirse productos en dominios de nube y relacionados. Cuenta con una amplia experiencia como integrante y coordinadora de equipos offshore, especialmente en el ámbito de las nuevas evoluciones y la exploración de tecnología.

Mira nuestra plataforma
EN ACCIÓN

Solicita tu demo