Scrum: manejo de la falta de motivación

De acuerdo con esto , "Scrum depende en gran medida de equipos altamente motivados, muy 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 hacer que alguien se interese en tomar posesión?

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

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: "ya no tienes ningún código. Cualquier cosa que escribas será pisoteada (ya sabes, propiedad del equipo). No te moverás ni levantarás un dedo porque ahora administraremos tu tiempo por horas". Ah, y ahora tienes un aburrido stand-up de 15 minutos todos los días donde la gente discutirá cosas que no te importan y generalmente tomará 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 otro estilo, donde todo está controlado centralmente, y no solo me quitó toda la vida, sino que también me dio mucha libertad. Es hora de actualizar mi currículum.

En los últimos doce meses, después de presionar en numerosas ocasiones para que nuestro gerente de equipo intentara algo diferente, en realidad me tomó en cuenta 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 el equipo de desarrollo "ágil" en tres pequeños para que cada uno solo tenga 3-4 desarrolladores. Esto hace que todos se involucren y las personas no se ahoguen.
2. Asegúrese de que todos en el mismo equipo trabajen en torno a la misma área funcional para que las personas se preocupen de lo que otros están hablando en stand up y planes de iteración.
3. En lugar de elegir simplemente quién trabaja en qué y asignar historias / tareas, se nos ocurrió una acumulación y el equipo mismo tuvo mucho que decir sobre cómo se divide el trabajo.
4. Debido a que 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 las personas nuevas concentrarse en un área más pequeña de un producto desconocido y también tener una sensación más rápida de que no están jugando en la caja de arena de otra persona. Pero a los 6-8 meses del programa, esas áreas comenzaron a transformarse a medida que los límites se volvieron más grises. Ahora los muchachos, en los equipos en los que estoy, se sienten bastante cómodos entrando en el código de otros o haciendo 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 escatimó cuando hicimos Scrum por primera vez):
   • Transferencia de conocimiento en términos de técnicas / métodos de programación.
   • Fue genial para otros aprender código que de otra manera no habrían visto
   • 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 un error o dos, 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 verificarán y dejarán que la gerencia se encargue del proyecto. Si desea que las personas estén motivadas, deben ser investidas y solo serán investidas si están haciendo lo que creen que es correcto, no lo que se les dice que hagan desde arriba.

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 con respecto a scrum se dieron vuelta después de ver implementadas sus sugerencias de las retrospectivas.

Un conjunto de problemas menores pueden sumar desmotivadores. Por ejemplo, una cosa que surgió la semana pasada fue un miembro del equipo al que no le gustaban las reuniones de las 4:00. Eso se soluciona fácilmente.

En otras palabras, la mejor manera de descubrir qué es lo que desmotiva a su equipo es preguntarles.

Al darles la 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 reducir el riesgo, pero no es tan bueno para motivar a las personas a ser personalmente responsables. La propiedad del equipo puede generar un código promedio, porque no hay un incentivo de propiedad individual.

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

Ver también: /software//a/33464/1204