Cómo resuelve Scrum los cambios de alcance

Los cambios de alcance son extremadamente habituales en cualquier proyecto software. Los cambios aparecen en diferentes formas: requisitos nuevos, cambios sobre lo entregado, incidencias, nuevos usuarios… En el modelo tradicional de proyecto, hablamos de cambio cuando vamos a hacer algo diferente a lo planificado. En la mentalidad de producto el cambio es bienvenido, los cambios son mejoras sobre lo que tenemos, un descubrimiento para tener un producto que proporcione un mejor servicio. Aún así, todo cambio requiere una gestión ¿O tal vez no? Analizamos diferentes situaciones relacionadas con los cambios de alcance: 

Gestión tradicional: análisis-parálisis

En el mundo tradicional los cambios de alcance se basa en las alteraciones que le queramos hacer al plan inicial. Generalmente, se hace un análisis de lo que se construirá y se firma un contrato en torno a lo que se ha descubierto. A partir de ahí, se fija lo que se llama “la línea base del alcance” y, cada cambio sobre dicha línea se tiene que gestionar. Hay muchas maneras de resolverlo, por ejemplo, aumentando el tiempo (y el coste), otras veces es asumiendo el cambio tal cual, y otras veces intercambiándola por otra funcionalidad de un tamaño similar. 

De una manera o de otra, la gestión del cambio la realiza el Jefe de Proyectos, que alerta a la dirección sobre la aparición de cambios. Las fuentes del cambio son diversas: negocio, interesado al que no se le involucró, descubrimientos que hagamos por el camino, limitaciones técnicas u opiniones de usuarios. 

Los cambios aparecen debido a la incertidumbre, y que aumenten los costes es algo que no sienta bien en las organizaciones. Cuando en un proyecto sufrimos muchos cambios, podemos acabar teniendo muchos problemas como el de no ser rentables. Muchas veces se cree que el problema proviene del análisis inicial, no se dedicó suficiente tiempo. El problema de este pensamiento, es entrar en una fase de “análisis-parálisis”, donde no tomemos ninguna decisión para evitar que después un cambio nos “coma”. Sin embargo, el tiempo sigue pasando y nuestros clientes se impacientan. 

Formalizando la gestión del cambio

Dado que tenemos que tener un contrato firmado y los cambios impactan en dicho contrato, debemos de formalizar el cambio. El PMI (Project Manager Institute) propone una manera de formalizarlo mediante el comité de cambios. Se deben determinar reglas cuando aparecen cambios. Si es un cambio que consume poco % de presupuesto, el Jefe de Proyectos puede aprobarlo de manera automática. Sin embargo, si es demasiado costoso, deberá reunirse con el comité para defender el cambio y esperar su aprobación. Para poder defender el cambio, el equipo deberá reunirse para hacer una estimación del impacto que supondrá dicho cambio.  A esto sumamos que convocar una reunión con personas muy ocupadas que se demoran en el tiempo.

Problema con el login

El problema con los cambios es que en el mundo donde hay complejidad aunque creemos que los requisitos son claros, muchísimas veces vemos que no es así. Un ejemplo que he vivido ocurrió una vez cuando un cliente nos pidió un login para un portal y estimamos la tarea en unas cuantas horas. Cuando fuimos a desarrollarlo, nos dijo el cliente que, éste login debía incluir recordar contraseña y recuperar contraseña. Nosotros protestamos, es un cambio de alcance, hay que renegociar. Sin embargo, el cliente nos argumentaba que nosotros éramos expertos y que deberíamos saber que cualquier login normal contiene esa funcionalidad. Por tanto, esta situación nos lleva a una ambigüedad, que nos puede llevar a un debate duro porque el dinero está por medio y mientras tanto un usuario esperando un software que no llega. 

El origen de los cambios ¿por qué hay que hacerlo?

Los cambios muchas veces no vienen motivados por usuarios finales. A veces. hay cambios antes de salir a producción y de que el propio usuario pruebe el software. Una vez estuve en una aplicación de un gran banco donde cambiaron totalmente el color de la aplicación sin ningún usuario lo hubiera visto nunca. La gestión del cambio es algo que llega a veces antes de salir a producción, sin tener datos de lo que los usuarios opinan. 

