El equipo es un desastre desorganizado que se parece vagamente a Scrum, el gerente está ausente sin permiso, los desacuerdos del equipo sobre cómo implementar las pruebas, ¿qué debo hacer? [cerrado]

Somos una empresa de TI y nuestro equipo trabaja para un tipo de productos en la empresa. Mi gerente actualmente tiene 9 personas en el sitio y alrededor de 15 a 20 personas trabajando en el exterior bajo su mando. Tiene demasiados problemas que manejar, por lo que dividió su equipo en 4 subequipos. Soy ingeniero de software I y también tenemos SE II y SE III en el equipo. Comenzamos a trabajar en un nuevo producto en octubre pasado y tenemos un pequeño equipo de scrum de 8 miembros (4 en el extranjero y 4 en el sitio). Soy un desarrollador en el sitio. Dado que trabajé activamente en las etapas iniciales del producto y tengo más conocimiento sobre las últimas tecnologías que otros miembros sénior del equipo, con el tiempo, sucedió que estoy ejecutando el scrum y haciendo asignaciones de historias, etc. En los últimos meses, mi gerente se deslindó de otros temas y se concentró menos en este equipo y yo dirijo el equipo Scrum en términos de trabajo. Dejé de escribir código hace un mes porque me siento abrumado, pero trabajo en problemas de bloqueo, manejo de problemas dependientes entre equipos, etc. Escribo código para tales problemas.

Hasta ahora, tenemos a todo el equipo programando y probando sus propias historias. Descubrimos que estamos corriendo al final del sprint y la gente no está gastando tanto tiempo requerido y planeado para las pruebas. Todo el mundo está de acuerdo con eso. Llamé a una reunión hace 10 días y pedí las opiniones de todos. Hubo una variedad de ideas sobre por qué la calidad se ve obstaculizada: no dedicar suficiente tiempo a la planificación. Los requisitos no están claros al comienzo del sprint. Por lo tanto, los cambios de alcance durante el sprint no permiten suficiente tiempo para probar. Sugerencias para superarlos donde el 50% trabajaba en Pruebas y el 50% en Codificación en rotación para cada sprint (originalmente era el plan de mi Gerente y lo leí en la reunión. Él no estaba en la reunión). Algunas personas sugirieron que hicieran pruebas y codificaciones, pero que probaran las historias de los demás. A algunos les preocupa que no funcione, ya que mientras la persona esté codificando, no tendrá tiempo para realizar pruebas al final, independientemente de si es su historia o la de los demás. Había otras ideas también, pero tuvimos esta discusión.

Terminamos un sprint ayer y planeamos el próximo hoy. Tuve una discusión con los miembros en el sitio ayer y todos estaban de acuerdo con probar el 50% de las pruebas y la codificación. Juntos decidimos sobre esa idea en el sitio y la pusimos en la reunión de planificación de sprint donde también está presente la gente del extranjero. Mi gerente sabía que íbamos a hacer esto. Reconozco aquí que si voy a escribir código, odiaría probar todo el sprint. Pero fue idea del gerente y estaba bien intentarlo.

Durante la planificación, a uno de los miembros del equipo no le gusta la idea (puede ser porque estará en control de calidad en este sprint) y discutió un poco en la reunión. Dijo que toda la discusión en el extranjero sobre esto antes de la planificación y pensó que sería bueno si todos hicieran codificación y pruebas porque la productividad será menor, algunos solo tienen que esperar a que se entregue el código (pero, tienen tareas para arreglar algunos errores y crear casos de prueba durante ese tiempo). Mi jefe era consciente de que la productividad será menor. También hablé de eso en la reunión (pero no dije que fuera del Gerente). Para ponerlo en marcha, concluí diciendo que los escucho a todos, pero quiero probar esto en un sprint y ver cómo va y podemos probar otras ideas para el próximo sprint.

Supongo que este miembro del equipo está enojado conmigo ahora. Simplemente me sentí así, no hubo signos explícitos, sino basados ​​en la forma en que habló. ¿Cómo manejar tales situaciones? No tengo ningún rencor personal o resentimientos y quiero ser amable con todos. Soy desarrollador y estuve trabajando junto a ellos hasta ahora. Entiendo que podemos dirigir un equipo con éxito cuando todos están contentos y de acuerdo. Esta persona está en el extranjero y no interactuamos cara a cara. Trabajan en otro país en diferente zona horaria.

