SCRUM Product Owner: Problemas Frecuentes

En los últimos años se ha visto un incremento en el uso de las metodologías Ágiles. Ahora todos quieren aplicarlas y aunque este cambio tiene sentido, el marco Ágil no es para todos los proyectos (abordaremos este tema en un próximo blog). En este artículo, nos enfocaremos en SCRUM y uno de los roles de este framework: los dueños de producto (PO por sus siglas en inglés).

Solo para refrescar la memoria, el framework Ágil posee tres roles principales:

• Scrum Master: el conductor de la orquestra. Un Scrum Master conoce bien el framework y el mundo Ágil. Elimina los impedimentos (blockers) que pueda enfrentar el equipo y guía al PO en su rol si fuera necesario. Su objetivo principal es entrenar al equipo en todos los procesos SCRUM para así crear equipos de alto rendimiento.
• Equipo de Desarrollo: los constructores, los que desarrollan el producto. Tienen grandes responsabilidades, como saber cuánto trabajo pueden entregar luego de cada sprint; además, el equipo debe ser auto-organizado y debe participar en todas la reuniones para obtener mejores resultados.
• Product Owner: “la voz del cliente.” Un PO conoce el producto y representa los intereses del cliente o de un grupo de clientes. Es responsable por mantener el ‘backlog’ del producto en orden, agregar historias adecuadamente y refinar tiquetes con el equipo, entre otras tareas.

Al implementar SCRUM, si todos los roles cumplen su función adecuadamente, aumentarán las probabilidades de éxito. Sin embargo, luego de años de experiencia y de conversar con equipos ubicados alrededor del mundo, hemos encontrado que una de las razones principales que llevan al fracaso de un proyecto es la mala ejecución del rol de dueño del producto.

La siguiente es una lista de escenarios y comportamientos clave de los cuales hay que estar atentos para así evitar problemas para el equipo, el proyecto en general y la compañía.

Presionar al Equipo Más Allá de lo Razonable

Las proyecciones incorrectas son uno de los problemas más comunes que enfrenta un equipo SCRUM. Algunas veces, el PO puede planificar cuánto trabajo abordará el equipo de desarrollo a través de un largo periodo de tiempo (en términos de funcionalidades o puntos de historia). Pero, de repente, el trabajo que el equipo está entregando no es suficiente.

¿Qué sucede a continuación? El siguiente es un escenario de una reunión de planificación de sprint:

• PO: Bien, durante este sprint debemos completar estas 15 historias. Ya hice todos los preparativos y este será nuestro próximo sprint.
• Equipo de Desarrollo: Ok… pero si vemos más detenidamente los puntos, estamos hablando de 50 puntos de historia. Esto va mucho más allá de lo que podemos entregar de acuerdo con nuestra velocidad.
• PO: Sí, pero como ya tenemos fecha de entrega, tendremos que incluir la mayoría en este sprint. Será lo mismo para los siguientes sprints.

¿Suena familiar? Desafortunadamente, para muchas personas esta situación es común. Si tomamos un momento para analizarla, encontramos tres problemas principales:

1. El equipo de desarrollo es el que está a cargo de saber cuánto trabajo pueden asumir para el siguiente sprint. No es una mala idea que el PO tenga una lista de tareas seleccionadas como posibles candidatos para el siguiente sprint, pero eventualmente, muchas de estas tareas se dejarán para el próximo sprint sucesivamente y la complejidad de nuevas tareas requerirá más tiempo.
2. Aún si existe una fecha de entrega, los efectos negativos secundarios de este tipo de presión son como un efecto dominó.
3. Es importante aclarar que aunque exista un calendario de entrega, éste se debe refinar luego de cada sprint. De otro modo, estaríamos transformando un proyecto Ágil en un proyecto de presupuesto/duración fija que implementa SCRUM, algo que la mayoría del tiempo conduce al desastre.

No es sorprendente que el equipo se canse de seguir este paso y cada vez, más tareas de un sprint se dejarán para el siguiente. Ya que la lista ya está definida todas las veces, cada reunión de planificación de sprint será peor: horas extra para el equipo de desarrollo, cansancio, eventualmente no lograrán cumplir con las fechas de entrega y algunos miembros del equipo dejarán la compañía.

Esto Parece Fácil

Aunque las reuniones de refinamiento no son una ceremonia formal del framework Ágil, son bastante prácticas a la hora de obtener un mejor contexto del trabajo a futuro y nos permiten obviar reuniones largas de planificación de sprint.

Pero podemos encontrarnos escenarios como el siguiente (utilizando puntos de historia con secuencias Fibonacci):

