Estoy trabajando con un equipo que tenía un PO que microgestiona el equipo, tiene un enfoque muy direccional para trabajar con el equipo. A menudo les pregunto 'cuándo terminan las cosas', etc. Obviamente, lo estoy entrenando sobre cómo comportarse como un PO y que este enfoque perjudicará al equipo a largo plazo. Entonces, esto es parte de mi rol como Scrum Master: eliminar este impedimento para el éxito de los equipos.
Sin embargo, tengo la oportunidad de hacer una retro sin el PO (están fuera) y me preguntaba si alguien tiene algún enfoque de formato retro que permita que esta disfunción salga a la luz en el equipo. Entonces, ¿una forma de lograr que el equipo exprese cualquier desafío o inquietud (si corresponde) que tengan con el enfoque de la OP? Tal vez no tengan ningún problema con su enfoque, pero sería bueno sacar a la superficie su opinión al respecto.
Esperar a que el propietario del producto esté fuera antes de tener la conversación no es un buen enfoque de Scrum.
Es mejor tener una discusión abierta en equipo y resolver el problema con todos los presentes.
Si el equipo no habla abiertamente frente al propietario del producto, ese es el problema que debe resolverse, no el comportamiento del propietario del producto.
No sé en qué tipo de semillero político puede estar su organización, pero evitaría tratar de descubrir la opinión de los equipos sobre un miembro individual del equipo en un grupo abierto. Creo que pedir tal cosa pondría en peligro la confianza general del equipo. Después de todo, ¿qué diría el equipo sobre mí cuando esté ausente en un retro?
Si tiene la hipótesis de que el comportamiento de este PO está afectando negativamente el rendimiento, investigue esto a puertas cerradas donde se puede garantizar el anonimato. Y asegúrese de NO hacer preguntas de manera directa para no confirmar inadvertidamente su hipótesis de manera sesgada. Así que evite hacer esto completamente retro y realice eventos únicos en privado.
Barnaby Golden , Thomas Owens y David Espina han dado buenas respuestas, pero quiero abordar su pregunta central de una manera diferente. Usted pregunta:
Me preguntaba si alguien tiene algún enfoque de formato retro que permita que esta disfunción salga a la luz en el equipo.
Como Scrum Master, es su responsabilidad facilitar discusiones respetuosas, valientes y, a veces, difíciles dentro de la retrospectiva. Los acuerdos de trabajo en equipo, las funciones y responsabilidades, y las comunicaciones del equipo son temas que están dentro del mandato de una retrospectiva típica, pero es su trabajo asegurarse de que se haga de manera constructiva .
Me doy cuenta de que está buscando un formato simple para abordar el tema y, aunque proporciono uno a continuación, siento que ese aspecto de su pregunta es en realidad parte del problema. El tenor general de su publicación original ya implica un juicio fuerte sobre la situación y los participantes, y eso no es propicio para realizar una retrospectiva saludable porque establece una dinámica de Equipo contra PO que probablemente se convierta en una actitud defensiva y señalando con el dedo. .
En cambio, si las personas le plantean el problema a usted en su rol de Scrum Master o miembro del equipo, entonces, como miembro del equipo, tiene todo el derecho de señalar los problemas que le han llamado la atención dentro de la retrospectiva. Luego, asegúrese de facilitar la discusión para mantenerla encaminada y constructiva, y mantenga al equipo enfocado en salir con un plan concreto o un elemento de acción.
El objetivo del Scrum Master no es culpar; es para facilitar la mejora continua del proceso. Con eso en mente, un Scrum Master experimentado podría usar el siguiente formato para descubrir, abordar y resolver un problema de proceso basado en roles o comunicación dentro de una Retrospectiva de Sprint.
Mini guión de Scrum Master
En este Sprint, varias personas han planteado inquietudes sobre los informes de estado al Propietario del producto, lo que reduce la productividad del Equipo de desarrollo según lo medido por... Para abordar estas inquietudes, me gustaría que todos examináramos:
- Ya sea que sea realmente un problema para el equipo como un todo o para miembros individuales.
- Si es así, ¿qué tiene de malo nuestro proceso, comunicaciones o transparencia que está desencadenando lo que les parece una excesiva presión de estatus?
- Ahora que hemos identificado el problema, ¿cuáles son nuestros elementos de acción como equipo?
También puede usar técnicas como 5 porqués para identificar una causa raíz y asegurarse de intervenir con firmeza para evitar ad hominems o cualquier intento de atribuir malas intenciones en lugar de descubrir una razón. Recuerde que el objetivo es identificar los problemas del proceso y luego identificar las soluciones orientadas al proceso.
Como otro ejemplo práctico, parece probable que, en este caso, los 5 porqués identifiquen una falta de confianza del propietario del producto en la capacidad del equipo de desarrollo para alcanzar el objetivo del Sprint, o descubran un proceso de desarrollo menos que transparente donde el Sprint Backlog, El tablero Kanban u otros radiadores de información no son confiables o no se utilizan de la mejor manera. Cualquiera que sea el problema, piense en él como un problema de proceso y encuentre una solución orientada al proceso como equipo que todo el equipo pueda respaldar.
Adaptar los acuerdos y prácticas de trabajo del equipo para resolver los problemas del proceso está en el corazón de Scrum, Kanban y el Manifiesto Ágil. Los roles, ceremonias y procesos que forman Scrum están destinados a facilitar la negociación efectiva de acuerdos de trabajo sostenibles, y no a culpabilizar. Siempre asegúrese de que todo el equipo (y especialmente el Scrum Master) mantenga un enfoque constante en los problemas del proceso, ¡no en encontrar fallas individuales!
Tomas Owens
aventura2099
Todd A. Jacobs