¿Cómo debe tratarse un cambio de funcionalidad en medio de la ejecución de un sprint?

... el Propietario del Producto avisa al Scrum Master, o directamente al equipo si no encuentra a este último, convoca una reunión extraordinaria en la que se redefine el sprint para incluir el cambio... Chirría ¿verdad?

Cuando el equipo estima las funcionalidades de la parte superior de la pila de producto, hace el corte de lo que cree que le cabe en el sprint y se lo lleva pila de sprint se adquieren dos compromisos:

• El equipo se siente verdaderamente comprometido con la pila de sprint, de verdad cree que puede construir esas funcionalidades. Al fin y al cabo los miembros del mismo han decidido lo que cabe. Resaltar que se trata de que se sientan comprometidos, si por razones lícitas no llegaran a entregar no se les puede exigir que cumplan ningún compromiso.
• Propietario del Producto, jefes de proyecto, gerentes, responsables de área y otros interesados se comprometen a no romper el sprint, a no cambiar ninguna funcionalidad durante el sprint.

¿Porqué funciona Scrum? Porque es como si hiciéramos pequeños proyectos de dos semanas de duración con su entrega real, con todas sus consecuencias, con todo hecho para poder subir el incremento a producción. Esta forma de trabajar nos permite reconducir y cambiar de rumbo del proyecto entre sprint y sprint hacia lo que de valor y de verdad cubra las necesidades de nuestro cliente.

¿Qué puede a ocurrir si se aceptan cambios de funcionalidad a medio sprint?

• Rompemos el sentimiento de compromiso del equipo. La forma clásica de no sentir responsabilidad es "como lo ha dicho mi jefe... el sabrá lo que hace...". Cuando nos sentimos comprometidos nos sentimos motivados y lo damos todo dentro de lo razonable para cumplir con éxito. Si nos rompen eso, si sentimos que otros mandan sobre nuestras acciones, nos sentimos marionetas y perdemos toda responsabilidad, motivación y creatividad.
• Rompemos el ritmo y el trabajo del equipo. Si cerramos un sprint con ciertas funcionalidades y dejamos que el equipo se autoorganice, este encontrará la mejor forma y la más óptima para construir esas funcionalidades. Si rompemos el sprint el equipo tendrá que reconcebir y replanificar, lo que probablemente llevará a la no entrega a final de sprint.

El peor mal de esta conducta es esta no entrega. Cuando no llegamos a entregar una y otra vez, cada 2 semanas, hay un sentimiento de frustración que se acrecienta y que causa un estrés brutal. ¡Tendremos malos finales de proyecto cada dos semanas! Desde la perspectiva del seguimiento del proyecto saltarán alarmas cada dos semanas y eso puede llevar a un control brutal cada dos semanas...

¿De verdad un cambio no puede esperar como mucho dos semanas?

Si de verdad aplicamos Scrum y nos guiamos por valor de negocio, de manera que el equipo siempre esté construyendo aquello que más valor de negocio aporte, no es usual que haya cambios, ya que sobre lo valioso, el equipo de negocio y el usuario tienen muy claro de lo que se trata. Por supuesto el mercado puede traer un cambio inesperado y fulminante, pero eso es una situación excepcional. Scrum es ágil y permite pequeños ajustes a lo largo del sprint, pero nunca rompiendo con el objetivo del sprint.

En Scrum está prohibido cambiar la objetivo de un sprint a lo largo del mismo

Jefe de proyecto rompiendo el sprint junto al sentimiento de compromiso del equipo

La única autoridad que tiene un Propietario del Producto sobre un sprint es pararlo totalmente. Puede ser que no tenga sentido seguir con lo que está construyendo el equipo, y este decida parar el sprint, el objetivo del sprint ya no tiene sentido. A partir de aquí el equipo deberá dedicarse a las actividades necesarias para dejarlo todo bien, acabar cosas y/o deshacer otras. Una vez todo esté estabilizado se empieza de nuevo con Scrum y se sigue el ritmo con un nuevo sprint.

De forma excepcional existe el sentido común, el Propietario del Producto puede plantear la situación al equipo, y si este encuentra una fórmula que no afecte a la entrega ni al sentimiento de compromiso, en definitiva si el equipo encuentra una solución con la que se sienta cómodo, es factible absorber un cambio de funcionalidad. Resaltar que esa conducta excepcional no es Scrum, es puro sentido común y requiere de confianza y "buen rollo".

Scrum es otra forma de pensar y de hacer las cosas, quién cambie las reglas de Scrum al comenzar a andar va a tener muchos problemas. Hay muchas empresas que hacen Scrumbut, que es como se llama, y esas empresas suelen dejar de trabajar con su "Scrum" por el estrés que les genera. Scrum bien llevado crea espacios y tiempos correctos para que todo fluya de una manera motivante y con entregas con gran calidad... pero para eso hay que aplicar Scrum al 100% como es.