Algunos miembros del equipo no participan activamente en la planificación de Sprint

15

Algunos miembros del equipo solo esperan hasta que se discutan las historias en las que es más probable que trabajen y solo entonces participan. De lo contrario, solo juegan con su teléfono y no escuchan.

De alguna manera entiendo esta posición. ¿Por qué escuchar una discusión sobre una característica que es poco probable que ayude a desarrollar en Sprint o alguna vez?

¿Qué crees que deberíamos hacer?

agile scrum

— Eugene
fuente

99

¿Qué tan grande es este equipo?

— JeffO

8

@JeffO dio en el clavo: este es un problema clásico del equipo de gran tamaño. Equipo de gran tamaño = autoridad / responsabilidades individuales de tamaño insuficiente = compromiso individual de tamaño insuficiente. Un equipo del tamaño adecuado significará que todo lo que ustedes hablan afecta a todos en la sala. Alternativamente, está asignando demasiadas responsabilidades: ¿por qué escuchar una discusión sobre una característica con la que es poco probable que ayude? Un equipo del tamaño adecuado que no tenga responsabilidades en el silo debería hacer que todos trabajen en cada función.

— Jimmy Hoffa

77

Teléfonos apagados, sin excepciones. Sencilla reunión de sentido común.

— user1019696

55

@ user1019696 para ser justos, podría recibir una llamada telefónica de mi esposa de que mi hijo le rompió la pierna en cualquier momento. Hay una gran diferencia entre "teléfonos apagados" y "no te metas con tu teléfono en medio de una reunión, porque es simplemente irrespetuoso".

— Jimmy Hoffa

44

@ Si hablas de una época en la que había secretarias de la compañía, no ha habido esa persona en una compañía en la que he trabajado durante años; no tendrían nada que hacer. Y no, no puede esperar. Especialmente no por trabajo, lo siento pero familia> trabajo. Dicho esto, tal vez recibo una llamada en medio de 1 de cada 30 o 40 reuniones (tal vez ??) de las cuales probablemente respondo 1 de cada 30 o 40 ... No es difícil no ser un idiota con su teléfono. Si las personas los necesitan discapacitados o eliminados de sus personas para evitar ser un imbécil, tal vez esa persona sea simplemente un imbécil.

— Jimmy Hoffa

32

Detener la propiedad del código. Haga que sea igualmente probable que cualquier persona en un equipo trabaje en una tarea determinada.

Es casi seguro que habrá un retroceso en eso, porque los desarrolladores se sienten cómodos con un área específica de código y con otras personas que no miran por encima de sus hombros. Además, la administración verá un problema con el trabajo que demora más de lo normal, porque siempre hay una curva de aprendizaje.

Pero realmente es lo mejor para todos. Ser indispensable es una espada de dos filos. Comienza a ser más difícil tomarse un tiempo libre, por la noche, los fines de semana o tomar vacaciones. Y la propiedad del código es mala para una empresa porque, cuando alguien se va, le cuesta más tiempo del que haya ahorrado en pequeños fragmentos de transferencia de conocimiento.

— pdr
fuente

44

+1 absolutamente. Hay una falsa impresión de eficiencia cuando crees que los codificadores son solo otra parte de la línea de ensamblaje y luego te preguntas por qué un proyecto se retrasa porque uno de los engranajes necesita ser reemplazado.

— JeffO

3

@JeffO que es más o menos el estándar entre la gestión de la empresa de desarrollo de software en mi experiencia, teniendo en cuenta los desarrolladores a ser piezas idénticas en una máquina que puede ser intercambiado al instante por otra unidad de carbono ...

— jwenting

3

@jwenting lo que los hace perfectamente adecuados para ser subcontratados también. No veo por qué los desarrolladores ayudan en esta actitud.

— GrandmasterB

1

@jwenting Ese es el punto de ágil. Para cambiar este tipo de visión sobre las cosas.

— Eufórico

1

@Eufórico en mi experiencia, el resultado final es el reverso, los gerentes ven a las personas aún más como activos que pueden intercambiarse sobre la marcha, como requisitos ...

— comenzando

15