Medir la desviación

El problema de la gestión del cambio tradicional es que requiere un parón del equipo para estudiar el impacto que tendrá el cambio en el plan original. Imagínate que mañana cae un árbol sobre las vías del AVE. El operario, lo último que hace es ponerse a estimar el impacto que eso tiene en el ave. Lo que hacen es solucionarlo y después estudiar el impacto real con datos reales de lo ocurrido. Es decir, que lo importante no es imaginarnos el impacto sino actuar y estudiar el impacto a posteriori. ¿Esto se alinéa con Scrum?

Cambios sobre el documento funcional

Otra situación bastante habitual ocurre cuando dedicas mucho tiempo a un documento funcional que no para de cambiar contínuamente. Una vez, en un gran banco, estuve ocho meses desarrollando el documento. Durante ese tiempo, no hicimos nada de software, no pudimos contrastar  que lo que estábamos escribiendo era o no era útil para nadie. Es un ejemplo que nos enseña lo que nos cuesta arrancar sin tener todos los requisitos. Sin embargo, en un mundo digital, se tiene que descubrir lo que quiere tu usuario a base de pruebas y eso que quiere empezar sin tener todos los requisitos. Cuánto antes llegue a mi usuario y le entregue algo, antes tomaré su pulso, y con eso podré tomar decisiones más acertadas. 

Scrum y el cambio

En Scrum los cambios de alcance se simplifican, pero requiere de un factor importante: el Product Owner tiene que estar empoderado. Un cambio en Scrum se gestiona de una manera muy sencilla: se introduce un nuevo ítem en el backlog y se ejecuta cuando toca. De hecho, si estamos hablando de cosas no realizadas, con subir su priorización, un cambio iría antes que otra cosa que llevara más tiempo. Pero todo esto solo es viable si el Product Owner tiene la capacidad de tomar decisiones. 

Para que esto ocurra el Product Owner debe de tener varias cosas que no son muy habituales en las organizaciones más tradicionales. Para empezar, exclusividad en el producto que está trabajando. Venimos de un mundo donde la eficiencia de recursos nos lleva a tener responsable de producto en varios equipos. En segundo lugar, tener el control sobre el presupuesto, ya que los cambios tienen un impacto económico sobre el producto y  tiene que ser responsable para equilibrar coste-beneficio de un cambio. 

Otra factor importante para la gestión del cambio, es utilizar la Sprint Review como un momento para inspeccionar cambios. Es el momento ideal para tener una conversación sobre cambios que queremos y cómo afectarán a nuestro producto. 

También es importante para gestionar los cambios el poder medir el valor de nuestra aplicación. Cómo sabremos que un cambio fue positivo si no sabemos el valor que aporta más allá del coste. Por tanto, es muy importante tener trabajada la visión de nuestros productos y los KPIS de negocios y de valor que nos indican si un cambio es positivo o negativo. 

Además, un buen Product Owner tiene que pasar gran parte de su tiempo en contacto directo con los usuarios del software. Hay varias maneras de hacerlo: un cara a cara con usuarios actuales o potenciales, incluyendo funcionalidades en el software que nos den feedback sobre las sensaciones de los usuarios o estudios de mercado que nos aporten información. Para poder competir tiene que tomar decisiones en base a lo que el mercado le dice y no sólo en base a su intuición. 

Por tanto, los cambios de alcance y su gestión están más relacionados con la cultura de la organización que con el proceso que se siga. En una organización digital, dónde se promueva la eficiencia de flujo, es clave la rapidez entre que escuchamos el mercado y damos una respuesta. Por contra, en el mundo tradicional que busca la eficiencia de las personas, los cambios deben seguir procesos formales para poder controlarlos. Scrum simplifica muchísimo la gestión del cambio dejándolo como una tarea más de gestión de expectativas del Product Owner. Aquí tenemos un ejemplo más donde personas interacciones sobre procesos y herramientas. 

¿Cómo tratáis los cambios de alcance en tu organización?