¿Qué indicación tiene de que el miembro del equipo está enojado con usted? ¿Ha logrado que la gerencia acepte el uso del nuevo método para el próximo sprint?
Algunas cosas que dices sobre tu equipo Scrum me parecen señales de alerta. Dices que los manejas. Haces asignaciones de trabajo. Decidiste que algo se hace sin el apoyo de tu equipo. ¿Estás seguro de que estás haciendo Scrum? Porque nada de esto debería pasar en Scrum.
No tiene una función/título de gestión en la organización, pero ¿está dirigiendo a la mitad de los desarrolladores para que no realicen ningún trabajo de desarrollo y, en cambio, los obliga a realizar trabajo de control de calidad? Creo que yo también estaría molesto.
Escribí toda la situación elaborada si algo cambia de sus opiniones.
@JoeStrazzere para este proyecto no tenemos Garantía de calidad separada. Sin embargo, otros productos tienen equipos de control de calidad explícitos. Los desarrolladores escriben integración y casos de prueba de extremo a extremo en este proyecto. Durante la planificación, los desarrolladores estiman para las pruebas. Pero dedican tanto tiempo a la codificación que las pruebas se vuelven pequeñas al final.
"¿Cómo manejar a un miembro del equipo que no está de acuerdo?" podría ser el título más fuera de tema que he visto. Estoy luchando contra el impulso de cambiar el título de esto "El equipo es un desastre desorganizado que se parece vagamente a Scrum, el gerente está ausente sin permiso, los desacuerdos del equipo sobre cómo implementar las pruebas, ¿qué debo hacer?"
Lo obvio parece ser si estás feliz de seguir siendo gerente de facto o scrum master (¡cualquiera de los dos, pero no ambos!), hacer que el jefe te ascienda (?) Oficialmente e insista en que te atrapen a ti (y al equipo) un poco de capacitación y ajuste su metodología, y designe/contrate al otro puesto de maestro/gerente de scrum junto a usted. Encuéntrales algunas recomendaciones de entrenamiento asequibles. Si no está feliz de serlo, renuncie a desarrollador y haga que el jefe nombre/contrate a otra persona. Entonces, ¿hacia dónde quieres ir?

Respuestas (4)

Sin embargo, concluí diciendo que los escucho a todos, pero que quiero probar esto en un sprint y ver cómo va.

Básicamente, a pesar de sus objeciones, les diste órdenes. No estoy seguro de lo que cree que está haciendo o cuál cree que es su rol allí (nunca nos lo dijo), pero este no es un equipo ágil o Scrum. No hay un "gerente" de un equipo Scrum que les diga qué hacer. Se llama "Inspeccionar y adaptar", no "Mi jefe inspeccionó y me dijo que me adaptara y ahora tengo que hacer lo que dice".

Tienes dos opciones:

  • Puede obtener la aceptación de su equipo , lo que significa que al menos la mayoría debería estar de su lado en este tema. Y no por no quejarse, sino por expresar activamente su apoyo a este cambio. Entonces el equipo cambió la forma en que se va a organizar el equipo y nadie puede estar enojado contigo . No tuviste nada que ver con eso.

  • También podría dejar en claro lo que espera de su equipo. ¿Quizás menos errores u otra medida de calidad cuantificable? Exprese sus expectativas y permítales llegar a conclusiones sobre cómo llegar allí.

De hecho, tiene una tercera opción: deje de fingir que es Scrum y regrese al comando y control. Porque ese parece ser tu comportamiento actual. Claro que está cubierto de azúcar y los escuchas, pero si no valoras su opinión, es mejor que dejes de fingir.

Escribí toda la situación elaborada si algo cambia de sus opiniones.
Su equipo debe estar formado por miembros iguales. No pareces ser igual a nadie y discutir cosas con 4 personas primero tampoco me sentiría muy igual como miembro extranjero. Mantendré mi respuesta y diré que haces un mejor trabajo con Scrum o lo abandonas. Pero decirle a la gente que están en un equipo Scrum y luego no tratarlos como parte del equipo está condenado al fracaso. Ya estás viendo señales de ello.
Pero déjame decirte esto: sí, tienes problemas con la calidad y puedo ver por tu razonamiento que necesitas una solución. Tal vez el tuyo incluso funcionaría. Pero Scrum se basa en el hecho de que el PO dice lo que se debe hacer y el equipo determina cómo se puede hacer. Entonces, si quiere ser el PO en ausencia del PO, dígales lo que quiere (¿menos errores?) y déjelos decidir cómo quieren hacerlo.

Tenemos un pequeño equipo de scrum de 8 miembros. Actualmente administro el trabajo y las asignaciones del equipo Scrum, aunque técnicamente no soy el gerente del equipo.

Estas dos oraciones no se alinean. Si está haciendo scrum, entonces no debería haber ninguna asignación de trabajo. Los miembros del equipo deben recoger historias a medida que avanzan. Idealmente, deberían ser capaces de manejar cualquier historia y tratar de trabajar en una variedad de historias para mantener un conjunto de habilidades tan amplio como sea necesario.

