Agile Product Owner, en apuros

En la primavera de 2016 Runroom tenía dos equipos de desarrollo ágil que habían crecido demasiado. Había llegado el momento de crear un tercer equipo y fueron los propios runroomers los que decidieron cómo sería la nueva reestructuración.

Entre todos se concluyó que el ‘mínimo equipo viable’ sería el compuesto por las personas con más experiencia en una disciplina y las nuevas incorporaciones. En los otros dos equipos, los skills quedarían más equilibrados. Así nació el equipo Silex, un equipo multidisciplinar que necesitaba fichar un Product Owner: servidora.

Y durante los primeros meses en Runroom, no hice más que estar en apuros.

Cada uno de su padre y de su madre

Silex estaba compuesto por siete personas: dos Diseñadores UX/UI, dos Frontend Developers, dos Backends Developers y un Product Owner (PO). El primer reto al que debíamos enfrentarnos era convertirnos en un equipo. No fue algo que sucediera de un día para otro.

Por un lado las tres personas que llevaban muchos años en la empresa tuvieron que hacer un gran esfuerzo por compartir sus conocimientos técnicos a la vez que descubrían nuevas formas de trabajar en equipo. Por otro, los “juniors” (costó horrores quitarles el sambenito) que debían aprender el máximo en el menor tiempo posible y además lanzarse a aportar ideas innovadoras, usables y factibles dentro del desarrollo por sprints. Casi nada.

Y finalmente yo, una Product Owner atípica. Mientras mis homólogos eran ingenieros informáticos, toda mi formación era en periodismo y marketing digital. Además, aunque llevaba tiempo interesada por el agilismo, toda mi experiencia en el desarrollo de software era en proyectos waterfall. Lo tenía todo para triunfar.

Scope, iterativo incremental y atomic design

La primera gran batalla que ganamos como equipo fue la del alcance: durante los primeros meses decíamos más veces “scope” que “gracias”. Que nadie os engañe, idear soluciones y ponerlas en producción en sprints de 2 semanas, es difícil.

En la fase de refinamiento e ideación participábamos todos para garantizar que lo que se decidía iba a estar funcionando en la demo. Si teníamos una buena idea que se iba de alcance nos costaba muchísimo volver a empezar. Fue un trabajo diario, pero lo conseguimos.

Igual pasó con los conceptos iterativo incremental y atomic design. No fueron cosas que conseguimos poner en marcha de un día para otro. Supusieron mucho esfuerzo y descoordinación pero a la vez veíamos que nuestros productos y tiempos de desarrollo mejoraban.

El equipo agile Silex estrena nuevo Product Owner

 

Scrum de mi vida, tú eres ágil como yo

Algo que nos ayudó a cohesionar nuestra forma de trabajar en equipo fue apoyarnos en la metodología como si fueran las tablas de la ley. Cuando en las retrospectivas discutíamos debatíamos sobre cómo mejorar los procesos, recurríamos una y otra vez a los principios ágiles y la metodología scrum. Compartíamos la fe en la base teórica aunque no todo lo supiéramos poner en práctica. Seguíamos en el empeño porque cada vez las cosas salían mejor.

“Y tú, ¿qué haces?”

Por mi parte los primeros meses me centré exclusivamente en la definición de producto y control de calidad, dejando al scrum master la tarea de liderar al equipo. Doble error: Los buenos productos nacen de los buenos equipos y la calidad no es algo que pueda depender de una sola persona.

Es saludable que en un equipo haya más de una persona capaz de liderar, motivar y tomar buenas decisiones en momentos clave. En un equipo ágil el PO tiene que ser uno de ellos porque tiene mucha información y la visión más transversal.

A modo de resumen, además de estar disponible para resolver dudas, debía crear el backlog más adecuado para cada proyecto, planificar el sprint, velar porque los objetivos del producto se estuvieran cumpliendo, dar contexto de lo que vendría, gestionar la relación con cliente, ocuparme de los fuegos y evitar ruido para que el equipo pudiera concentrarse en la producción.

