Siete errores comunes de los nuevos Scrum Masters al servicio de los Product Owners

Siete errores comunes de los nuevos Scrum Masters al servicio de los Product Owners

Hace poco me encontré con un video de Mike Cohn sobre siete errores que todo Scrum Master comete y qué hacer al respecto. En resumen, estos son los siete descuidos según Mike:

1. Compartir opiniones con demasiada facilidad

2. Imponer ideas en lugar de venderlas

3. Dirigir la Daily Scrum

4. Omitir eventos clave de Scrum

5. Tratar la guía de Scrum como una biblia

6. Pensar que todo es una historia de usuario

7. Permitir que el trabajo sin terminar avance de sprint en sprint

Puedes ver el video completo en el siguiente enlace:

7 Mistakes Every Scrum Master Makes, And What to Do About Them (youtube.com)

Precisamente, basado en ese video, quise ir más allá, aportar de mi experiencia acompañando equipos y organizaciones en este trasegar ágil. En particular, he visto que muchos Scrum Masters, sobre todo los que inician por su ruta ágil tienen sendos traspiés cuando se trata de servir al Product Owner. Muchos, de hecho, ni siquiera acompañan a su PO a hacer el trabajo de este.

No es un pecado si eres Scrum Master por primera vez o estás en las primeras de cambio. El asunto comienza a convertirse en problema si ya han pasado unos cuantos sprints y sigues igual. No puedes promover la mejora continua si tú mismo no la practicas. Ahora bien, necesitas compañía, coaching y mentoring, no intentes hacerlo solo.

Veamos entonces estas siete faltas (que no pecados):

1. Soporte inadecuado en la definición del objetivo del producto

Un Objetivo de Producto bien definido sirve como brújula para el equipo, guía su trabajo durante el sprint y asegura la alineación. Pero los nuevos Scrum Masters pueden pasar por alto la relevancia de apoyar activamente a los Product Owners a crear metas claras y accionables.

Ejemplo: Un Product Owner podría proponer una meta vaga como «aumentar la satisfacción del cliente». Parece un buen objetivo, de valor, pero realmente adolece de la especificidad necesaria y suficiente para enfocar los esfuerzos del equipo.

Recomendación: Si trabajas de manera colaborativa con tu Product Owner para refinar el objetivo del sprint, es muy probable que lleguen con una mejor propuesta a la Sprint Planning y lograr que sea un objetivo SMART (Específico, Medible, Alcanzable, Relevante, Limitado en el Tiempo).

Ejemplo de corrección: De distintas maneras puedes mostrarle a tu PO que «aumentar la satisfacción del cliente» no es la mejor propuesta de Meta del Sprint y ayudarlo con distintas técnicas para ir de esa propuesta inicial a algo como «reducir los tickets de soporte al cliente en un 20 % en el próximo trimestre al mejorar la usabilidad del producto».

Recordatorio: de lo que se trata es de que proporciones orientación proactiva y garantizar que el Objetivo del Producto esté bien definido. De esta manera, comienzas a convertirte en un Scrum Master extraordinario y contribuyes en grande al éxito del equipo. ¡Y el Product Owner te lo agradecerá!

2. Soporte ineficaz para la gestión del product backlog

Como antes, parto de la base de que es algo involuntario, pero tu falta de experiencia como Scrum Master puede entorpecer el trabajo de tu Product Owner puesto que no le brindas un servicio apropiado para la gestión del product backlog. Como consecuencia directa el equipo en pleno obtendrá un backlog desorganizado, demasiado grande o ambiguo.

Ejemplo: un product backlog lleno de docenas de elementos (léase historias de usuario) de baja prioridad crea confusión e ineficiencia. Esto causa que el equipo pierda tiempo en tareas que no contribuyen directamente a avanzar hacia el logro del Objetivo del Producto.

Recomendación: facilita sesiones regulares de refinamiento del backlog y guía a tu Product Owner en la priorización y ordenamiento y de las historias de usuario según su valor para el cliente final y para el negocio.

Ejemplo de corrección: motiva y enseña, si es necesario, al Product Owner a adoptar un método de priorización basado en el valor, como MoSCoW, WSJF, RoI, el costo de la demora, o algún otro, para que finalmente el equipo se centre en las características imprescindibles que se alineen directamente con el Objetivo del Producto y la visión del negocio.

