¿Debe un Product Owner asistir al Scrum diario?

 

por Avi Schneier | J23 de julio de 2021 | Blog

¿Debería Product Owners asistir al Daily Scrum? Me lo preguntan a menudo.

Así que vamos a poner este a la cama juntos oficialmente. 

Empezaremos examinando la Guía Scrum, para luego profundizar a través de experiencias reales pragmáticas. Por último, concluiremos con un análisis de cómo la asistencia al Product Owner puede secuestrar el Scrum diario y cómo hacer que su asistencia sea, en cambio, una experiencia enriquecedora.

 

Guía Scrum: Las reglas del juego

 

La actualización de 2020 Guía Scrum establece claramente lo siguiente:

"El Scrum Diario es un evento de 15 minutos para el Developers del Equipo Scrum. Para reducir la complejidad, se celebra a la misma hora y en el mismo lugar todos los días laborables del Sprint. Si los Product Owner o Scrum Master están trabajando activamente en elementos del Sprint Backlog, participan como Developers".

Según esta frase, no es que el Product Owner debe o no debe asistir - es que no necesitan a no ser, claro está, que estén "tirando de retraso" como el Developers. Entonces, si estas sencillas frases son tan claras, ¿por qué hay confusión o incluso alguna duda sobre su asistencia? 

Resulta que la Guía Scrum puede darnos más información que nos lleve a la necesidad de asistir a la Product Owner.

Más adelante, en la misma sección, dice:

"Los Scrum diarios mejoran las comunicaciones, identifican los impedimentos, favorecen la toma rápida de decisiones y, en consecuencia, eliminan la necesidad de otras reuniones".

Promover la rapidez en la toma de decisiones es una razón esencial para celebrar los Daily Scrum. 

Como revelan los datos del Informe Chaos del Standish Group, la latencia de las decisiones (el tiempo que tarda en tomarse una decisión) es el factor clave del éxito de un proyecto. Si esas decisiones implican cambiar las prioridades del Product Backlog o priorizar las interrupciones sobre el trabajo del Sprint Backlog, la aportación del Product Owner podría considerarse necesaria en el Daily Scrum.

Hay otras líneas en la Guía Scrum que aportan más aclaraciones. En una parte anterior, se explica:

"El Equipo Scrum es responsable de todas las actividades relacionadas con el producto, desde la colaboración con las partes interesadas, la verificación, el mantenimiento, el funcionamiento, la experimentación, la investigación y el desarrollo, y cualquier otra cosa que pueda ser necesaria."

y

"Todo el Equipo Scrum es responsable de crear un Incremento valioso y útil cada Sprint".

Por lo tanto, estos tomados en conjunto podría equivaler a un argumento racional de por qué el Product Owner debería estar en el Daily Scrum. 

Al fin y al cabo, si todo el equipo es responsable del Incremento, y todo el equipo es responsable de todas las actividades relacionadas con el producto, y el Product Owner forma parte -y no está separado- del Equipo Scrum, ¡entonces debería estar en el Scrum Diario!

 

Charla desde las trincheras

 

Dejemos a un lado la Guía Scrum y la teoría, y examinemos lo que hemos aprendido sobre el terreno. He encuestado a un grupo de profesionales experimentados en Scrum. Esto es lo que han dicho:

"El Product Owner pertenece al Daily Scrum. La ausencia de una sola persona indica que NO forma parte del equipo. No debe utilizarlo para pedir información actualizada ni para dirigir la reunión. Deben ESCUCHAR lo que el equipo tiene que decir y OFRECER una actualización propia. Si este acto se utiliza para imponer directa o indirectamente un sentido de importancia o jerarquía, pierde drásticamente su valor". - Toby Johnson, Director de Producto

 