Comunicación ++

La clave siempre acababa siendo la comunicación. Si alguien tenía un problema, impedimento o imprevisto, debía avisar lo antes posible para entre todos buscar la solución. Cuando solo dispones de 10 jornadas de trabajo para tener software funcionando, todo tiempo cuenta.

También tuvimos que comunicarnos más y mejor en el plano personal. Comer todos juntos cada viernes, hacer reuniones de feedback “one to two” con PO y scrum master, y organizar alguna movida fuera de la oficina, obraron milagros en la cohesión del equipo.

Cohesión y empatía en equipo Agile

 

Zapatero a tus zapatos

Para poder tener la mejor solución y llegar al compromiso de entrega, definir el producto entre todos, en dinámicas conjuntas, era esencial. A la vez, a veces eso nos llevaba a sesiones interminables en las que acabábamos opinando todos, de todo.

Si hay algo que nos hizo dar un gran salto adelante fue asumir que cada uno tenía un rol del cual era especialista y eso había que respetarlo. Fue una forma de empoderar a cada uno en su área de responsabilidad y ajustar el timebox de las reuniones.

Un equipo que rema junto

Una de la cosas más difíciles fue la entrada y salida de algunos miembros del equipo. Encontrar el grupo de personas dispuestas a hacer lo que sea por conseguir el objetivo común fue un desafío. Cada uno tiene su rol, pero si uno pide ayuda, el otro acude.

He visto backends retocando imágenes y copys para la demo, diseñadores testeando la integración front/back y maquetadores aplicando mejoras de diseño directamente en el código. Lo que haga falta por conseguir cerrar el sprint. O lo conseguimos todos o ninguno.

Product Owner y Equipo Agile en Runroom

Una nueva etapa

Lo confieso, nunca fuimos un equipo perfecto. Nos equivocamos muchas veces, quedaron cosas por aprender y épicas fueron nuestras discusiones -que acabamos bautizado como capítulos de una serie: “La del vídeo”, “La de la mesa”, “La de la review”…-. Pero he de reconocer que poco a poco mis apuros acabaron desapareciendo y ser Product Owner ha sido una experiencia increíble. Por no hablar del orgullo por nuestros proyectos. ¡Qué maravilla oiga!

Ahora Runroom ha vuelto a emprender un proceso de mejora y he pasado a tener un rol transversal para conseguir que la experiencia de nuestros clientes sean memorables. Muchos hemos cambiado de posición y nuevos PO están al frente de los equipos. Igual creen que están en apuros, pero lo están haciendo bien. No hay fórmulas mágicas, solo trabajo, constancia e ilusión. Bienvenidos.

 

 

*la foto de la cabecera es de Martin Reisch en Unsplash

About Montse Pachón

Soy Head of Client Services en Runroom. Me formé como realizadora audiovisual y periodista pero siempre he trabajado en equipos de marketing coordinando proyectos (mayormente) digitales. He tenido mucha suerte, me encanta mi trabajo y ya llevo más de 10 años disfrutando de él. Mis habilidades van muy relacionadas con "venirse arriba" en los momentos críticos: the show must go on!

Comments

  1. Daniel Benítez García dice:

    Muy interesante, es genial aprende de las experiencias de otras personas y más cuando están tan bien explicadas, muchas gracias por compartir ;D

    1. Montse Pachón dice:

      Muchas gracias Daniel, ¡me alegro mucho que te haya gustado!

  2. Sarah dice:

    Me encantó el artículo y aprender mas de tu experiencia, ¡gracias! Y a seguir mejorando :)

    1. Montse Pachón dice:

      Muchas gracias por tu comentario Sarah, ¡me alegro que te haya gustado!

  3. ari dice:

    Qué bonita la reflexión final :)

    1. Montse Pachón dice:

      Gracias Ari ;)

Something to say?