Soy Scrum Master para un equipo pequeño (8 desarrolladores). He tenido problemas para lograr el compromiso de muchos de los miembros del equipo, especialmente los miembros del equipo junior. Mi jefe se perdió dos retrospectivas porque tenía otras reuniones y comencé a progresar. Hubo más compromiso, y un miembro junior del equipo que había estado en silencio en Sprint Retrospectives anteriores habló extensamente sobre un elemento de acción que quería agregar.
Luego, el último Sprint, mi jefe asistió a la retrospectiva y los desarrolladores junior cerraron. Siempre pedía la opinión de todos, pero cada vez que abría la boca eliminaba cualquier posibilidad de que 7 de los 8 miembros del equipo dijeran algo, y el miembro restante del equipo siempre estaba de acuerdo con él. Obtuve buenos elementos de acción de las retrospectivas y todos los elementos han tenido propietarios voluntarios. Pero en este retro, la mayoría de los elementos de acción fueron sugeridos por mi jefe y no había propietarios para ninguno de los elementos.
El problema es que todavía tiene un pie en el aspecto técnico y aún completa algunos de los elementos de Sprint. Eso significa que no es exactamente un pollo; es por lo menos medio cerdo . Podría pedirle que permanezca en silencio, pero no estoy seguro de que eso funcione. Hay un efecto escalofriante cuando él está aquí. ¿Estoy exagerando? ¿Debería tratar de aumentar la confianza del equipo o debería excluir a mi jefe de la retrospectiva? No estoy seguro de cómo se lo tomaría.
Parece que tienes miembros del equipo de culturas de alta distancia al poder. Es posible que las personas no hablen cuando el jefe está en la sala porque sus valores requieren que escuchen y sigan, no que aconsejen ni lideren. Incluso puede notar que sucede entre los miembros del equipo junior y senior o entre usted y los miembros del equipo. Lea más sobre distancia de poder aquí: https://en.wikipedia.org/wiki/Power_distance
Las culturas con una gran distancia de poder a menudo tienen un fuerte colectivismo, lo que significa que las personas quieren ser parte de un todo en lugar de destacarse como individuos. Esto es contrario a otras culturas que tienen un fuerte individualismo y valores bajos de distancia del poder.
Una solución a corto plazo puede ser realizar dos retrospectivas en las que primero recopile comentarios del equipo, luego anonimice y consolide los comentarios antes de presentar las recomendaciones del "equipo" al jefe y discutir sus ideas con el equipo. Esto protege a las personas de sentirse "molestados" mientras permite que las personas individualistas obtengan un poco de protagonismo.
Para una solución a más largo plazo, lea cómo la industria de las aerolíneas capacita a sus equipos para reducir los problemas relacionados con la distancia del poder. Lo ideal es enseñar al equipo a tener baja distancia de poder (libre intercambio de información entre el equipo) y alto colectivismo (reconocimiento y aceptación de la interdependencia del equipo). https://en.wikipedia.org/wiki/Crew_resource_management
PD. Consulte la respuesta de Todd A. Jacobs para obtener un buen análisis de las preguntas relacionadas con el proceso Scrum con las que tendrá que lidiar además de los temas culturales que mencioné anteriormente.
Hay un efecto escalofriante cuando él está aquí. ¿Estoy exagerando? ¿Debería tratar de aumentar la confianza del equipo? ¿O debo prohibir a mi jefe de la retrospectiva?
En mi experiencia, este es un caso clásico de perder el bosque por los árboles y confundir los problemas del proceso con problemas interpersonales. Vamos a enumerar algunos de los problemas que sustentan su pregunta.
En resumen, definitivamente tiene un problema de comunicación dentro de su proceso, pero todo parece reducirse a una falta de confianza y honestidad. Fundamentalmente, si no puede ser honesto dentro del equipo o acerca de informar los impedimentos del proceso, entonces tiene una falla en la implementación de Scrum. Scrum simplemente no puede funcionar de manera efectiva en una cultura organizacional basada en el miedo, independientemente de si esa cultura proviene de los miembros del equipo o del "tono en la parte superior".
No hay una bala de plata. El miedo, la incertidumbre y la duda arruinarán cualquier marco de gestión de proyectos. Este no es un problema exclusivo de Scrum. Debe abordar la fuente de los temores del equipo de frente, aceptar las cosas como son o seguir adelante de la manera más profesional posible. Para abordar el problema de frente, usted y el resto del equipo (incluido su jefe) deben concentrarse en el proceso Scrum en lugar de en los conflictos interpersonales, ya sean reales o percibidos.
Para poner en marcha la mejora del proceso, debe analizarse a sí mismo y su papel como Scrum Master. Si percibe un problema, ¿por qué no se siente seguro de recopilar o facilitar comentarios honestos del equipo? Más importante aún, si usted es el Scrum Master (y, por lo tanto, la persona responsable de arbitrar el proceso Scrum), ¿por qué no se siente seguro al tener una conversación honesta con el "jefe" (cualquiera que sea su rol real en Scrum) sobre su impacto en el proceso?
Si puede responder esas preguntas honestamente, probablemente encontrará su propia respuesta. Según la experiencia pasada con implementaciones disfuncionales de Scrum, el primer paso casi siempre es mejorar las comunicaciones. Si no puede o no quiere hacerlo usted mismo, entonces no es realista esperar que otros miembros del equipo (especialmente los introvertidos, "junior" o inexpertos) lo hagan tampoco.
Fundamentalmente, si todo el equipo (incluyéndote a ti) se siente inseguro o inseguro acerca de ser honesto con los demás, o de comunicar los impedimentos del proceso con el liderazgo de tu organización, entonces realmente no importa si tu jefe tiene la culpa o no. El problema subyacente es que el equipo carece colectivamente de cohesión, confianza, conciencia situacional y comunicación abierta. Si el equipo no puede arreglar esas cosas colectivamente, tampoco puede arreglar la implementación de Scrum.
Al final del día, es posible que no puedas cambiar la dinámica social del equipo. Si ese es el caso, es probable que su proyecto fracase. Si eso sucede, habrá mucha culpa para repartir. Por otro lado, si decide tener una conversación abierta y honesta como equipo y su jefe no está dispuesto a resolver problemas junto con los demás, entonces se queda con las dos mitades de un proceso roto.
La respuesta a esta pregunta depende mucho de las personas del equipo y del jefe.
Normalmente, un equipo Scrum no debe contener personas con roles especiales, especialmente un jefe . El equilibrio de poder se estropea y puedes despedirte de la autoorganización porque un jefe tenderá a decidir sobre los asuntos y querrá tener la última palabra en varias situaciones y decidir sobre las cosas. Así no es como debería funcionar un equipo Scrum. En un equipo Scrum todos son compañeros .
Si este jefe fuera solo eso, un jefe, la respuesta sería simple: pedirle al jefe que no participe en retrospectivas. El problema es que este jefe también es miembro del equipo y, como mencionaste, todavía tiene un pie en el aspecto técnico y aún completa algunos de los elementos del sprint. No puedes echarlo de las retrospectivas porque en realidad es un miembro del equipo y debería tener una voz. El problema es que su voz es más fuerte o más importante que la del resto de los miembros del equipo. La forma de resolver este problema depende de la dinámica del equipo.
Aparte, hay un problema adicional con el hecho de que el jefe sea un miembro del equipo: son solo medio tiempo, al menos la mitad del tiempo, como mencionas. Si el jefe necesita ocuparse de los "asuntos del jefe" mientras el equipo depende de él para los artículos de Sprint... tienes un problema. Esto genera problemas con la planificación de los sprints, con el trabajo en sí mismo, o incluso puede causar conflictos si el jefe necesita tomar decisiones que van en contra de las del equipo o las recomendadas por la práctica de Scrum. Y pueden, ya que son el jefe.
Antes de empezar a hacer algo, le sugiero que discuta esto con todos los miembros del equipo, incluido el jefe . Dependiendo de la dinámica del equipo, puede tener estas discusiones de forma transparente con todos o en privado. Todo depende de la gente. Trabajas con ellos, los conoces mejor y debes decidir cómo será con todos. Solo para poner un pie en la puerta, sugeriría que en su próxima retrospectiva, usted como Scrum Master, pida a todos que completen un formulario de evaluación de Scrum solo para evaluar sus prácticas de Scrum. Como un chequeo de salud, Por ejemplo. Haga que cada miembro del equipo ponga su nombre en el formulario y se lo envíe en privado. Luego puede decir que desea recopilar más comentarios de las personas y ahora tiene una excusa para tener reuniones individuales con todos y ver cómo se sienten todos acerca de la situación. Ahora puede alentar a algunas personas a tener más confianza, puede pedirles a algunas personas que participen más y puede decirle a su jefe que sea más consciente de cómo se comportan con los demás.
Agregue todos los resultados y conclusiones y decida en base a eso, juntos como equipo, qué hacer . Usted, como Scrum Master, en realidad no tiene el poder de excluir al jefe de las retrospectivas, pero el equipo en su conjunto puede decidir rechazarlo . Con suerte, su jefe tiene la mente lo suficientemente abierta como para aceptar la decisión del equipo y comprender sus razones.
Recopile la mayor cantidad de información posible sobre cómo se sienten todos y forme una imagen más completa antes de decidir nada, ya que las cosas siempre pueden salir mal si su jefe decide usar su papel diferente en el equipo para imponer su punto de vista sobre las cosas.
Podría sugerir que hablar de esto en el retro podría estar en orden.
Las retrospectivas y los elementos de acción que surgen de ellas a menudo se centran en el proceso y en cómo mejorarlo. Sin embargo, puede ser fácil olvidar que los retros también son parte del proceso, y vale la pena modificarlos si no funcionan como deberían.
Ahora, puede que sea una conversación delicada; Estoy seguro de que a su jefe no le encantará que le digan que el equipo tiene mejores retros sin él, y que los miembros del equipo no querrán que se les preste atención ni a la diferencia en su comportamiento cuando el jefe no está. Sin embargo, si desea tener retrospectivas abiertas y honestas, abordar este tema podría ser un buen primer paso. Trátelo como cualquier otro elemento de acción potencial e intente intercambiar ideas con el equipo sobre cómo solucionarlo.
Si la idea de hablar sobre el tema durante una retro (mientras tu jefe está allí) es completamente impensable, bueno... eso también contribuye en gran medida a responder tu pregunta.
Si la presencia de algún miembro del equipo está reduciendo el rendimiento y la productividad de alguna actividad, elimine el problema.
Para ampliar un poco mi respuesta: un efecto escalofriante provocado por un "superior" en la habitación no es raro. Muchos factores juegan un papel en eso, incluido el grado de brecha de "rango" entre el jefe y el equipo, los problemas culturales en la empresa, la falta de talento del jefe, las interacciones previas, incluidas las consecuencias por plantear inquietudes, y así sucesivamente. Como líder de proyecto, usted es responsable del desempeño y eso significa necesariamente que debe administrar hacia abajo, hacia arriba y hacia los lados y eliminar las barreras para el equipo. Eso también significa que debe tener las conversaciones más incómodas con cualquier parte interesada, adecuadamente sazonadas con el nivel apropiado de sal política, cuando haya identificado la causa raíz de un problema de desempeño.
Como no conocemos a su jefe, no podemos predecir cómo sería esta conversación, pero es una conversación que debe tener. En los proyectos, mi opinión es que no tenemos tiempo para "crecer" a las personas. Quita el engranaje infractor, lo reemplaza por uno nuevo y vuelve a encender la máquina. En una configuración más de operaciones, es posible que se tome más tiempo para trabajar con el problema para ver si puede mover la aguja. Esta es su elección para hacer. Correcto o incorrecto, mi enfoque sería decirle al jefe (s) que está interfiriendo con el proceso y solicitar una salida inmediata de ese proceso. De lo contrario, podría ver si el jefe abordaría este problema y solicitaría activamente comentarios de una manera diferente a la anterior.
Como Scrum Master, la única vez que buscaría prohibir a alguien de una retrospectiva es si el equipo me lo pide.
Mi recomendación sería entrenar primero al equipo y al jefe sobre la importancia de hacer de la retrospectiva un espacio seguro. El equipo (o el jefe) puede entonces actuar por su propia voluntad.
Si eso no ayuda, convertiría el comportamiento del equipo cuando el jefe está presente en un tema retrospectivo, remitiéndome al entrenamiento.
Bogdán
Bogdán
ciara dunn
benlinders
nvoigt
steve bennett
Bogdán
steve bennett
Todd A. Jacobs
Thorbjorn Ravn Andersen