¿Invitas a las personas adecuadas a tus reuniones? Si ha dividido el sistema en áreas de responsabilidad para los equipos secundarios, ¿por qué invitar a todos los equipos secundarios a cada reunión?
Por ejemplo, si tiene un equipo frontend y un equipo backend, mantenga las sesiones de planificación para el trabajo frontend a los miembros del equipo frontend. Tal vez invite a alguien del equipo de backend como enlace en caso de que una tarea cruce los límites del equipo (pero si eso sucede con frecuencia, es posible que desee reevaluar la división de responsabilidades entre sus equipos).
Idealmente, todos deberían trabajar en todo, pero en realidad eso a menudo no es práctico a menos que su sistema sea realmente pequeño y simple, lo que hace que todos conozcan cada parte a fondo. En la práctica, por supuesto, muchos sistemas son lo suficientemente grandes como para esperar que cada miembro de su organización tenga suficiente conocimiento de una tarea planificada para poder dar una entrada válida durante las sesiones de planificación (y mucho menos ser igualmente productivo trabajando en cada parte del sistema). Simplemente no realista.

— jwenting
fuente

12

Su desinterés es solo un síntoma. El problema es que no está distribuyendo el trabajo de manera uniforme a todos los miembros de su equipo. Idealmente, cada miembro del equipo debería recoger cualquier boleto nuevo que no esté restringido a ciertas áreas del proyecto.

— Tom Squires
fuente

3

Eso es bueno en teoría. En la práctica, especialmente en proyectos grandes, el sistema puede ser lo suficientemente grande como para que no sea práctico que cada miembro del equipo tenga suficiente conocimiento de cada parte para ser productivo al trabajar en él.

— Jwenting

@jwenting: parece que este equipo está muy seguro de que nunca se les exigirá que trabajen en otras partes. Aunque una persona no puede saberlo todo, eso no significa que deba aprender lo menos posible.

— JeffO

@JeffO es cierto, pero no se puede esperar que puedan participar activamente en la planificación de cosas para áreas de las que no tienen conocimiento. Escucha y aprende, pero mantén la boca cerrada. Y tal vez use su teléfono celular para tomar algunas fotos del tablero de planificación :)

— comenzando

1

@jwenting en la práctica en grandes proyectos, ¡necesita distribuir más el trabajo! No es que todos tengan el mismo conocimiento, pero es igualmente probable que trabajen en cualquier área en particular. Permitir excusas hace que los miembros del equipo sean más propensos a no adoptar nuevas áreas.

— Dave Hillier

5

Suena como un problema de motivación: ¿por qué a algunas personas no les importa el proyecto en el que están trabajando? Tal vez sea porque el equipo se divide en los "organizadores" y los "excluidos".

Por lo tanto, involucre a todos, en lugar de que 1 o 2 personas se hagan cargo de las sesiones de planificación, involucre a todos: haga que diferentes personas se hagan cargo de cada sesión, preferiblemente haga que diferentes personas se hagan cargo durante la sesión. Gíralo todo. Sé que esto puede parecer difícil porque siempre hay alguien que quiere preocuparse y organizar a todos, pero ellos son el problema aquí.

He aquí una idea: cuando planifique, elija una persona al azar para hacerse cargo de cada historia. Al azar. Registre quién fue responsable de la planificación de la misma, por lo que en el próximo sprint podrá saber si hicieron un buen trabajo para lograr un buen consenso de estimaciones y división de tareas. Eso los hará prestar atención y también les dará una razón para comprometerse con el proyecto.

Recuerde, el problema no son ellos, es usted y la forma en que se realizan sus sesiones de planificación. Entonces, cuando alguien más se hace cargo de un plan de historia, pueden elegir cómo hacerlo, debe haber una forma oficial de proceder. (es decir, no se siente y continúe forzando a su organización sobre ellos por poder)

— gbjbaanb
fuente

Buenas ideas. Esperemos que la gente no vea esto como una pérdida de tiempo.

— Eugene

1

¿Cuál es la duración de tu sprint?

Las duraciones de sprint más largas conducen a

Más trabajo para planificar en el sprint, lo que lleva a
Reuniones de planificación más largas, lo que lleva a
Mayor dificultad para que los miembros del equipo se mantengan enfocados, ...
Los miembros del equipo se aburren

Entonces, si la duración de tu sprint es más de dos semanas, intenta trabajar en sprints más cortos.

Si es difícil lograr que las partes interesadas se comprometan con sprints más cortos, entonces puede omitir algunas de las reuniones formales, por ejemplo, solo tener la revisión del sprint después de cada 2 sprints, en lugar de después de cada sprint.

— Pete
fuente