Recordatorio: emplea técnicas como el Mapeo de Historias de Usuario para visualizar el camino del usuario con el producto y garantizar que se prioricen las historias de usuario de mayor valor actual. Tu misión, como Scrum Master, es ofrecer orientación y soporte efectivos al Product Owner, para que este mejore de manera significativa la eficiencia y la eficacia de la gestión del product backlog.

3. Falta de apoyo en la clarificación de los elementos del product backlog

Es muy probable que tu Product Owner tenga buen conocimiento del negocio, de lo que quiere el usuario, pero eso no garantiza que los elementos en el product backlog estén claramente definidos y sean concisos. También, como Scrum Master novel, es probable que no procures la orientación suficiente a tu PO para corregir esto. De allí a disminuir la capacidad del equipo para entender y ejecutar las tareas de manera efectiva hay solo un paso.

Ejemplo: una historia de usuario mal articulada, como «mejorar el rendimiento del sitio web», carece de los atributos necesarios para su implementación.

Recomendación: ayuda a tu Product Owner a crear historias de usuario que cumplan con los atributos INVEST. Pero más que nada, ayuda a generar un entorno donde las conversaciones entre el PO y su entorno (interesados, usuarios, mercado, regulaciones, competencia, etcétera), y el PO y los Developers fluyan por doquier. Sobre esto último escribí extensamente en mi anterior artículo:

De la especificación a la conversación – Lucho Salazar

Ejemplo de corrección: guía al Product Owner en el refinamiento de «mejorar el rendimiento del sitio web» en historias más pequeñas y específicas o incluso criterios de aceptación como «reducir el tiempo de carga de la página de inicio en un 20 % optimizando las imágenes».

Recordatorio: facilita talleres colaborativos para dividir las partes complejas o grandes del backlog en historias de usuario manejables y bien definidas. Si no sabes cómo hacerlo, tu misión es buscar a alguien que les enseñe a todos. Tu objetivo es garantizar la claridad y la especificidad en las historias de usuario; cuando lo logres, verás como se incrementa significativamente la eficiencia y la productividad del equipo y, sobre todo, la entrega de valor.

4. Descuido en la planificación empírica del producto

Como Scrum Master puedes llegar a creer que tu Product Owner lo hace bien cuando planifica el producto de manera empírica, pero recuerda que nos movemos en entornos dinámicos de alta incertidumbre, así que no subvalores el acompañamiento que le puedes ofrecer.

Ejemplo: la mayoría de los Product Owners que conozco dependen únicamente de la planificación a largo plazo basada en suposiciones y he visto cómo esto resulta en esfuerzos desperdiciados cuando las condiciones del mercado cambian intensamente.

Recomendación: eres el Scrum Master, así que aboga por ciclos de planificación cortos (por ejemplo, a través de los Objetivos de Sprint) y enfatiza los principios de inspección y adaptación de Scrum.

Ejemplo de corrección: en lugar de una planificación detallada en el mediano o largo plazo, ayuda a tu PO a implementar un enfoque donde los [2 o 3] sprints siguientes se planifican en detalle mientras los futuros sprints permanecen flexibles.

Recordatorio: aprende a facilitar sesiones de planificación de producto que prioricen los resultados y el valor. Promueve el uso de datos históricos de sprints anteriores para la toma de decisiones. Cuando fomentas un enfoque empírico para la planificación del producto, estás ayudando no solo a tu PO, sino al equipo en general a adaptarse más efectivamente a los escenarios cambiantes y a entregar valor de manera más consistente.

5. Facilitación inadecuada de la colaboración con los interesados

Te entiendo. Es posible que no sepas como asumir un papel activo para garantizar que tu Product Owner tenga las herramientas y los métodos adecuados para fomentar una colaboración regular y constructiva con los interesados y su entorno.

Ejemplo: el Product Owner no es capaz de conseguir retroalimentación oportuna de los interesados clave o de los usuarios finales o el mercado y esto converge en retrasos y pérdida de oportunidad. Al final, no es posible responder a los cambios del entorno de manera certera.

Recomendación: como Scrum Master ayuda a organizar y facilitar reuniones con los interesados (por ejemplo, Sprint Reviews) y promover la transparencia en la comunicación con los interesados. Aprende y despliega tu conocimiento de distintas técnicas, instrumentos, formas y protocolos para que las revisiones de producto sean efectivas y concluyan con los ajustes adecuados al product backlog que satisfagan nuevas oportunidades.

