Agile, Producto, scrum

Product Owner en Remoto

Tras la pandemia de la Covid 19 toca reinventar la manera en la que trabajamos. Scrum, com marco ligero qué es, permite que lo usemos de diferentes maneras. El Product Owner, pieza clave de un Scrum Team debe adaptarse cuando usamos el remoto, la comunicación es diferente. Os contamos algunos consejos que podemos usar en remoto para ser buen@s Product Owners. 

Transparencia, y si hay dudas, más transparencia

La transparencia es un pilar fundamental de Scrum. Necesitamos saber en cada momento el estado del trabajo (pendiente, realizando actualmente y ya realizado) para poder hacer una inspección y adaptación correctas. Cuando trabajamos en digital, perdemos la capacidad de vernos y es clave usar la transparencia como elemento diferenciador. 

Por eso, es clave tener presente a quienes esperan tu producto, sean personas de tu propia organización o customers. Si eres Product Owner, debes tener muy presente la importancia de la conexión entre el trabajo que realizan los Developers y las personas que están van a recibir dicho trabajo. Podemos tener sesiones de trabajo, buscar maneras de recibir feedback de manera directa o bien poner encima de la mesa los datos que nuestro producto proporciona. 

Gestión de expectativas

La gestión de expectativas es clave tanto en presencial como en digital. Sin embargo, adquiere mayor relevancia cuando ciertas áreas de la empresa no entienden de tecnología y disponen de expectativas sobre fechas prometidas. El hecho de que estemos en digital puede generar mucha desconfianza, sobre todo porque hay una sensación generalizada en las empresas de que “tecnología va lento”. Esta sensación de lentitud cada vez es más palpable, cómo diría un amigo mío: “es más fácil pensar que hacer, por eso vamos lentos”.

Existen muchas técnicas para gestionar expectativas. La primera que recomiendo es, una vez más, la transparencia, no ocultar información sobre el avance, sobre las dificultades que vayan surgiendo etc. Además, podemos crear un plan de trabajo a largo alcance que nos sirva de guía y de roadmap. 

Es clave apoyarse en el/la Scrum Master para la transparencia y expectativas. Hay un trabajo muy importante que hacer con la organización para explicar lo que significa una planificación en un entorno empírico donde hay muchas variables que no podemos controlar. 

Product Backlog a distancia (mural)

Soy defensor acérrimo de los tableros visuales. Cuando trabajamos en remoto, no tenemos opciones para usar postits y, por tanto, es normal apostar por algún tipo de herramienta digital. Herramientas, como Mural o Miró, nos sirven cómo alternativa a los postits. Cualquier software como Jira o Kanbanize nos proporciona métricas que son importantes para tener un control estadístico del equipo y su capacidad de entrega. Sin embargo, antes que eso, debemos tener claro el alcance y el estado actual del trabajo.

Podemos hacer una sesión en Mural con todo el trabajo pendiente que tenemos detectado y usar colores para marcar el estado del trabajo, desde una idea “feliz” hasta un determinado item que se está desarrollando actualmente. 

Una vez identificado el estado del trabajo, en cada Sprint debemos evaluar cuáles esperamos hacer y cuáles debemos refinar para futuro Sprints. Es clave para el trabajo de un Product Owner saber cuándo se “aterrizará” un determinado trabajo y ganar información acerca de él. 

Después de este ejercicio, podemos introducir el trabajo en Jira y medir nuestros tiempos de resolución para calcular nuestro “cycle time” o “lead time”. 

Roadmap en remoto

Además de trabajar el Product Backlog y el trabajo del Sprint, podemos plantear un roadmap a largo plazo. Hay que ser cautos, un roadmap se puede percibir como fechas comprometidas. Comprometer fechas cuando no hemos refinado el alcance, puede llevarnos al desastre, sobre todo en empresas que basan el éxito de un equipo en el cumplimiento de un alcance. 

Podemos pintar los próximos 4-6 meses divididos en Sprints (según el tamaño que tengamos). Cada Sprint ponemos el alcance deseable, sabiendo que, los Sprints más lejanos tienen una mayor dificultad de cumplimiento. 

Tener un Roadmap nos sirve para adelantar a futuras dependencias y para gestionar mejor las expectativas. 

Sprint Review

La Sprint Review es una pieza clave para un Product Owner y coge mayor relevancia en remoto. Este evento es un punto de conexión entre developers y negocio, usuarios y demás customers que recibirán nuestro producto. Usar estas sesiones para entendernos, gestión de expectativas, resolución de impedimentos… ¡Este es nuestro momento!

En remoto, es esencial calendar las Sprint Review con antelación, hoy en día en las empresas las personas que necesitamos suelen estar ocupadas y disponer de ellas con tiempo es esencial. 

Durante la sesión, tener abierto una pizarra digital donde cualquiera pueda escribir es esencial, recordemos que la Sprint Review es una sesión de trabajo, no un reporte. 

Confianza en el equipo, no hay otra

En remoto, la confianza adquiere mayor relevancia. No podemos ver a las personas, por lo que tendremos que confiar en su trabajo. La confianza no debe ser ciega, disponemos de eventos como la Sprint Review para dar resultados y saber si hemos trabajado en la dirección correcta y de la manera correcta. Esta es la clave de Scrum, saber rápido si un equipo está funcionando y si estamos construyendo el producto correcto de la manera correcta. 

Implementar medidas de control por falta de confianza es peligroso porque acabamos mareando más al buen developer que tratando de que el miembro poco profesional aparezca. Es mejor confiar en el equipo y apoyarse en el Scrum Master para que el equipo aprenda a trabajar aquello que no funciona internamente, incluso expulsar a un miembro que no colabora. 

La confianza debe ser mutua y se trabaja con el tiempo, sin embargo, en un mundo donde el resultado de nuestro trabajo es la suma de un equipo, es complicado tener herramientas que midan individualmente a los miembros de un equipo.

Y tú, ¿cómo haces de Product Owner en remoto? 

Deja un comentario