¿Es una buena idea designar a uno de los miembros del equipo scrum o al maestro scrum como propietario del producto?

Últimamente tuvimos un proyecto, en el que el cliente estaba ocupado de gira. Como se formó el equipo habitual de scrum, la gerencia decidió nombrar a nuestro analista como propietario del Producto ya que el Cliente no podrá participar activamente. El analista fue quien trabajó estrechamente con el cliente para el análisis de requisitos y la redacción de especificaciones.

El cliente no tiene tiempo para revisar los dos primeros lanzamientos. Todo salió bien hasta que el cliente vio el tercer lanzamiento; no estaba satisfecho con algunas funcionalidades, y esas fueron introducidas por el propietario del producto de turno (nuestro analista).

Nos dijeron que esperemos hasta que el equipo de diseño finalice la maqueta de todas las páginas y el cliente verificó cada una y aprobó continuar trabajando. El equipo Scrum está allí, pero no hay sprints: terminamos el trabajo casi como el clásico método de cascada.

¿Es una buena idea nombrar al miembro o maestro del equipo scrum como propietario del producto? ¿Necesitamos seguir scrum en ausencia de la participación del cliente / propietario del producto?

Hace solo unas semanas, Mike Cohn escribió sobre la combinación de los roles de scrum master y propietario del producto en su blog. No creo que pueda decirlo mejor que él, pero mi breve resumen de su publicación es este:

• es una mala idea
• SM y PO realizan tipos de tareas muy diferentes ("tareas estrella" y "tareas de tutor" en palabras de Cohn)
• es poco probable que la persona que combina los dos roles sea adecuada para todas las tareas involucradas en ambos roles
• El equipo puede verse afectado por el SM / PO combinado que descuida las tareas en las que no son los mejores.

Creo que no hay nada de malo per se en tomar un miembro de un equipo scrum y trasladarlo al propietario del producto. Pero debes darte cuenta de que es como una promoción o una transferencia interna; crea un hoyo en el equipo y el hoyo necesita ser llenado. Quizás el equipo pueda "autoorganizarse" para llenar el hueco; tal vez necesite contratar a un nuevo empleado para ocupar el puesto vacante.

Tu proceso me parece bien. No lo describió en detalle, pero al menos, se respetan los roles (esto es importante).

Sin embargo, con los pocos detalles que tengo, puedo ver algún problema a nivel del propietario del producto.

Él / ella debe asegurarse de que el cliente sea notificado adecuadamente del progreso. Parece que está haciendo "cascada" externamente con el cliente y "scrum" internamente con usted.

Resultado : la cascada gana ya que el cliente es el rey. Incluso si en este caso, el cliente tiene su responsabilidad ...

Su equipo actual (incluido Scrum Master), debe centrarse en entregar el retraso del sprint. Sin embargo, el propietario del producto (analista) debe asegurarse de que lo que está en su cartera de pedidos refleje lo que el cliente desea. También debe asegurarse de que la comunicación sea buena y que el cliente participe.

Posible solución : envíe a su propietario del producto (analista) a un curso Scrum Product Owner , o haga que lea (y comprenda) este libro: Gestión ágil de productos con Scrum .

Scrum funciona mejor con un cliente real en su lugar. Hay un par de desafíos reales al tratar con clientes que no están acostumbrados al diseño iterativo de productos.

• El síndrome de la hoja en blanco
• Síndrome de cliente asustado

Las etapas de diseño con una hoja en blanco tienden a aparecer en el cielo muy rápidamente, y generalmente profundizan en un par de cuestiones secundarias y no tienen suficiente profundidad en la funcionalidad central necesaria. Realmente necesita un hombre de paja para que el cliente lo separe para que las reuniones de diseño se desarrollen con éxito. Al enfocarse en un solo aspecto a la vez, está ayudando a su cliente a aprender diseño iterativo.

Los clientes asustados (como lo hizo con su experiencia) no se dan cuenta de que los proyectos ágiles anticipan una cierta cantidad de trabajo (controlado) como parte del proceso. Lo que les cuesta comprender es que a medida que avance el desarrollo del producto, habrá menos momentos de "Oh, Dios mío". Más importante aún, la parte con la que la mayoría de los clientes tienen dificultades es que los momentos de "Oh, Dios mío" no requieren mucho dinero para solucionarlos debido al corto tiempo entre los ciclos de revisión / planificación.

Gestionar las expectativas del cliente es muy difícil. Es un buen equilibrio de educación al cliente, aplacar e incluso aprender a decir "no". El cliente no siempre puede venir semanalmente o quincenalmente. A veces solo pueden venir una vez al mes. Está bien. Siempre y cuando les muestres lo que hiciste para abordar sus inquietudes el mes anterior, y luego concéntrate en el trabajo de este mes, será de gran ayuda para que el proyecto funcione sin problemas. La conclusión es que, en ausencia del cliente, usted tiene alguien que puede hacer recomendaciones razonables para algunas preguntas. Debe ser alguien familiarizado con los objetivos que el cliente intenta alcanzar.

Idealmente, el propietario del producto tiene cierto nivel de autoridad y conocimiento sobre el proyecto. Lo mismo podría haber sucedido si el cliente asignó a un empleado de nivel inferior que luego fue desestimado en una fase posterior que requiere que casi comience de nuevo.

Gracias por tu publicación. Me doy cuenta de que es viejo, pero creo que has planteado un gran caso y aquí están mis $ .02:

Problema 1: nombrar al analista como PO en su caso acorta seriamente el marco de scrum. ¿Por qué? Porque solo la OP puede hacer juicios de valor, evaluaciones de ROI, priorización y elecciones decisivas que fluyen del negocio, no de la tecnología, ni siquiera de la familiaridad con el producto. Estoy seguro de que tu sr. El analista hizo un trabajo fantástico imitando la orden de compra, pero finalmente tuvo que adivinar los deseos, valores y opciones que vendrían de su orden de compra. ref http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/ . A menos que el cliente le haya otorgado POA al analista (poco probable), no estará en condiciones de aceptar o rechazar nada en la revisión de sprint.

¿Podría este enfoque posiblemente funcionar? Sí, pero tendría que haber una transferencia total de responsabilidades mientras su cliente estaba fuera. El jefe de su cliente necesitaría estar de acuerdo con el sustituto y no se revertiría ninguna decisión razonable tomada. ¿Suena probable? Es más probable que obtenga una orden de compra temporal de la organización de su cliente (¡lo que ciertamente no está exento de inconvenientes!) Pero si su sr. analista trabajó con la orden de compra temporal, cualquier decisión incorrecta vendría del negocio, manteniendo así las funciones de su equipo limpias.

Problema 2: "el cliente no tiene tiempo para revisar". Gran problema (y uno con el que me encontré recientemente). PO debe estar presente para aceptar el producto. Nadie más puede 'firmar el cheque'. La ausencia de PO significa que la insatisfacción ocurre más tarde, potencialmente más retrabajo y pérdida de confianza. Más fundamentalmente, siento que el cliente no participa activamente en su proyecto: no hay tiempo para el standup diario, no hay tiempo para responder preguntas, etc.

Problema 3: "nos dijeron que esperemos hasta que el equipo de diseño termine la maqueta". Y ahora están fuera del scrum por completo. La gente que hace la maqueta debe ser parte de su equipo multifuncional. No puedo decir si esto es causado por la falta de comprensión de la administración del scrum o una reacción de choque a su tercer lanzamiento.

Pregunta: ¿Dónde estaba tu scrum master en todo esto? El SM normalmente reconocería el peligro del conflicto de roles y la falta de participación de la OP, ambos obstáculos / peligros que deben abordarse.