¿Cómo resuelve Scrum la frustración de un desarrollador cuando le viene una enésima modificación de su tarea?

Si preguntamos a los programadores qué es lo que más les fastidia y más malestar les produce, su contestación suele ser que cuando les hacen modificar una y otra vez el mismo código o transacción. 

Desesperado ante un cambio, gracias Pedro por la escenificación :-)

En equipos tradicionales, sin valores ágiles adquiridos, los desarrolladores suelen no ver más allá de la parte del desarrollo que les atañe directamente, y son varios los sentimientos de rechazo que puede producirles un enésimo cambio:

• Una asociación automática con que les viene "otro marrón que no es mío" que supondrá un esfuerzo por su parte y que asociará directamente a correr, a estrés y a hacer horas extra
• Un sentimiento de crítica hacia su trabajo, contrario al reconocimiento que todos necesitamos
• Enfado hacia el usuario, analista o jefe de proyecto que según su percepción no sabe lo que necesita, produciéndose exclamaciones como "Que hagan bien su trabajo, y antes de marearme que definan bien..."
• Desmotivación por sentirse anclado a la misma pierda y no ver avance

Una de las consecuencias más caras de la desmotivación puede ser una degradación paulatina del código, la incurrencia en deuda técnica y por ende, de una calidad mediocre del producto.

Como expone el Manifiesto Ágil "valoramos la respuesta ante el cambio sobre seguir un plan", Scrum abraza el cambio y por tanto, situaciones de enésimos cambios sobre un mismo objeto forman parte de la naturaleza de los proyectos ágiles. Entendido esto, tanto por el equipo como por todos los demás interesados, la mentalidad con la que el desarrollador se enfrenta a estos cambios es muy distinta. El cambio no le rompe nada, el cambio forma parte de su día a día y tiene la vía de incorporación del cambio resuelta:

• La tarea al estar dentro de un sprint intocable, con un inicio y un final, hará que el programador haya cerrado mentalmente el cambio en curso antes de iniciar un posible cambio posterior en otro sprint
• No hay solapamientos. Nuevos cambios, nuevos sprints, un espacio propio y acotado para cada cambio. Al entrar en un sprint el nuevo cambio este es reconocido y aceptado por todos, tanto equipo como interesados
• Gracias a la comunicación y transparencia propia de Scrum, el programador tiene visión del producto y así está preparado para entender el porqué del cambio. Tiene empatía hacia el cliente y es capaz de ver y entender la necesidad del cambio, y de que se ha producido por un cambio sufrido en el negocio/mercado que se le ha contando y comprende
• No tiene sensación de hacer un esfuerzo extra, cada cambio viene a través la pila de producto y entra en la pila de sprint con el tiempo necesario para realizarlo
• No tiene sensación de trabajo mal hecho, si su tarea ha estado bien hecha ha sido reconocida en la reunión de revisión de sprint correspondiente
• El sentimiento es de avance continuo, si no es por su tarea inmediata percibe el avance en adaptación del producto a las variaciones del negocio

La motivación hace que el desarrollador se sienta parte del proyecto y viva el producto, y de esta forma busque automáticamente la mejora continua en el código.

La motivación intrínseca que propicia Scrum va mas allá de la satisfacción del trabajo técnico bien hecho, esta surge del trabajo en conjunto bien hecho, sentir el orgullo de como la herramienta en que se ha participado resuelve realmente el trabajo diario a usuarios y clientes.