Scrum y la motivación

Parece ser que un equipo está motivado principalmente por dos factores:

• Visibilidad (logros tempranos)
• Reconocimiento

Pero existe un peligro a tan fantástica conclusión, y es que al contrario, podría usarse Scrum para motivar al personal, simplemente porque "parece ser que los equipos que usan Scrum están más motivados". Es decir, olvidaríamos los requisitos, premisas y dogmas de Scrum, para centrarnos en "tener contentos a los programadores".

Recientemente me he encontrado con premisas de este tipo: el seleccionar Scrum, como herramienta de motivación para los equipos de desarrollo. Después de todo, no parece una mala idea el motivar a los equipos mediante un cambio de forma de trabajo. Al final, el problema está siempre en necesidades contrapuestas. Por desgracia, al igual que tenemos un triángulo del software (calidad, tiempo, recursos), también tenemos un triángulo de actores que se relacionan con el desarrollo del software:

• El cliente: tiene unas expectativas, y unos requisitos funcionales. No ve valor en el código, sino en necesidades de negocio resueltas.
• La dirección (los jefes del equipo de desarrollo): la empresa no vive del aire, y para poder seguir desarrollando, hay que poder seguir emitiendo facturas. Tiene unos requisitos económicos y de negocio. Estas necesidades de la dirección está íntimamente relacionada con las labores "ingratas" o rechazadas por parte del equipo desarrollo (control, monitorización, documentación).
• El equipo de desarrollo: En este caso, se trataría más bien de unos requisitos de satisfacción laboral, de bienestar social, reconocimiento, y algo que parecemos olvidar siempre: hay que cobrar todos los meses. No sólo de metodologías ágiles y buen rollito vive la gente.

Hay que tener en cuenta estas interrelaciones entre los tres, ya que podemos encontrarnos con que la implantación de Scrum u otras metodologías ágiles, no consiga la motivación deseada, o lo haga de forma temporal.

Es por eso, que en vez de buscar la mera implantación de una metodología, lo que hay que hacer es detectar las necesidades de los actores alrededor del desarrollo software, y lograr un equilibrio mediante:

• Políticas de reconocimiento de logros
• Metodologías que mediante técnicas ágiles obtengan logros tempranos, pero que no perjudiquen las necesidades de información de los clientes y gestores.
• Sistemas de mejora continua, que satisfagan tanto a la empresa como a los desarrolladores.