Si se necesita más/mejor control de calidad, debe discutirlo con el propietario del producto y el equipo de scrum para decidir cómo el grupo quiere resolver el problema. Si tiene algún tipo de rol de liderazgo técnico (que parece), entonces está bien que lleve esta necesidad al equipo, pero el equipo debe decidir cómo manejarla.

Con respecto a la insatisfacción actual, esto es algo que debe manejarse en la discusión retrospectiva para que el equipo pueda decidir cómo proceder en futuros sprints.

Actualizar la edición de la pregunta de la publicación :

Discutir con la mitad del equipo de scrum (la mitad en el sitio) no es cómo debería funcionar esto y es probable que haya alienado a la mitad en el extranjero. En el modelo de scrum, todos los miembros del equipo que no son de OP deben ser iguales al discutir cómo debe operar el equipo. Acaba de decirles a los 4 trabajadores externos que no son iguales.

Entiendo que todos los miembros deben ser incluidos en las discusiones. Pero la única razón es por la falta de superposición de horas de trabajo para llevar a cabo dichas reuniones.
Esa es una de las partes difíciles de hacer un equipo de scrum distribuido, pero al final del día, este tipo de cambio debe ser la voluntad del equipo si se va a ser fiel al scrum. No es realmente scrum si no puede encontrar horarios regulares para que todo el equipo se reúna.

Hay detalles que está omitiendo o pasando por alto que tendrán un impacto profundo en la forma en que se debe abordar la situación.

Voy a comentar cada punto y algunas preguntas que me vienen a la mente:

  1. Nos dice que no es el administrador, pero que está aplicando cambios.

¿Estos cambios se están implementando con el apoyo y el consentimiento del equipo, o en base a su autorización o autorización?

Si usted, aunque no es oficialmente su jefe, de repente quiere imponer cambios importantes, es natural que algunas personas reaccionen mal ante su demostración de autoridad.

En otras palabras, dependiendo de su posición dentro del equipo y cómo anunció estos cambios, podría ser lo que causó la fricción.

  1. Está tomando medidas para imponer cambios bastante fundamentales. Esto plantea de inmediato dos preguntas importantes. ¿Son necesarios y el equipo entiende/está de acuerdo en que son necesarios?

Si algunos de los miembros del equipo están entregando un código deficiente y esta es su solución, entonces esta persona puede sentir que está pagando por el error de otra persona.

¿Comunicaste tus razones y motivaciones para querer adoptar estos cambios? ¿Tus compañeros de equipo tuvieron la oportunidad de darte alguna opinión o decir lo que piensan? ¿Hubo algún tipo de debate sobre la situación?

No menciona cómo manejó todo lo anterior, por lo que es muy difícil determinar qué podría estar sintiendo el equipo en este momento. Sin embargo, le sugiero que tome la reticencia de esta persona como una señal de que los demás también pueden tener dudas.

Haga una declaración para todo el equipo que explique su razonamiento (si aún no lo ha hecho) y aborde sus inquietudes.

  1. ¿Es este tipo generalmente un alborotador, o su disidencia es una completa sorpresa?

Si esta persona es generalmente un mal compañero de equipo, entonces no debes preocuparte demasiado por su actitud; algunas personas nunca serán felices sin importar lo que hagas. Es posible que desee hablar con él y simplemente aclararlo.

Sin embargo, si generalmente está de acuerdo con las decisiones del equipo y solo ahora está expresando preocupaciones, lo más probable es que algo en su enfoque lo desencadene. Esta es una situación más delicada. Debe acercarse a él, obtener algunos comentarios y abordar sus inquietudes.

Escribí toda la situación elaborada si algo cambia de sus opiniones.
Para 3, generalmente expresa su voz en voz alta sobre los problemas y tenemos argumentos sobre problemas de diseño, etc., pero finalmente llegamos a un acuerdo. Pero él no es un creador de problemas. Es bueno en lo que hace. Me siento mal, nunca volverá a hablar ni a dar ideas sobre lo que hice hoy.

Supongo que este miembro del equipo está enojado conmigo ahora. Simplemente me sentí así, no hubo signos explícitos, sino basados ​​en la forma en que habló. ¿Cómo manejar tales situaciones?

Lo manejas dejando que se enoje, pero aún así lo haces responsable de sus entregas.

No eres su jefe. No eres su niñera. No eres su representante de recursos humanos. No eres su consejero de carrera.

En cambio, usted es el Scrum Master (o está administrando este equipo Scrum).

Usted hace su trabajo de dirigir el equipo y exige que él haga su trabajo.

El equipo es un desastre desorganizado que se parece vagamente a Scrum, el gerente está ausente sin permiso, los desacuerdos del equipo sobre cómo implementar las pruebas, ¿qué debo hacer? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v