El rol del Product Owner en Scrum

el rol del product owner en scrum

Mucho se ha escrito sobre el rol del Product Owner (PO) en Scrum a lo largo de los años y me parece que en el último mes la cuestión ha recibido mucha atención en blogs, Twitter y otras redes sociales. No creo que haya una respuesta de «mejores prácticas». Echemos un vistazo a lo que sabemos y luego veamos si podemos encontrar una respuesta. El objetivo del OP debe ser proporcionar el valor comercial adecuado. Para hacer esto, involucran a los equipos para crear soluciones que brinden valor comercial.

Están escuchando y evaluando las necesidades de la comunidad de partes interesadas. Necesitan tener una gran visión para los negocios y comprender el mercado y los clientes. Necesitan entender lo que es técnicamente posible. A partir de todos estos aportes, proporcionan un flujo de información al equipo sobre cuáles son las prioridades. Constantemente actualizan esta información y evalúan los resultados del equipo para verificar que estén completos y correctos. Si bien el equipo tiene el mismo objetivo de brindar valor comercial, su espacio problemático es muy diferente. En todos los dominios y proyectos, excepto en los triviales, esto requiere un enfoque de equipo. La formación de equipos no se trata de dinero. ¡Pregúntale al dueño de los Yankees, George Steinbrenner!

La formación de equipos no se trata de tecnología o computadoras. La formación de equipos se trata de personas. Sin embargo, los problemas que enfrenta el equipo para brindar las soluciones se relacionan con la tecnología. El equipo toma la dirección (curso) del OP, ¡pero él o ella no pueden trabajar en la sala de máquinas de la nave Scrum! No es que no estén calificados (puede que no lo estén), es solo que su función principal es tan importante y requiere tanto tiempo que descuidarían ese deber si lo hicieran. El equipo debe tomar la dirección (camino) del OP. Su trabajo requiere toda su atención. Sabemos todo esto. La verdadera pregunta es ¿cómo podemos crear mejor la comunicación y la retroalimentación que el Producto necesita para que la empresa pueda tener éxito y prosperar? Scrum proporciona un gran lugar para comenzar. Lean nos ayuda a comprender la visión del producto y el flujo de valor comercial. El proceso de planificación del lanzamiento de un producto debe incluir información del equipo. La planificación de Sprint es un proceso cooperativo entre el equipo y el propietario del producto.

El stand-up diario es una reunión de equipo que es el núcleo de la formación de equipos. Scrum nos dice que el equipo de gestión de productos puede escuchar esta reunión, pero es la reunión del Equipo. Si yo fuera Product Owner, si es posible, estaría en el trabajo diario. La revisión y demostración de Sprint se trata de que el equipo reciba comentarios del propietario del producto y cualquier persona interesada. Si estuviera en un equipo, NUNCA iría a una revisión de Sprint sin saber qué piensa el propietario del producto sobre el resultado de Sprint. La retrospectiva de Sprint es una reunión de equipo. Esta reunión se centra principalmente en la formación de equipos y el perfeccionamiento de procesos. Esta debe ser una reunión privada del equipo.

¿Puede el Product Owner ser una ventaja para el equipo en el proceso diario de desarrollo de soluciones? Depende ¿Cuánto tiempo tienen? ¿Qué tan bien entienden la tecnología? ¿Qué tan bien trabajan dentro del equipo? Nadie puede saber las respuestas a estas preguntas sin observar al Dueño del Producto y al Equipo. ¿Será el propietario del producto un miembro útil, aceptado y valioso del equipo? Depende ¿Puede el Product Owner proporcionar el flujo de información y decisiones al equipo con un alto nivel de precisión? Depende Con todas estas incógnitas, no creo que nadie pueda decir cómo un propietario de producto y un equipo determinado podrán trabajar mejor juntos sin conocimiento de primera mano.