La propia puerta, y el modo en que se abrió, al menos a mi, me trajo a la mente esa escena típica en tantas películas, esa en la que lentamente una pesada puerta de barrotes se empieza a deslizar, mientras al otro lado espera ese condenado, peligroso, esposado y vestido con un mono naranja. O, si lo quieres más simple, a la escena en que C3PO se queda mirando incrédulo como, cuando ya se iba a ir, se abre la pesada puerta del palacio de Jabba.
Al otro lado, por desgracia, no había ni un peligroso preso ni el temido Jabba, sólo había un alterado Product Owner que, sin mediar saludo, se apresuró a a decir… «¿puede un miembro del equipo hablar con un cliente o solo puede hacerlo el Product Owner?» Esa fue la recepción que me esperó.
Lo normal, lo típico, lo más común, es que la comunicación con los clientes (extensible a los llamados Stakeholders) recaiga exclusivamente en el Product Owner. Hay muchas razones que justifican esto, por ejemplo, las más destacadas:
– Esto evita interrupciones al equipo técnico.
– Evita cambios continuos de prioridades.
– En síntesis, evita desperdicios.
Siendo el Product Owner el responsable del Product Backlog, y de sus items, y de las típicas Historias de Usuario que lo habitan y que suele haber en un Product Backlog, debiera tener conocimientos suficientes para poder explicar y resolver dudas sobre los mismos, funcionales, de producto, con capacidad para decidir qué entra y en qué orden. Todo lo anterior, típicamente, no debe requerir del equipo técnico.
Esto es lo típico, lo normal y lo sensato, lo que provoca menos desperdicios a los equipos técnicos.
Pero sonaría poco a auto-organización, poco a Shu-Ha-Ri, y mucho a prescripción y Taylorismo, fijar reglas inamovibles, desde la lejanía y para todos los contextos. Piensa, en vez de relajarte haciendo lo que dicen otros o lo que dice algún manual, piensa.
Porque puede darse el caso, que yo tomaría como excepción mas que como regla, de que hay que explicar a un cliente algo muy complejo, que tiene más sentido que lo cuente quién más sabe de ello, pudiendo ser alguien del equipo técnico.
Pero, en cualquier caso, en casos como los anteriores, el Product Owner debe estar al tanto y ser el guardián que celosamente custodia la llave de esa poderosa puerta que permite interrumpir a los equipos, que, como en las películas, solo se abre en ocasiones especiales.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Desde mi experiencia, sí que el Product Owner debe ser el guardián de los requerimientos de los clientes, quien prioriza, organiza y comunica todas las historias y necesidades que surjan. Sin embargo, en caso de que falle comunicando la importancia de una funcionalidad en especial, o en caso de que haya un miembro un poco terco, creo que es importante que haya una comunicación directa con el equipo técnico. Muchas veces nos olvidamos la importancia de una visión de producto en ellos y si nosotros por alguna razón no lo logramos, pues es un buen método.
Hola Javier,
¿Esta opinión no te parece contradictoria con la práctica de una «Scrum Review» en la que participan los stakeholders tal y como propugna Scrum?
Sprint Review: time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.
https://www.scrum.org/scrum-glossary
Además, recuerdo haberte leído en alguna otra entrada que era fundamental la participación de los stakeholders en está reunión.
Un saludo
Hola,
en el post quería plantear la situación en la que el Review no es suficiente, o en la que se necesita una explicación, o conversación, más específica de un tema concreto.
Saludos!