¿Cómo manejar una situación en la que un miembro del equipo no quiere participar en las retrospectivas?

El equipo trabaja en conjunto durante un par de meses. Están en algún lugar entre la normalización y la fase de ejecución. Todos los miembros del equipo están entusiasmados con su trabajo y el producto en el que trabajan. Uno de los miembros del equipo dice que no se beneficia de las retrospectivas. Ha estado en muchos de ellos (entre 30 y 50) en diferentes equipos y llegó a la conclusión de que prefiere hacer el trabajo relacionado con el desarrollador.

Al mismo tiempo, colabora: ayuda a los demás, respeta las normas del equipo, participa activamente en otras reuniones, etc. También es un buen ingeniero. Al equipo no le gustaría perderlo; en otras palabras, una solución con despedirlo del equipo no es aceptable.

¿Cómo se siente el resto del equipo acerca de la utilidad de las retrospectivas? Si los encuentran útiles, y valoran su aporte, y él quiere ayudar a los demás, entonces no se trata de su beneficio, sino del de ellos. :) Un enfoque que he usado con miembros del equipo que no ven valor en algo que el equipo valora es desafiarlos a crear su propio formato o proceso que creen que funcionaría para todos los involucrados.
¿Por qué dice que no se beneficia de las retrospectivas? Parece no tener ningún problema con el formato de las otras ceremonias, entonces, ¿qué hace que las retrospectivas sean problemáticas? Además, estoy de acuerdo con el comentario de @JeffLindsey: ¿qué piensa el otro equipo sobre las retrospectivas? ¿Sienten también que no se benefician? Tal vez haya algo en su proceso retrospectivo que se pueda mejorar.
¿Es porque piensa que los elementos de acción de una retrospectiva nunca se toman en cuenta (especialmente aquellos en los que el cambio está fuera del alcance del equipo)? He visto esto y, francamente, no pude resolverlo por completo.
Suponga que el proceso retrospectivo no tiene fallas. 5 miembros del equipo se benefician, solo 1 no.
"Suponga que el proceso retrospectivo no tiene fallas". La idea general de Agile es que todo se puede mejorar, eso no significa necesariamente que tenga fallas.
@SpoonerNZ Cierto. Una mejora en esta situación podría ser que este miembro del equipo no participe en la reunión retrospectiva.
Si realmente cree que hay una solución, publíquela como respuesta a su propia pregunta. No lo veo como una buena solución, ya que entonces ese miembro del equipo no sabrá sobre los cambios que el equipo hace en su forma de trabajar o, lo que es más importante, no entenderá el razonamiento detrás de ellos. También sienta un precedente para "Nuestras reuniones no son importantes, solo di que no quieres venir y no nos molestaremos en tenerlas". Sospecho que plantear eso como una solución será votado negativamente en general.
@SpoonerNZ No pensé que fuera una buena solución. Es solo una idea. Mi punto era más como: una mejora no siempre tiene que significar seguir pautas generales, que es "todo el equipo debe participar" en este caso. También creo que hay una mejora a corto y largo plazo. A corto plazo, esta configuración solo libera algo de tensión y, a largo plazo, un miembro del equipo podría cambiar de opinión porque en realidad extrañaría las retros :-)

Respuestas (5)

La práctica habitual es pedirles que se unan a la reunión, no tienen que hacer nada más que escuchar las discusiones de vez en cuando, incluso pueden sentarse en la esquina. Si quisieran participar en una discusión, ese acuerdo cambia y tienen que participar hasta el final de la sesión. Eso es algo en lo que tienes que estar de acuerdo cara a cara.

Hablé con el equipo y el desarrollador antes mencionado y llegamos a una solución similar a la que propusieron. Por el momento está presente en las retrospectivas, pero está sentado en la esquina y trabajando en sus cosas. Cada vez que escucha algo interesante, interviene. Además, está de acuerdo con cualquier cambio en el proceso que lo afecte, pero no habló.

Parece que sería un buen momento para tener una 'Retrospectiva de retrospectivas'. Comience con un recordatorio del propósito de tener una retrospectiva y lo que el equipo está tratando de obtener de ella. Revise cómo el equipo ha tenido retrospectivas en el pasado, qué salió bien, qué se puede mejorar, etc. Puede ser el formato de las reuniones el problema, y ​​otros pueden tener sentimientos similares si se les da una mejor oportunidad de expresarlos.

La única vez que he visto una situación similar es donde las retrospectivas planteaban siempre los mismos problemas organizativos, y como equipo no pudimos mejorar la situación. Si este es el caso, lamentablemente no puedo ayudar, ¡dejé la organización!

Este no es el caso. Un miembro del equipo mencionado en la pregunta no está diciendo que los resultados retrospectivos sean malos. Tampoco trata de socavar el proceso. Todo lo que dice es que le gustaría dedicar su tiempo al desarrollo, no a la retrospectiva, porque, en su opinión, ofrece más valor. Además, como escribí en la pregunta, es amigable, tiene buenas habilidades (no es una estrella), está dispuesto a ayudar, etc.
Pero estoy de acuerdo en que este enfoque sería un buen punto de partida para arreglar un bucle de inspección y adaptación.

No puedes hacer cambios sin aceptar el cambio

Se ha encerrado a sí mismo. El solo hecho de que esté haciendo esta pregunta indica que existe fricción entre este desarrollador y el proceso elegido por el equipo, aunque en realidad no ha definido la naturaleza del problema que esto está creando.

También busca resolver esta fricción sin requerir que el desarrollador se adapte a un proceso orientado al equipo y, por lo tanto, está dispuesto a romper el proceso en lugar de reconocer que este miembro del equipo puede no encajar en él. Simplemente no puede mantener el statu quo y resolver esta fricción simultáneamente.

