En un nuevo equipo, un exgerente de desarrollo, que ha estado en ese puesto durante muchos años, se incorporó como propietario del producto del equipo. El equipo ha decidido hacer Scrum.
La mentalidad ágil del PO ciertamente está ahí, pero no puede adquirir el hábito de centrarse en el "qué" y desviarse del "cómo", y confiar en que el equipo de desarrollo se preocupe por el "cómo". Como dificultad adicional, la mitad de los miembros del equipo son desarrolladores muy jóvenes, y el PO está tratando de guiarlos (o jugar a ser papá) para brindarles el mejor apoyo.
Sin embargo, esa “orientación” se está desangrando por todo el equipo, al punto que todo está pasando por él. El Scrum Master lo mencionó y tuvo una discusión con el PO con respecto a este comportamiento, y los argumentos del PO fueron que, en primer lugar, los viejos hábitos tardan en morir y él está tratando de cambiar su postura, y en segundo lugar, que necesita retener al junior. un poco la mano de los desarrolladores, hasta que aprendan el producto y maduren un poco, de modo que estén en condiciones de asumir la propiedad y tomar sus propias decisiones.
En general, el PO tiene una buena formación técnica y es capaz de hacer sugerencias y dar orientación (lo hace todos los días en el scrum de la mañana), sin embargo, existe el riesgo de que este comportamiento sea la norma en el futuro, por lo tanto, cortar fuera de las alas de los desarrolladores.
¿Ve algo malo en este paradigma y, de ser así, qué le aconsejaría a este PO (o Scrum Master) que hiciera en tales ocasiones?
Creo que el momento es importante.
Durante el scrum diario, necesita concentrarse en el "qué".
Durante el resto del día, si siente que su experiencia (para los juniors) es valiosa, entonces no hay razón para que deje de dar consejos valiosos.
Pero no puede contaminar el día a día.
Una vez que tenga que "caminar" para dar su consejo individualmente, probablemente será más exigente en cuanto a quién interrumpe , y el "sangrado" también se detendrá.
Este es un problema con una solución simple que, lamentablemente, es difícil de implementar.
Es simple porque el PO solo necesita cambiar su estilo de tomar las manos o tomar decisiones por el equipo, o ser prescriptivo, a alguien que actúe más como un entrenador y se centre principalmente en hacer "las preguntas correctas" para que las personas descubran las cosas por ellos mismos. Todos también deben sentirse cómodos con el fracaso, porque las personas cometerán errores y debes aceptar que cometer errores a veces es la mejor manera de aprender algo.
Es difícil de implementar porque implica cambiar hábitos y estar atento a la situación en todo momento. Tienes que encontrarte haciendo el comportamiento actual y cambiar al nuevo comportamiento. Esto es difícil simplemente debido a la naturaleza humana. La OP debe ser consciente de lo que está haciendo y pensar en las implicaciones. Necesitan atraparse a sí mismos y decir "oye, estoy haciendo eso otra vez". El SM puede tener una discusión con el PO y acordar cómo manejar las cosas, luego el SM puede ayudar a detectar el comportamiento anterior y decir "oye, estás haciendo eso otra vez".
Usted notó muy bien que la forma actual de trabajar puede convertirse en la norma y crear una dependencia de una persona mientras que el resto del equipo solo los busca para todo, pero no puede dejarlo de golpe. Tendrá que hacer la transición a una nueva forma de trabajar. Así que plantee este tema en su próxima retrospectiva con todos (no solo algo entre PO y SM). Y decidan juntos cuál creen que es el mejor enfoque a largo plazo y cuáles son algunos de los primeros pasos para llevarlo allí (tal vez un programa en pareja, tal vez algunas personas muerdan el clímax e intenten hacer algo interactuando menos con el PO, tal vez algunos se necesitan sesiones de entrenamiento, etc.). Luego inspeccione y adapte.
Recomendaría reunir al equipo para discutir roles y responsabilidades.
Pueden enumerar los pros y los contras de tener a alguien en el rol de Propietario del producto que tenga un aporte técnico al trabajo y que también tenga autoridad sobre los miembros del equipo.
Idealmente, trate de pensar en una forma de rastrear si el comportamiento es problemático o beneficioso. ¿Quizás un chequeo frecuente en las retrospectivas?
Puede introducir la práctica (acuerdo) de que los desarrolladores junior vayan primero a sus colegas más experimentados en el equipo.
Haga esto de manera reactiva (los juniors tienen preguntas) o proactivamente (un senior se sienta con un junior de antemano/en momentos designados).
El hecho de que diga que esta persona "optó" por el rol de PO parece ser parte del problema. Por lo general, las OP no se eligen a sí mismas. Por lo general, se espera que un PO sea un gerente comercial, no un desarrollador o un profesional de administración de TI. Un PO es alguien que tiene la responsabilidad de algún área comercial o producto, puede tomar e implementar decisiones sobre la dirección del producto y será responsable ante las partes interesadas clave y la alta gerencia por el éxito comercial.
¿Tiene su OP ese tipo de responsabilidad? Si es así, no "optó" por el papel, se le asignó o fue seleccionado por acuerdo con un grupo más amplio de personas. Si su OP no es realmente alguien con ese tipo de rol y responsabilidad, entonces quizás esté tratando de actuar como representante de las partes interesadas reales. La mejor solución puede ser que el equipo se comprometa con las partes interesadas reales y haga que nominen su OP.
Yo estaba en una posición similar y siendo un evangelista Ágil, no vi ninguna salida en la situación dada. Entonces, enumeraré los problemas que debe resolver para permitir que su PO se detenga.
Te falta una pista técnica
Si bien el comportamiento del PO hace que sea más difícil asumir la propiedad técnica, él no está involucrado a tiempo completo en su solución técnica. Tiene que hablar con las partes interesadas, escribir historias de usuarios y hacer mucho "papeleo". Si con todo esto todavía tiene un conocimiento superior de manera que "todo está pasando por él" , le falta una contraparte técnica.
El líder técnico debe poder responder todas las preguntas de PO hasta el punto de que el asesoramiento técnico de PO se vuelve obsoleto. Además, el líder técnico debe tener una personalidad que adopte una postura en contra de la actitud de PO.
Habiendo dicho eso, no ignore el consejo de PO si es valioso. Esfuérzate por no necesitar más el consejo.
El Scrum Master no está haciendo su trabajo
Leí que su Scrum Master ya llamó a PO, pero ¿por qué no cambió nada?
Como primer paso, prohibiría a PO hablar por su cuenta en el stand-up diario. Él está allí para responder preguntas y permanecer en silencio de lo contrario. Si se le solicita explícitamente asesoramiento técnico, puede compartir toda su valiosa experiencia. Lo mismo se aplica al tiempo entre ceremonias. No se le permite molestar al equipo con consejos no solicitados.
A continuación, el Scrum Master debe alejar todas las partes de los criterios de aceptación de las historias de usuario que explican el "cómo" en lugar del "qué". En mi caso, agregué sugerencias como comentarios para darle al equipo un punto de partida, pero aclaré que se trata solo de pensamientos rápidos y sin requisitos. A veces mis ideas eran útiles, a veces eran inútiles. El Scrum Master debe realizar esta evaluación junto con el Product Owner, porque algo que parece un detalle de implementación puede ser en realidad un requisito difícil, por ejemplo, otro sistema depende de ello.
Brinda capacitación continua a tu Product Owner
Necesita entender cómo su comportamiento está frenando al equipo. Tal vez no entienda algunos flujos de trabajo. Scrum es muy vago y no te da un plan de acción claro. Por lo tanto, PO necesita a alguien que lo guíe y le enseñe las mejores prácticas. Óptimamente, ese sería el Scrum Master, pero si no están conectados a nivel personal, podría ser mejor buscar a alguien más en su organización. A medida que el equipo mejora con el tiempo, el propietario del producto también tiene que trabajar en mejoras continuas.
Bogdán