En Scrum, ¿por qué no deberían combinarse los roles Propietario del producto y ScrumMaster?

19

En los proyectos más tradicionales en los que he trabajado, el gerente del proyecto (y, en proyectos más grandes, puede haber gerentes de proyecto asociados / adjuntos / asistentes si una persona no está disponible) es la persona responsable de comunicarse con el cliente y recibir el proyecto. actualizaciones de estado y salud, determinando la programación y el presupuesto, administrando el proceso, asegurando que el equipo tenga lo que necesitan para completar las tareas, etc.

Sin embargo, en Scrum, estas responsabilidades se dividen entre el propietario del producto y el ScrumMaster. El propietario del producto es la voz del cliente. Interactúan directamente con el cliente, crean historias de usuarios, organizan y priorizan la acumulación de productos y otros problemas que enfrentan los usuarios / clientes. ScrumMaster maneja el proceso, supervisa las reuniones (incluida la estimación y planificación), elimina los impedimentos y supervisa el estado general del proyecto, haciendo los ajustes necesarios.

He leído en múltiples fuentes, incluida Wikipedia , que el papel de ScrumMaster y Product Owner debe ser desempeñado por dos personas diferentes. No solo leí sobre, sino que trabajé en proyectos exitosos de estilo "tradicional" donde las actividades de ambos eran manejadas por un solo individuo. De hecho, tiene más sentido que una o tres personas sean responsables del manejo del proyecto (incluyendo recursos humanos / personal) y tareas de nivel de proceso, ya que a menudo van de la mano. Los cambios en el proceso tienen un impacto en la programación, el presupuesto, la calidad y otras metas a nivel de proyecto, y los cambios del proyecto tienen un impacto en el proceso.

¿Por qué Scrum llama a aislar estas actividades en dos roles? ¿Qué ventajas ofrece esto realmente? ¿Alguien ha estado en un proyecto Scrum exitoso donde el propietario del producto y ScrumMaster fueran la misma persona?

— Thomas Owens
fuente

Además, juro que esta pregunta ya se hizo, pero no puedo encontrarla y no la destaqué como favorita. Aquí hay muchas preguntas sobre las definiciones de roles, pero no veo el PO / SM que estoy seguro de haber leído.

— Thomas Owens

¿Estás pensando en esta pregunta ?

— Adam Lear

@Anna Eso parece familiar, pero en realidad no parece ser un duplicado. Supongo que esta pregunta específica podría no haberse hecho antes.

— Thomas Owens

¿Qué tal este ? :)

— Adam Lear

1

Recomiendo leer Triunfar con Agile donde se discute esto con más detalle.

— Ladislav Mrnka

17

Pueden (y a menudo son) combinadas y realizadas por una sola persona (no hay ninguna regla en contra de esto (su scrum después de todo)).

PERO debe equilibrar la responsabilidad de la diferencia con cuidado ya que los dos roles tienen competencias y agendas (y se necesita una persona especial para poder hacer ambas cosas simultáneamente). He visto muchos intentos, pero pocos lo logran durante un largo período de tiempo (es una posición estresante).

Para ser el SM, necesita más conocimiento técnico que el PO (ya que ayudará a organizar el equipo de desarrollo). Se necesita un conocimiento detallado del producto para poder extraer elementos de la cartera de pedidos del producto en la cartera de pedidos de primavera (a veces simplemente no puede extraer los elementos 'n' superiores, ya que esto puede ser contraproducente).
El PO requiere una mayor comprensión del usuario final de la ecuación que ellos SM. No es necesario que sea tan técnico, pero sí requiere conocimiento de cómo se utilizará el producto en el mundo real y la dirección en que el cliente quiere tomar el producto.

Si puede encontrar una persona que pueda hacer ambos roles, entonces no veo ninguna razón para evitar esto.

