¿Es una buena idea designar a uno de los miembros del equipo scrum o scrum master como Propietario del producto?

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

• es una mala idea
• SM y PO realizan diferentes tipos de tareas ("tareas estrella" y "tareas de guardián" en palabras de Cohn)
• es poco probable que la persona que combine los dos roles sea una buena opción 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 malo en sí mismo en tomar a un miembro de un equipo de scrum y trasladarlo al Propietario del producto. Pero tienes que darte cuenta de que es como una promoción o una transferencia interna; se crea un agujero en el equipo y el agujero debe ser llenado. Tal vez el equipo pueda "auto-reorganizarse" para llenar el agujero; tal vez necesite contratar a un nuevo empleado para llenar el puesto vacante.

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

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

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

Resultado : la cascada gana porque 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 registro de sprint. Sin embargo, el propietario del producto (analista) debe asegurarse de que lo que está en su cartera refleja lo que el cliente quiere. Ella / él también debe asegurarse de que la comunicación sea buena y que el cliente participe.

Posible solución : envíe el propietario de su producto (analista) a un Curso de propietario de producto Scrum , o hágale leer (y entender) 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 del cliente asustado

Las etapas de diseño con una hoja en blanco tienden a ir más rápido en el cielo, y por lo general profundizan en un par de problemas secundarios y no tienen la suficiente profundidad en la funcionalidad básica necesaria. Usted realmente necesita un hombre de paja para que el cliente lo desmonte para que las reuniones de diseño se realicen con éxito. Al centrarse en un solo aspecto a la vez, está ayudando a su cliente a aprender el diseño iterativo.

Los clientes asustados (como usted tuvo con su experiencia) no se dan cuenta de que los proyectos ágiles anticipan una cierta cantidad (controlada) de retrabajo como parte del proceso. Lo que les cuesta entender es que a medida que el desarrollo del producto avance, habrá menos momentos de "Oh, Dios mío". Y lo que es más importante, la mayoría de los clientes con los que se lo pasan mal es que los momentos "Oh, Dios mío" no requieren grandes cantidades de dinero para solucionarlos debido al poco tiempo que transcurre entre los ciclos de revisión / planificación.

Gestionar las expectativas del cliente es muy difícil. Es un buen equilibrio entre la educación del cliente, la satisfacción, 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. Mientras les muestre lo que hizo para abordar sus inquietudes el mes anterior y luego se centre en el trabajo de este mes, esto hará que el proyecto se desarrolle sin problemas. La conclusión es que, en ausencia del cliente, usted tiene a alguien que puede hacer recomendaciones razonables para algunas preguntas. Es necesario que sea alguien familiarizado con los objetivos que el cliente está tratando de lograr.

Idealmente, el propietario del producto tiene cierto nivel de autoridad y conocimiento sobre el proyecto. Esto mismo podría haber ocurrido si el cliente asignara a un empleado de nivel inferior que luego fue anulado en una fase posterior que requería que comenzara de nuevo.

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

Problema 1: designar al analista como PO en su caso seriamente cortocircuita el marco scrum. ¿Por qué? Porque solo la OP puede hacer juicios de valor, evaluaciones de ROI, priorización y decisiones decisivas que surgen 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 al final tuvo que adivinar los deseos, los valores y las elecciones que provendrían de su orden de compra. ref enlace . A menos que su analista haya recibido el POA del cliente (poco probable), no estarían en posición de aceptar o rechazar nada en la revisión del sprint.

¿Podría funcionar este enfoque? Sí, pero tendría que haber una transferencia total de responsabilidades mientras su cliente estaba fuera. El jefe de su cliente tendría que estar de acuerdo con el sustituto, y no se anularían las decisiones razonables tomadas. ¿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. El analista trabajó con la orden de compra temporal, cualquier decisión incorrecta provendría de la empresa, por lo que mantendríamos limpios los roles de su equipo.

Problema 2: "el cliente no tiene tiempo para revisar". Gran problema (y uno que encontré recientemente también). 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 trabajo y pérdida de confianza. Más fundamentalmente, siento que el cliente no está involucrado activamente en su proyecto: no hay tiempo para el standup diario, no hay tiempo para responder preguntas, etc.

Problema 3: "nos dijeron que esperáramos hasta que el equipo de diseño terminara la maqueta". Y ahora están completamente fuera del scrum. La gente que hace la maqueta debe ser parte de su equipo multifuncional. No puedo saber si esto se debe a una falta de comprensión por parte 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 generalmente reconocería el peligro del conflicto de roles y la falta de participación de la OP, ambos obstáculos / peligros que deben abordarse.