Básicamente, ha hecho que el marco Scrum sea opcional para este desarrollador, pero está tratando de tener su pastel y comérselo también. Si va a permitir que cada individuo en el equipo escoja y elija las partes del marco que le gustan y está dispuesto a seguir, entonces no solo está invitando a Scrum-Buts, sino que esencialmente está abandonando el rigor (y muy probablemente los beneficios) de su implementación de Scrum.

Está bien decir que un marco determinado no funciona para su equipo y su organización; ciertamente hay otros marcos para elegir. Sin embargo, debe tener algún marco de gestión de proyectos con controles aplicados rigurosamente si no quiere invitar a la anarquía.

Las prima donnas no son ágiles

Tiene a alguien que no encaja en su proceso orientado al equipo. Eso te deja con las siguientes opciones:

  1. Vuelva a evaluar el formato y la eficacia de sus retrospectivas, y luego modifique la ceremonia hasta que brinde valor a todos.
  2. Brindar educación, incentivos y consecuencias para garantizar que todos los miembros del equipo participen de manera efectiva en esta ceremonia obligatoria de Scrum.
  3. Abandonar el proceso Scrum si no planea seguirlo de todos modos.

Scrum se trata de trabajo en equipo. Los lobos solitarios, incluso si son estrellas de rock técnicas, son tóxicos para los procesos ágiles.

Las retrospectivas son requeridas por Scrum Framework

Uno de los miembros del equipo dice que no se beneficia de las retrospectivas.

Este miembro del equipo no entiende el punto. Si se beneficia o no de la retrospectiva es irrelevante; el problema real es si el equipo se beneficia o no de las retrospectivas.

Además, la Retrospectiva del Sprint es una ceremonia de Scrum formalmente definida que es esencial para el proceso de inspección y adaptación. Eso significa que debe realizar retrospectivas si se adhiere al marco formal de Scrum. No mantener Sprint Retrospectives efectivos reduce la efectividad del marco y va en contra de los principios básicos de Agile.

Finalmente, debe considerar cuidadosamente si está dispuesto a que su proceso sea secuestrado por alguien que no está dispuesto a ser un miembro del equipo en pleno funcionamiento dentro de un marco ágil orientado al equipo como Scrum. Si permite que este miembro del equipo dicte el proceso al resto del equipo, o que seleccione y elija unilateralmente los elementos del marco Scrum que desea seguir, entonces esto no es ni ágil ni Scrum.

Como Scrum Master, si renuncia a su responsabilidad de arbitrar el proceso Scrum para aplacar a una persona, no ha cumplido con su trabajo. En cambio, debe asegurarse de que las retrospectivas proporcionen valor al equipo y que el equipo funcione como un equipo en todo momento.

Sin ofender, pero esto es un montón de consejos absolutos y tenemos muy poco contexto. ¡Ojalá respondiera con más información! :)
Una respuesta completa :-) Entiendo que la Guía Scrum dice que todo el equipo debe participar. Intencionalmente no etiqueté mi pregunta con Scrum ni mencioné Scrum en cuestión.

¿Qué formato estás usando para tus retrospectivas? En mi experiencia, cambiar el formato puede mejorar las tasas de participación. Si solo está utilizando una 'rueda de cambio' con la expectativa de que los miembros del equipo hablen abiertamente frente a sus compañeros, intente cambiarlo un poco. Cree histogramas para las áreas de enfoque y solicite a los miembros del equipo que coloquen notas adhesivas sobre qué tan bien ven (personalmente) el desempeño en esa área de enfoque. Alternativamente, pruebe el enfoque "Érase una vez una retrospectiva" como se describe en StickyMinds.com. Sobre todo, asegúrese de documentar todos los cambios propuestos y asigne elementos de acción a los miembros del equipo, luego haga un seguimiento antes o al comienzo de la próxima retrospectiva.

Por lo general, elijo Start Stop Continue, pero introduzco otros formatos de vez en cuando (digamos cada 3 retro). Esta es una buena solución, gracias :-)

[Modificado] Como se menciona a continuación, leí mal las reacciones asumiendo que no haber realizado las acciones fue la principal razón para no asistir. Por lo tanto, la respuesta a continuación puede estar fuera de tema, pero la dejé aquí porque creo que aún podría ser útil para los lectores de este hilo.

Creo que el miembro del equipo tiene razón si siente que las acciones que surgen de una retrospectiva no se toman en cuenta; eso es un problema serio

¿Se ha investigado esto, se conocen las causas fundamentales? Eso sería lo primero que haría.

Si las acciones no se realizan lo suficiente, debe detener la línea y abordar eso. Las razones que veo para no haber hecho las acciones son:

Las acciones son demasiado vagas, la gente no sabe qué hacer. Las acciones no son visibles, las personas tienden a olvidarlas mientras realizan sus actividades diarias. No está claro por qué se debe realizar la acción, faltando el problema que se debe resolver. No hay suficiente cultura para la mejora continua.

Todo esto se puede resolver, pero necesita saber por qué no hay suficiente seguimiento para abordarlo.

El autor de la pregunta no afirma que este miembro del equipo sienta que las acciones que surgen de las retrospectivas no se toman en cuenta.
Mi error, vi esto mencionado en una discusión anterior y lo interpreté mal como si viniera de Bartek Kobyłecki, quien planteó la pregunta. ¡Gracias por señalar esto, jordix!
¿Cómo manejar una situación en la que un miembro del equipo no quiere participar en las retrospectivas?
RespuestasAquíPolítica de privacidad1y, 2v