"Los Roles Scrum internos deberían disiparse temporalmente para aprovechar un espacio de seguridad psicológica, ya que el Scrum Diario es una toma de pulso de "El Equipo". Aunque no se trata de un evento para apaciguar o proporcionar una actualización de estado al Product Owner, éste podría asistir pero como miembro del equipo y no sólo con su gorra de Product Owner". - Roy Nanku, ex NavalX Military Scrum Trainer y actual Consultor Scrum Inc.

 

"En mi experiencia, el Product Owner tiene que estar en el Daily Scrum porque siempre hay problemas en torno a las cosas que surgen, todo en torno a la priorización del 'qué'. " - Jessica Crowley, antigua Controladora de Proyectos para un gran fabricante de frenos de tren y Enterprise Agile Coach, actual Consultora Scrum Inc.

Así pues, parece que tenemos datos consistentes sobre la asistencia de Product Owners, pero que no está exenta de complicaciones. ¿Cuáles son los principales comportamientos de secuestro que presentan los Product Owners? Enumerémoslos y luego examinemos las soluciones.

 

¡Secuestrado! (Y volver al buen camino) 

 

Según la Guía Scrum, "el propósito del Scrum Diario es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el próximo trabajo planificado". Comprender el estado de un elemento de trabajo y lo que impide que avance es un ingrediente principal para ajustar el próximo trabajo planificado. 

Los compañeros de equipo que se ayudan mutuamente (a veces llamado "Swarming") es un patrón beneficioso que esperamos ver coordinado en cada Daily Scrum.

Al fin y al cabo, se trata de comportamientos. Cualquiera puede secuestrar o descarrilar la Scrum diaria y convertirla en improductiva o degradarla a una mera reunión de estado. Aunque es importante que todo el mundo conozca el estado del trabajo, lo más importante es encontrar la forma de que el equipo lo lleve a cabo.

¿Qué comportamientos Product Owner pueden hacer descarrilar un Scrum Diario? ¿Y cómo podemos evitarlos o curarlos? He aquí cinco categorías principales (con ejemplos) que vemos habitualmente y cómo solucionarlas. 

1) MicrogestiónEl comportamiento más debilitante que vemos es cuando los Product Owners se meten en la maleza de cada pequeña cosa que hacen los Scrum Master o los Developers. Un ejemplo de ello es cuando pasan a dictar el "cómo" en lugar del "qué" y aplastan la innovación. 

Un segundo ejemplo es cuando actúan como jefes de proyecto tradicionales y asignan trabajo a las personas. Un tercer ejemplo es cuando se centran demasiado en las métricas de rendimiento del equipo, como la velocidad, y se preguntan constantemente por qué los elementos del backlog no avanzan.

Cura: No te metas en el CÓMO Todo el mundo sabe que el Product Owner aporta algo, pero es mejor dejar que el equipo te deslumbre con su brillantez. En lugar de dictar cómo deben hacerse las cosas, hable en último lugar y utilice las preguntas para exponer los fallos de lógica de forma positiva o empujar al equipo a pensar más allá de lo establecido. Esto es especialmente difícil cuando el Product Owner es también un Developer, así que tenlo en cuenta. No asignes trabajo a los Developers. Deja que hagan lo que quieran y para lo que tengan capacidad. Coordinarlo es su trabajo, facilitado por el Scrum Master, no por el Product Owner. Manténgase centrado en las métricas de resultados y deje que el equipo se guíe por las métricas de producción (por ejemplo, velocidad, relación plan/hacer, etc.). La capacidad de autogestión del equipo es importante para crear una cultura de autonomía y responsabilidad.

 

2) El centro de atención: Hay tres versiones comunes de este comportamiento. La primera es dirigir la reunión. Es una expresión de microgestión. Especialmente si se lleva a cabo de forma que se obtenga la información que el Product Owner desea en lugar de que el Developers obtenga la información que necesita para maximizar la probabilidad de alcanzar el Objetivo del Sprint. La segunda es actuar como una audiencia unipersonal a la que los miembros del equipo deben presentar lo que han hecho. La tercera es ser visto como (y aceptar el papel de) la única fuente de respuestas.

