¿Qué tan importante es tener el PO dentro del equipo?

Creo que el propietario del producto es un miembro importante del equipo y debe ser tan accesible como cualquier otro.

Recientemente me enfrenté a la idea de que debido a que el PO es parte del 'negocio' (es decir, el cliente) no debe ser considerado como miembro del Equipo.

Dicho de otra manera: deben asistir a reuniones importantes y a la mayoría de los stand-ups, pero limitar su participación para evitar tratar de controlar el proyecto (como se ha convertido en una mala práctica para los BA o la gestión de proyectos).

¿Deberían mantenerse a distancia o completamente adoctrinados en el proceso ágil?

Como dice Mitch Lacey en su libro utilizando la analogía de un automóvil: el equipo de desarrollo es el motor, el scrum master son los líquidos necesarios para hacer funcionar el automóvil sin problemas y el PO es el conductor. Además, si desglosa el rol tradicional de gerente de proyecto, PO en realidad asume más tareas que incluso SM. Entonces, sin un PO capaz, estás disparando en la oscuridad.
La Guía Scrum o es Scrum solo de nombre.

Respuestas (6)

El PO es un miembro importante del equipo ágil, pero debe permanecer estrictamente dentro de su definición de funciones, que según este artículo :

El propietario del producto , llamado cliente en el sitio en XP y parte interesada activa en AM, representa a las partes interesadas. Esta es la única persona responsable en un equipo (o sub-equipo para proyectos grandes) que es responsable de la lista de elementos de trabajo priorizados (llamada acumulación de productos en Scrum), de tomar decisiones de manera oportuna y de proporcionar información de manera oportuna. manera oportuna.

Debido a la naturaleza de su rol y la cultura de la que provienen, puede haber una tendencia de ellos a controlar el equipo, pero el scrum master debe asegurarse de que el propietario del producto no traspase los límites.

Acordado. "Mantener alejado al PO" es la manera más fácil de evitar que actúen fuera de su rol, pero no es una muy buena manera, a menos que todo lo demás falle.

Se supone que el PO no debe controlar el equipo, pero él ES quien controla el proyecto en el sentido de que prioriza la acumulación.

No veo por qué un PO tendría que asistir a los stand-ups. No tiene nada significativo que aportar en ese momento. Lo más probable es que su inclusión sea solo una forma conveniente (para SM) de mantenerlo actualizado sobre el progreso (que no es el objetivo de los stand-ups). Por el contrario, pude ver cómo esto podría conducir a intentos del PO de controlar el equipo...

Definitivamente deberían estar bien informados sobre scrum y en estrecha cooperación cuando se trata de desarrollar los elementos del backlog.

Si quieres contarlo como parte del equipo es secundario. Si hace las cosas que debe y no hace las cosas que no debe...

Diría que depende del contexto, ¿es el PO el único que conoce los requisitos comerciales o los desarrolladores pueden tomar buenas decisiones incluso sin el PO?

"Creo que el propietario del producto es un miembro importante del equipo y debe ser tan accesible como cualquier otro". Si sientes que él/ella es importante, entonces probablemente lo sea.

La solución real es definir claramente los roles y responsabilidades y tener a las personas adecuadas para que los ocupen. Tener un PO que les diga a los desarrolladores cómo hacer las cosas es un gran problema, pero también lo es tener un PO que se siente aislado y que no forma parte de la ejecución.

Por lo tanto, hay algo de arte en la construcción de equipos efectivos y se debe prestar atención a la asignación de personas con las habilidades correctas y el comportamiento apropiado para los roles clave.

Si desea una ejecución efectiva, todos deben formar parte del equipo con total transparencia.

Supongo que el Product Owner (PO), por importante que sea, no tiene por qué estar dentro de un equipo específico. Él/ella podría manejar un par de equipos/proyectos.

En realidad, el PO también puede ser el gerente del proyecto e incluso otro rol. Realmente depende del tamaño del equipo, el proyecto y el 'espíritu' de la organización.

Si hay una brecha en la forma en que el equipo entiende las prioridades y las necesidades comerciales, entonces cuanto más se involucre el PO, mejor.