Pueden surgir problemas cuando el cliente está tirando de la orden de compra en una dirección que está causando conflictos importantes a los desarrolladores (porque primero necesitan construir otra infraestructura). El trabajo de SM no es seguir los caprichos del cliente, sino proteger a los desarrolladores de sus caprichos. Lograr esto objetivamente es difícil.

— Martin York
fuente

1

Sí, como lo veo, es el conflicto de intereses lo que causa el problema. El propietario del producto quiere hacer todo lo posible, el scrum master necesita gestionar las expectativas del propietario del producto.

1

Tu descripción de SM es incorrecta. Estás describiendo algo como líder de equipo, no SM.

— Ladislav Mrnka

1

Estoy totalmente en desacuerdo con eso. PO y SM son dos trabajos realmente diferentes. borisgloger.com/2009/12/07/…

@Pierre Ese enlace se publicó en una respuesta. Como dije en respuesta a esa respuesta, todos menos 3 tienen argumentos en contra que puedo presentar aquí y ahora, y 3 es tan general que se aplica a todos los puestos de trabajo.

— Thomas Owens

3

También asegúrese de revisar esta publicación que habla específicamente sobre esto: blog.mountaingoatsoftware.com/… . Si mezclar los papeles funciona para usted, le prometo que le enviaré una caja de bombones belgas.

4

No soy un experto, pero creo que el Scrum Master debería ser el defensor / facilitador del equipo. La voz del cliente debe tener los intereses del cliente en el corazón. El Scrum Master debe ayudar a que el equipo obtenga lo que necesita para tener un sprint exitoso.

— Amy Anuszewski
fuente

1

Además, tenga en cuenta la mayoría de las veces, no está trabajando en 1 cliente a la vez. Los propietarios de productos pueden administrar varios clientes y pueden concentrarse en esa parte del negocio, y ScrumMasters pueden concentrarse en el desarrollo de proyectos.

Como muchos han dicho, ambos roles tienen intereses distintos, pero un objetivo común y diferentes habilidades para adquirirlo.

— AJC
fuente

Eso puede ser cierto. En cada lugar en el que he trabajado, el personal del "nivel de proyecto" (el equivalente de las OP y SM) se dedicó a un solo proyecto, por lo que este es el único marco de referencia que tengo. El equipo de desarrollo puede estar asignado a múltiples proyectos, pero típicamente incluso un desarrollador está asignado a un proyecto a tiempo completo y roles de soporte en uno o dos más.

— Thomas Owens

0

Si la misma persona representa al equipo de desarrollo y a los usuarios / clientes, el único recurso que tiene en una disputa es mirar el contrato. Aunque eventualmente puede llegar a esto, es mejor que un representante de ambos lados con el mismo poder pueda llegar a un acuerdo.

— JeffO
fuente

Si la orden de compra no es de la organización del cliente (que, según tengo entendido, con frecuencia es el caso), aún tendrá que consultar el contrato si hay una disputa entre la organización en desarrollo (incluida la orden de compra) y el cliente.

— Thomas Owens

1

Eso es cierto, pero tener un defensor del cliente en el personal puede ser capaz de manejar un desacuerdo antes de que vuelva al cliente. Si ambos no están de acuerdo con el cliente, ese es otro problema.

— JeffO

0

Las personas en los roles de Propietario del producto y Scrum Master pueden tener deseos, objetivos, requisitos y limitaciones en conflicto, más de 2 programadores aleatorios. Los seres humanos pueden o no ser capaces de valorar igualmente los objetivos en conflicto, y es más probable que cometan errores de juicio cuando se enfrentan a objetivos en conflicto. Dos personas con enfoques o sesgos ligeramente diferentes pueden ser menos propensos a cometer juntos los mismos errores o el mismo grado de errores de juicio.

Dos personas también pueden asignar más horas-hombre totales para enfocarse en cada aspecto diferente del problema / proyecto (por ejemplo, los objetivos de los 2 roles diferentes).

— hotpaw2
fuente