Cura: Uno, no facilites el Daily Scrum. A menos que sea tu turno según un acuerdo de trabajo o algún otro arreglo. Deja que el Scrum Master ayude al equipo a decidir quién debe hacerlo si no es él mismo. Dos, no deje que el Developers hable sólo con usted. Anímale a hablar con el grupo; que se sienta cómodo sabiendo que intervendrás si es necesario. Esto incluye el lenguaje corporal, es decir, que no estén de cara a usted todo el tiempo. En tercer lugar, evita que los miembros del equipo te traten como una enciclopedia. Fomente las conversaciones entre los miembros del equipo con respuestas como: "Gracias por preguntarme. Antes de responder, me gustaría escuchar a los demás".

 

3) Calendario inadecuado de las nuevas solicitudes: Por supuesto, el equipo necesita conocer las nuevas solicitudes, pero ¿necesitan conocerlas hoy? Plantear nuevas solicitudes para escuchar las ideas del equipo, para que lo sepan, etc., puede ser muy perjudicial para el trabajo actual. Pone a los cerebros en modo de resolución de problemas para las cosas nuevas y desvía su atención de sus compromisos actuales. 

Cura: Introduzca nuevas solicitudes en el momento adecuado. Si realmente se trata de una interrupción importante, entonces el Scrum diario es perfecto para ello. Si no, entonces el mejor momento para introducirlas es en el Refinamiento del Backlog. Como plan de respaldo, podría hacerse como parte de una Revisión del Sprint. En cualquier caso, sea prudente a la hora de presentar nuevas solicitudes y piense en cómo afectará al enfoque y los compromisos del equipo. 

 

4) Retrasos o faltas sin avisar: Product Owners pasan mucho tiempo con clientes y partes interesadas, a menudo a expensas del tiempo que dedican a su equipo. Esto puede hacer que se sientan desatendidos o que formar parte del equipo Scrum sea menos importante que el resto del mundo.

Cura: Actúa como cualquier otro miembro del equipo y llega a tiempo. Si no puede hacerlo, respete el acuerdo de trabajo que haya establecido su equipo en relación con los retrasos o con la notificación a los demás de que no puede asistir. El equipo sabe que no vas a llegar a todas las Scrum diarias. Sé consciente de cuántas veces faltas a este y otros eventos y comprueba si las cosas se están desequilibrando. Haz un punto para bloquear tu calendario para el Scrum Diario (y otros eventos) para que tus compañeros de equipo sepan que estar con ellos es tan prioritario como hablar con aquellos a los que están al servicio.

 

5) Falta de información crucial: Aunque animamos a los Product Owners a compartir cuando es apropiado, también puede ser perturbador cuando las respuestas que busca el equipo no pueden obtenerse debido a que un Product Owner no está en contacto con las necesidades o los comentarios de los clientes.

Cura: Aunque la presencia con el equipo es digna de elogio, un Product Owner debe equilibrar su tiempo con los clientes y las partes interesadas. Al fin y al cabo, el objetivo de esas interacciones, y de la función del Product Owner en general, es ayudar a traducir esas necesidades y la información que las rodea en un backlog procesable para el equipo. Sin ello, pueden generarse impedimentos que el equipo no pueda despejar. Asegúrate de asistir a todas las revisiones de sprints y aprende a fomentar una buena retroalimentación sobre el producto y a capturarla y destilarla en un formato digerible que el equipo pueda utilizar.

 

Conclusión

 

 

¿Debería Product Owners asistir al Daily Scrum? El Product Owners debe estar presente en el Scrum diario, ya que es un miembro del equipo que tiene información crítica que compartir. Deben recordar que su presencia puede ser beneficiosa o perjudicial y que depende de ellos adoptar comportamientos que promuevan la agilidad del equipo y no desbaraten las conversaciones necesarias.