Ejemplo de corrección: programa reuniones recurrentes con los interesados durante las Revisiones de Sprint y establece un ciclo de retroalimentación para garantizar que todos inspeccionen los incrementos del producto y ofrezcan retroalimentación de manera temprana y frecuente.

Recordatorio: enseña y anima a tu Product Owner a utilizar instrumentos como mapas de ruta y tableros de progreso visual para mantener informados a los interesados. Cuando fomentas relaciones sólidas y colaboración con las personas en el entorno del equipo, lo estás ayudando a entregar productos que satisfagan con creces las necesidades de los clientes.

6. Ocupar “la silla” del Product Owner

Por tu falta de experiencia como Scrum Master te puede tentar el deseo de invadir responsabilidades del Product Owner, como tomar decisiones sobre priorización u ordenamiento o, incluso, definir elementos del product backlog (historias de usuario), o permitir que alguien más lo haga.

Ejemplo: con el mejor de los ánimos, quizás quieras comenzar a priorizar elementos del backlog durante las sesiones de refinamiento sin la participación del Product Owner, socavando su responsabilidad de maximizar el valor del producto. Esta es una tarea que nunca debe realizarse en ausencia de tu PO.

Recomendación: adhiérete a los límites de tu rol como Scrum Master y enfócate en la facilitación y en la mejora continua en lugar de la toma de decisiones relativas al product backlog, entre otras. Tienes mucho trabajo por hacer como Scrum Master, solo te falta aprenderlo a hacer. En ese sentido, te recomiendo el libro que escribí con Jorge:

[Nuevo Libro] Scrum: Epítome de experiencias – Lucho Salazar

Ejemplo de corrección: si observas que tu Product Owner tiene dificultades con la priorización, puedes enseñarle y sugerirle técnicas (por ejemplo, Weighted Shortest Job First o WSJF, MoSCoW, Costo-Beneficio, etcétera) pero, en última instancia, promueve y permite que tu PO siempre tome la decisión final.

Recordatorio: fomenta con el equipo y los interesados que el Product Owner es el único responsable de gobernar sobre el product backlog. Si respetas las responsabilidades de tu PO y ofreces el servicio apropiado, favorecerás un entorno de trabajo más eficaz y, sobre todo, colaborativo.

7. Fallar en desarrollar una mentalidad de producto en el equipo

Esta te la valgo durante las primeras de cambio: valorar más el proceso [Scrum] sobre el producto, aunque sea de manera involuntaria, en vez de guiar al Product Owner y al equipo en el desarrollo de una mentalidad centrada en el cliente y, por consiguiente, en el producto.

Ejemplo: el equipo puede enfocarse en completar tareas sin considerar su contribución a los resultados de valor para el usuario o el Objetivo del Producto.

Recomendación: impulsa un entorno donde las discusiones sobre el «por qué» detrás del trabajo, el problema detrás del problema, la causa raíz, sea el “pan de cada día”, una cultura donde las tareas de cada miembro del equipo se conecten con las necesidades del cliente y el valor para la empresa.

Ejemplo de corrección: enseña y motiva el uso de User Personas, mapas de empatía y otros instrumentos que permiten conocer mejor al usuario. Cuéntale a tu PO los beneficios de que los Developers también vean al usuario en acción, en su lugar de trabajo y de evaluar frecuentemente cómo las historias de usuario terminadas impactan al usuario final o al cliente. Aliéntalo a recopilar y compartir la retroalimentación de estos últimos.

Recordatorio: acuerda el uso de métricas como la satisfacción del cliente, el Net Promoter Score (NPS) o los datos de uso del producto para demostrar a los interesados el valor e impacto reales del trabajo del equipo.

Llamado a la acción

Ahí los tienes. Ya va siendo hora de que reflexiones sobre estas faltas habituales y tomes medidas eficaces para mejorar tus prácticas. Comienza organizando una sesión con tu Product Owner y el equipo Scrum en pleno para revisar y mejorar tus procesos actuales. El “cómo lo estoy haciendo”. Motiva conversaciones francas y ten el coraje de hacer lo necesario para lograr una asociación más sólida y colaborativa en el equipo.

Los productos que generan gran impacto se construyen con inteligencia colectiva. Tu trabajo es lograr eso en tu equipo, incluyendo al Product Owner.