Soy ScrumMaster para un equipo de desarrolladores y QA's con un Product Owner.
He intentado sin éxito durante el último año que el PO comprenda cuál es el papel del PO y parece que no lo entiende. Prueba mis sugerencias durante algunas semanas y luego vuelve a su antiguo modo de trabajar, especialmente cuando se acercan los plazos:
Qué ha dicho el equipo:
Mi pregunta es a dónde debo ir desde aquí. Estoy al final de mi atadura.
Estaba pensando que mi próximo paso debería ser hablar con su gerente y explicarle que creo que sería un muy buen gerente tradicional o gerente de proyecto, pero no veo ninguna cualidad útil para un Product Owner.
Hay algunas áreas en las que me gustaría profundizar más.
Primero: ¿Por qué el equipo tolera esto del PO? El PO, el SM y el Equipo deben tener aproximadamente la misma autoridad en el equipo Scrum, aunque en diferentes áreas. Supongo que hay otros factores en juego que otorgan más autoridad a la OP.
A menudo veo al Equipo Scrum como un juego de tira y afloja. Siempre que los roles sean similares, hay una tensión natural y todos nos divertimos. Si alguno de los roles es demasiado fuerte o demasiado débil, todos se derrumban.
Segundo: ¿Cuáles son las presiones sobre el PO? Todos tenemos expectativas sobre nosotros en el trabajo, pero si la empresa espera un alcance X para la fecha de entrega Y y responsabiliza al PO por eso, se encuentra en una situación que es imposible de cumplir para el OP y que no es saludable para todo el equipo Scrum. . En la mayoría de los equipos con los que trabajo, identificamos el propósito del equipo y las medidas del éxito. Tan pronto como vemos que la medida es "hacer el trabajo", sabemos que tenemos un problema. Las medidas deben centrarse en la rentabilidad, la reducción de costos, la satisfacción del usuario, etc. Luego, el trabajo de la OP es maximizarlas con cualquier trabajo que el equipo pueda realizar. Por lo general, en situaciones como la que usted describe, las solicitudes en la orden de compra por parte de otros miembros de la empresa son una expectativa equivocada.
Mi sospecha sería que tienes un problema de alineación y equilibrio y que el problema de las prácticas es secundario, especialmente porque dices que el PO prueba las sugerencias y luego vuelve a los viejos hábitos bajo presión.
Una respuesta aquí realmente depende de qué tan capacitado esté el equipo para utilizar Scrum.
Veo algunas cosas aquí que pueden valer la pena desempacar con su orden de compra:
Daily Scrum es para que el equipo de desarrollo vuelva a planificar su día en un esfuerzo por cumplir con un objetivo de sprint. Si el PO está causando problemas, no debe asistir, ya que esto distrae el propósito del Daily Scrum. Se debe hacer un esfuerzo para entrenar al PO sobre la utilidad del Daily Scrum.
la OP es responsable de maximizar/optimizar el valor del trabajo entregado, NO de la implementación de dicho trabajo. Los equipos de desarrollo están estructurados y autorizados por la organización para organizar y administrar su propio trabajo. Nuevamente, esto suena como una oportunidad de entrenamiento con su PO.
el PO debe estar disponible para proporcionar claridad en los elementos de trabajo. Si no pueden hacerlo, el Scrum Master debe asesorarlos sobre cómo mejorar en esto. Si las cosas no mejoran, se deben discutir oportunidades de capacitación externa.
En general, esto suena como una conversación que debe tenerse durante una retrospectiva de sprint, no 1 a 1 donde la transparencia es limitada. Entrenar al equipo para encarnar los Valores de Scrum durante este evento, específicamente la Apertura y el Valor, es más fácil decirlo que hacerlo, pero es esencial para desarraigar la causalidad y promover la transparencia tanto interna como externamente en el equipo. Las conversaciones difíciles hacen avanzar a un equipo.
Si un plan de solución surge de esta conversación abierta y no se logra ningún progreso, entonces tiene sentido escalar más allá del equipo. Eliminar los impedimentos para el progreso del equipo y ayudar a las partes interesadas de la organización a comprender y promulgar Scrum y el desarrollo empírico de productos son elementos clave para ser un Scrum Master. Tarea difícil, pero una parte esencial del rol.
Las respuestas anteriores son todas válidas. Solo me gustaría mencionar que la única "arma" que un equipo puede usar es un registro de desechos cuidadosamente rastreado y categorizado. Realice un seguimiento de la espera, el retrabajo, el servicio de la deuda, el sobrediseño, etc. e informe el tiempo (es decir, el dinero) perdido debido a un proceso insuficiente. Luego sugiera puntos de acción. Esa es la única forma que encontré que realmente funcionaba cuando los argumentos de sentido común no funcionaban. El trabajo es trabajo, por lo que el seguimiento del tiempo dedicado al trabajo no tiene sentido. Realice un seguimiento del tiempo dedicado a los bloqueadores. Consulte https://dzone.com/articles/90-sprints-for-capital-markets-part-4-of-4 (descargo de responsabilidad: soy el autor)
nvoigt
erik