Scrum: Manejar la falta de motivación

12

Según this , "Scrum se basa en un altamente motivado, Equipos estrechamente colaboradores, multifuncionales y autoorganizados ". Entonces, ¿cómo maneja a los compañeros de trabajo que pueden no estar tan motivados para tomar posesión del código? ¿Cómo lograr que alguien se interese en tomar posesión?

    
pregunta Brian Mains 27.02.2012 - 22:18

3 respuestas

14

No sé si este es el problema de su equipo, pero definitivamente fue para nosotros cuando introdujimos el scrum por primera vez. Nuestra gerencia nos contactó un día y nos dijo que a partir de ahora no trabajará en silos individuales. En su lugar, estarás trabajando como un scrum. Aquí hay un montón de nuevos procesos que todos deben seguir y seguirlos que seguirán.

La clave es que nunca vinieron a nosotros, los desarrolladores, y nos preguntaron: ¿cómo quieren trabajar? ¿Qué te hará más feliz? ¿más eficiente?. Entonces, lo que escuché fue que "ya no tienes ningún código. Cualquier cosa que escribas, será pisoteada (ya sabes, propiedad del equipo). No moverás ni levantarás un dedo porque ahora administraremos tu tiempo por hora". Ah, y ahora tienes una rutina aburrida de 15 minutos todos los días, donde las personas discutirán cosas que no te interesan y, por lo general, demoran 30 minutos y luego cada dos semanas tendrá una reunión de planificación súper aburrida de 4 horas que seguramente apestará toda la vida fuera de ti.

En realidad, esto no es Agile o Scrum, solo se está moviendo de un estilo de administración a un estilo diferente, donde todo está controlado centralmente, y no solo me quitó toda la vida, sino que también me dio Mucho tiempo libre para actualizar mi currículum.

En los últimos doce meses, después de presionar en numerosas ocasiones para que el gerente de nuestro equipo probara algo diferente, en realidad aceptó mis sugerencias y creo que hemos tenido un año muy exitoso.

Creo que el cambio clave para nosotros fue dar a los desarrolladores mucha más voz y libertad para elegir cómo queremos trabajar. Pocas cosas que hicimos:

  1. Divida al gran equipo de desarrollo "ágil" en 3 pequeños para que cada uno solo tenga 3-4 desarrolladores. Esto hace que todos se comprometan y los individuos no se ahogan.
  2. Asegúrese de que todos los miembros del mismo equipo trabajen en la misma área funcional para que a las personas les importe lo que otros hablan en las presentaciones y los planes de iteración.
  3. En lugar de la administración, simplemente seleccionando quién trabaja en qué y asignando historias / tareas, creamos un retraso y el equipo mismo tuvo mucho que decir sobre cómo se divide el trabajo.
  4. Como teníamos muchos miembros nuevos, comenzamos con un sistema de silo en el que cada persona posee un área principal de responsabilidad. Esto permitió a nuevas personas enfocarse en un área más pequeña de un producto desconocido y también tener una idea más rápida de que no están jugando en el arenero de otra persona. Pero a los 6-8 meses de iniciar el programa, esas áreas comenzaron a transformarse a medida que los límites se volvían más grises. Ahora los muchachos, en los equipos en los que estoy, se sienten bastante cómodos al ingresar el código de otros o hacer que otros desarrolladores trabajen en el suyo.
  5. Las revisiones de código de todas las presentaciones fueron clave (y esto fue lo primero que se omitió cuando hicimos Scrum por primera vez):
    • Transferencia de conocimiento en términos de técnicas / métodos de programación
    • Fue bueno para otros aprender código que no habrían visto de otra manera
    • Su equipo tiene la oportunidad de comunicarse y socializar, lo que mejora la dinámica del equipo.
    • Y supongo que las revisiones de código detectarán uno o dos errores, pero veo su valor principalmente en los aspectos anteriores.
  6. La gerencia tiene que escuchar al equipo. Si el equipo dice que algo no funciona o necesita ser cambiado, y simplemente lo ignoran, los miembros del equipo simplemente se retirarán y dejarán que la gerencia se encargue del proyecto. Si desea que las personas estén motivadas, deben estar confiadas y solo se concederán si están haciendo lo que creen que es correcto, no lo que se les dice que hagan desde arriba.
respondido por el DXM 28.02.2012 - 03:50
4

Hay muchas razones para la falta de motivación, pero probablemente la más común es no sentir que tienes algo que decir. Cuando nuestro equipo comenzó a hacer scrum, noté que las personas menos motivadas acerca del scrum se dieron la vuelta después de ver cómo se implementaban las sugerencias de las retrospectivas.

Un montón de problemas menores pueden sumarse hasta ser desmotivadores. Por ejemplo, una cosa que surgió la semana pasada fue un miembro del equipo a quien no le gustaban las reuniones a las 4:00. Eso es fácil de arreglar.

En otras palabras, la mejor manera de averiguar qué es lo que está desmotivando a tu equipo es preguntándoles.

    
respondido por el Karl Bielefeldt 28.02.2012 - 02:48
3

Dándoles propiedad individual sobre el código.

Muchas tiendas trabajan en un modelo de "propiedad del equipo". Esto es excelente para la colaboración cruzada y la reducción de riesgos, pero no tanto para motivar a las personas a ser personalmente responsables. La propiedad del equipo puede resultar en un código promedio, porque no hay incentivo de propiedad individual.

Solución: Asigne individuos a cada sección del código para que sean administradores de esa parte del código, pero permita el acceso completo del equipo a toda la base del código.

Vea también: enlace

    
respondido por el Robert Harvey 27.02.2012 - 22:24

Lea otras preguntas en las etiquetas