¿El propietario del producto puede trabajar con un segundo equipo?
- Categorías Leadership, Management, Product Owner, Scrum
- Fecha 10/03/2023
Durante varios años, la comunidad Scrum estuvo plagada de confusión al usar la palabra equipo. Dado que teníamos un equipo Scrum (compuesto 1 Scrum Máster + 1 Propietario de producto + equipo desarrollo) y un equipo de desarrollo, cada conversación necesitaba aclaración sobre a qué equipo se refería. En la versión 2020 de la Guía Scrum, los autores eliminaron el término “equipo de desarrollo” en favor de simplemente “Desarrolladores”, en parte con la esperanza de poner fin a esta confusión. Finalmente, solo tenemos un equipo: el equipo Scrum.
Ahora que esto se ha abordado y se ha dejado de lado toda confusión, propongo que todavía hay un segundo equipo y que es vital para un propietario de producto exitoso.
Los propietarios de productos deben acercarse a sus partes interesadas como miembros del equipo para maximizar la comunicación y la colaboración en ese grupo.
Por supuesto, los propietarios de productos son claramente miembros de pleno derecho del equipo Scrum. Piense en una revisión de Sprint: todo el equipo Scrum presenta el incremento de su producto a quienes están fuera de su equipo Scrum. La línea de demarcación es clara: los de adentro(producción) se presentan a los de afuera(los que piden).
Sin embargo, he visto a muchos propietarios de productos tratar a sus partes interesadas como un conjunto de personas, cada una con sus propias necesidades y deseos. Estos Propietarios de productos van de una parte interesada a otra no solo para recopilar sus comentarios, sino también para compartir información entre sus partes interesadas. Se enredan al tratar de explicar a una parte interesada por qué cierta característica es importante para otra parte interesada. Desperdician energía haciendo malabarismos con las prioridades de las partes interesadas individuales.
Los propietarios de productos exitosos ven a sus partes interesadas como un equipo.
Al igual que lo hace un equipo Scrum, su equipo de partes interesadas debe colaborar para tomar decisiones. Las partes interesadas tienen que convencerse mutuamente de la prioridad de sus funciones: abandonan el juego con un acuerdo común sobre el orden de prioridad.
Si tiene un conjunto de partes interesadas individuales, aquí hay algunas maneras de ayudarlos a actuar como un equipo:
- Reúnase como equipo: si tiene reuniones individuales regulares con sus partes interesadas, considere reuniones grupales periódicas. Cuando haga de esto una rutina, las partes interesadas llegarán a contar con ese momento específico como su oportunidad de ser escuchados. Y si algunas partes interesadas no lo logran, probablemente tenían prioridades más altas que esa reunión. Las partes interesadas que más necesitan ser escuchadas serán las que se presenten.
Perfeccione sus habilidades de facilitación: ¿qué va a hacer con sus partes interesadas una vez que los tenga a todos juntos? Un poco de habilidad de facilitación puede ser muy útil aquí. Ofrézcales múltiples formas de expresar sus opiniones y hacer que se escuchen sus voces. Cree actividades en las que las partes interesadas discutan el producto entre sí. Proporcione el espacio y una estructura para que puedan ofrecer sus ideas, considerarlas juntos y tomar decisiones grupales sobre ellas.
- No trate a todas las partes interesadas por igual: debemos reconocer como propietarios de productos que tenemos diferentes tipos de partes interesadas. Nuestro objetivo es identificar a nuestros principales interesados y gastar nuestros esfuerzos en formarlos en un equipo. Las partes interesadas tienen un interés alto o bajo y tienen un poder alto o bajo. Estamos muy interesados en las partes interesadas de alto interés/alto poder. Necesitará estrategias para cada uno, pero si no cuenta con las partes interesadas de alto interés/poder en la sala, es posible que esté perdiendo el tiempo.
💡 Si bien solo hay un equipo en Scrum, los propietarios de productos tendrán más éxito cuando traten a las partes interesadas como un segundo equipo. Después de todo, el Manifiesto Ágil nos dice que “las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados”. ¿Por qué no aplicaríamos esta sabiduría también a nuestros grupos de interés?
Etiqueta:product owner, SCRUM