Tenemos un Equipo Scrum de un Product Owner y cuatro desarrolladores (uno de los cuales es Scrum Master), ejecutando sprints de una semana. Según Scrumguides.org (énfasis mío):
La Retrospectiva del Sprint es una oportunidad para que el Equipo Scrum se inspeccione a sí mismo...
Eso incluye al Product Owner.
Siguiendo el consejo de Agile Retrospectives de Derby/Larsen, estamos tratando de centrar nuestra reunión en un tema específico. Tenemos iteraciones de una semana, por lo que generalmente cubrimos solo un tema cada semana.
Ahora, al menos la mitad de nuestras Retrospectivas estarán muy orientadas a la tecnología : hablar sobre cómo difundir el conocimiento técnico entre nosotros y otros equipos, mejorar las pruebas automatizadas, probar nuevas herramientas, etcétera.
Nuestro Product Owner no es muy técnico en absoluto, y no podrá contribuir demasiado en este tipo de Retrospectiva.
¿Alguna sugerencia sobre cómo lidiar con esto? ¿Hacemos esas retrospectivas solo con el equipo de desarrollo? ¿"Necesitamos" buscar formas de incluir también al Product Owner?
Idealmente, el propietario del producto estará presente y encontrará la retrospectiva interesante y gratificante.
Sin embargo, si el propietario del producto no ve su valor en las conversaciones técnicas, hay algunas cosas que puede hacer:
No soy un gran admirador de los dos últimos de estos enfoques. Pero creo que el primero se puede hacer funcionar.
El objetivo retrospectivo es, entre otros,
Inspeccionar cómo fue el último Sprint con respecto a las personas, las relaciones, los procesos y las herramientas;
Aunque usted siente que la mayor parte de la discusión girará en torno a problemas técnicos, ese podría no ser necesariamente el caso. Sin mencionar que resolver problemas técnicos es una forma de alcanzar un objetivo comercial y agregar valor, no un ejercicio en sí mismo, por lo que la OP puede y debe opinar al respecto.
Incluir al propietario del producto siempre es una buena práctica. No tengas miedo de que no lo consiga. Después de algunas retrospectivas, debería comprender mejor el origen de la historia tecnológica y la complejidad general de un proyecto. Él también es parte de un equipo, y tal vez tenga problemas con los que compartir.
https://www.mountaingoatsoftware.com/blog/the-product-owner-in-a-sprint-retropsective
Ya se han hecho muchos puntos buenos.
Uno más para agregar: A veces, el elemento de acción de una discusión completamente técnica será agregar un elemento al trabajo pendiente que es más técnico. Para que la OP pueda priorizarlo frente a otros elementos, debe comprender su valor. Entonces, incluso una discusión completamente técnica es hasta cierto punto útil para él.
De preferencia el Product Owner asiste a todas las retrospectivas, esto le ayudará a mejorar la forma de trabajar en conjunto con los miembros del equipo.
Asistir a la discusión técnica puede aumentar la comprensión de la forma en que el equipo desarrolla su producto y el efecto de esto en la calidad del producto. Por ejemplo, cuando el equipo ha acumulado una deuda técnica, pueden analizar estrategias junto con el propietario del producto para reducir la deuda y evitar que la calidad se degrade aún más.
Es importante tener siempre en cuenta que el PO en virtud de su posicionamiento en el equipo scrum posee la visión del producto.
En segundo lugar, siempre tenga en cuenta el propósito y el objetivo de las retros: revisar e inspeccionar cómo fue el último sprint, qué se hizo bien, qué se podría haber hecho mejor y cómo el equipo multifuncional manejó las relaciones, los procesos y las herramientas. .
Conduciendo esto a casa, es imperativo que vea la reunión retrospectiva más allá de discutir los tecnicismos del proyecto, maneje esto concentrándose en el objetivo comercial general que, en sí mismo, no es técnico.
Una OP no técnica sin duda tendrá una mentalidad comercial y aprenderá lecciones y comprenderá mejor cómo alcanzar los objetivos y valores comerciales.
Simplemente sí, el Product Owner es parte del equipo de entrega y los contenidos de la retrospectiva impactan directamente en su rol. Un gerente de producto, por el contrario, no necesita estar presente.
El Product Owner es un cerdo mientras que el Product Manager es un pollo :) El Product Owner está comprometido .
El problema real podría ser que lo retro es demasiado técnico, lo cual no debería ser. Ciertamente, puede identificar áreas técnicas que necesitan mejoras, pero las inmersiones profundas deben hacerse fuera de lo retro.
Del blog de Roman Pichler: La guía del propietario del producto para la retrospectiva de Sprint
Como propietario del producto, usted es miembro del equipo Scrum, que también incluye el equipo de desarrollo y el ScrumMaster. Mientras está a cargo del producto, confía en la colaboración de los otros miembros del equipo Scrum para crear un producto de software exitoso. Si no asistes a la retrospectiva como propietario del producto, desperdicias la oportunidad de fortalecer la relación y mejorar la colaboración con ellos.
Pero hay más: participar en la retrospectiva del sprint le permite comprender por qué el equipo requiere algo de tiempo en el siguiente sprint para realizar mejoras, como refactorizar el script de compilación o investigar una nueva herramienta de prueba; y quizás lo más importante, te ayuda a mejorar tu propio trabajo.
Digamos que algunas de las historias de usuarios en las que el equipo había trabajado no se terminaron en el sprint. A primera vista, esto parece culpa del equipo de desarrollo. Pero analizar el problema bien puede revelar que el tamaño de las historias y la calidad de los criterios de aceptación contribuyeron al problema. Como usted es responsable de garantizar que la cartera de productos esté lista, este hallazgo afecta su trabajo: le muestra que debe descomponer aún más las historias de usuario y sugiere que se debe mejorar la participación del equipo de desarrollo en la preparación de las historias; de lo contrario, habría detectado el problema antes de que las historias entraran en el sprint.