• PO: Equipo, este es el tiquete que debemos estimar. Me parece que es un esfuerzo pequeño/simple/fácil.
• Equipo de desarrollo: Bueno, debemos trabajar una UI nueva, conectar un nuevo endpoint e incluir algunas validaciones. Además, el equipo de QA también deberá poner a prueba varios escenarios y quizás debamos refactorizar el código… esto es un 3.
• PO: Hmm, yo no lo veo como un 3. Para mi es un 1 o a lo máximo, un 2. Sé que pueden hacerlo, confío en ustedes.

Hemos escuchado muchos relatos como este y hemos vivido situaciones similares nosotros mismos. ¿Qué pasará aquí? Exactamente lo mismo que en el ejemplo anterior. El equipo perderá confianza al realizar estimaciones si se les rechaza siempre y eventualmente se cansarán. Llegarán a pensar que este tipo de reunión es una pérdida de tiempo. De nuevo, un pequeño número de tareas pasarán de sprint a sprint y es posible pensar que hay algo malo con el equipo ya no están entregando lo que prometen o lo que demostraron en reportes previos de velocidad. De nuevo, es un efecto dominó.

El Equipo de Dev es una Herramienta y No es mi Aliado

Esta situación es muy triste. Si realmente se desea que un proyecto fracase, solamente se debe aislar al equipo y no dejarlos expresarse a lo largo del proceso de desarrollo al afirmar “yo sé lo que quiere el cliente.”

Seamos honestos: alguna veces el cliente no sabe lo que quiere o si lo sabe, no tiene claro si lo que desea se puede lograr utilizando código. En esta situación la voz de los expertos es necesaria - en realidad, es necesaria en toda situación. ¿Y quiénes son los expertos? Como dice Lawrence M. Miller (un experto con más de 20 años de trabajar con metodologías Ágiles y Lean): “los desarrolladores, los trabajadores, los que crean y construyen los productos son los mayores expertos del mundo.”

Por lo tanto, es necesario tomar en cuenta la perspectiva y las ideas del equipo. Su voz no puede ser ignorada; si se deja de lado, es mejor escribir un resumen de por qué el proyecto fracasó desde el comienzo.

Otras Malas Señales

Las siguientes son otros síntomas que pueden conducir al desastre:

• Entra cambio tras cambio cada vez que se recibe retroalimentación; cada sesión de prueba o retroalimentación del cliente se convierte en un tiquete. Es esencial que el PO filtre lo que es necesario y lo que se puede trabajar en futuros sprints.
• “Este esfuerzo requiere un cambio en el backend también pero no está listo, así que asumamos cuál será la respuesta.” Escuchar esta frase durante la planificación de sprint es un mal augurio ya que sin duda implica re-trabajo en el futuro.
• Frases como: “QA debe apurarse y solamente poner a prueba el ‘happy path’”
• Situaciones como: “Equipo, necesito agregar estas 3 tareas adicionales al sprint que comenzamos hace 4 días.”

¿Qué Podemos Hacer?

Algunas veces, las situaciones que mencionamos anteriormente suceden debido a una mala planificación o falta de información. Por lo tanto, lo primero que se debe establecer es una buena comunicación: ésta es la mejor herramienta que el equipo puede tener. Aunque pueda parecer obvio, los miembros del equipo deben hablar entre sí para lograr el éxito. 

Si somos parte del equipo de desarrollo, debemos hablar alto y claro. Es necesario expresar opiniones y comunicar ideas, particularmente en situaciones como la que mencionamos anteriormente con respecto a la mala estimación de puntos de historia. Nadie es el enemigo: todo el equipo está en el mismo bando. Si sentimos que se nos ignora, existe alguien cuyo objetivo específico es ayudarnos: el SCRUM Master. Éste está a cargo de ayudar a remover cualquier impedimento, y a veces estos impedimentos tienen nombre y altura.

Si desempeñamos el rol de SCRUM Master y los escenarios que hemos mencionado en este artículo siguen sucediendo, estamos haciendo algo mal. Como SCRUM Master, nuestra tarea principal es guiar al equipo (incluyendo al PO). Si las situaciones anteriores persisten y no las prevenimos, entonces dos roles del framework están presentando problemas. Debemos ayudarle al PO, explicarle las razones por las cuales no está haciendo su labor bien y enseñarle a obtener buenos resultados.

Si desempeñamos el rol de PO, sugerimos un poco de introspección y análisis con respecto a proyectos actuales, su estatus y la relación con el equipo. Aunque este artículo no aplique al caso, como PO siempre es clave tener una lista de prácticas que deseamos evitar.