¿Cómo nos ayuda Scrum a llegar a la fecha?

En las últimas semanas, uno de los clientes nos ha lanzado un reto: cómo gestionar fechas con Scrum. La empresa quiere lanzar una serie de productos y necesita saber cuándo estarán, pero con el cambio hacia Scrum parece que las fechas son un problema. ¿En Scrum se utiliza para alcanzar una fecha? ¡Lo estudiamos! 

Imagina que sois tres amigos y decidís montar una empresa. Al principio, todo va bien, conseguís clientes con proyectos pequeños a los que sois capaces de dar respuesta. Os comprometéis a hacer proyectos con fechas cerradas a dos o tres meses y cumplís con ellos. La organización crece y llega un momento en el que sois cincuenta personas. Ahora, vuestro código se ha vuelto más complejo, estáis abordando proyectos más ambiciosos con clientes más grandes y empezáis a tener problemas para entregar. 

En ese momento, decidís introducir el desarrollo ágil y, en concreto, Scrum. Sin embargo, las cosas empiezan a ir peor, dejáis de prometer fechas a vuestros clientes. Habéis leído que con Agile no se trabaja con fechas cerradas. Vuestra organización ha pasado a ser menos competitiva… ¿Os ayuda Scrum en esta situación?

¿Necesitan las organizaciones trabajar con fechas? 

Un CEO siempre va a necesitar gestionar fechas, y hay muchos motivos: estrategia de la empresa, compromisos con clientes o hitos relevantes de su negocio. Todos sabemos que el black friday está ahí, y que, si queremos aprovecharlo, debemos llegar a él. Las fechas son parte esencial del mundo y las organizaciones deben adaptarse para dar su mejor servicio. 

En Scrum, podemos trabajar con fechas, decir “esto no es Scrum porque tenemos fecha” puede ocasionar rechazo en las organizaciones que apuesten por este marco. Precisamente, Scrum trata de ayudar a un mejor delivery del equipo, sin fechas podemos generar rechazo. 

La misión de Scrum no es saber con exactitud si seremos capaces de entregar un alcance cerrado, en una fecha cerrada, con una calidad máxima y controlando el coste. Es decir, conseguir lo que en muchos proyectos tradicionales aspiran a alcanzar. Recordemos el famoso triángulo de hierro: 

Mientras que en el modelo tradicional, buscamos hacer una buena definición del alcance para, con ella, calcular el coste y el tiempo. A partir de ahí, la misión de un Jefe de Proyectos es controlar ese coste, ese tiempo y ese alcance. En Scrum, la estrategia más extendida de trabajo, consiste en dejar el alcance “abierto” de manera que tratemos de desarrollar lo que más valor nos aporta en el tiempo que tenemos. Aún así, como veremos en el resto del artículo, hay otras maneras de gestionar fechas. 

Realmente, Scrum al igual que el desarrollo ágil, nos permite gestionar el riesgo de nuestro equipo. Cuando hablamos de riesgos, hablamos de multitud de situaciones desagradables para la organización que podrían pasarnos cuando desarrollamos software: 

• ¿Qué pasa si no conseguimos todo el alcance en la fecha prevista? ¿Podríamos perder al cliente? 
• ¿Y si renunciamos a la calidad con tal de llegar? Esto podría afectar a la motivación del equipo y a nuestra imagen como marca. 
• ¿Qué pasa si invertimos mucho dinero en tratar de llegar y acaba por no ser rentable? 
• ¿Y si conseguimos llegar a la fecha con el alcance deseado y con calidad pero ningún usuario quiere nuestro software? 

Todas estas preguntas son riesgos que cualquier empresa necesita poder gestionar. Scrum nos ayuda a tomar decisiones con información real que nos ayude a gestionar el riesgo. Analizamos algunas situaciones típicas que se nos pueden presentar y cómo Scrum nos ayuda: 

Tenemos una fecha cerrada por un motivo relevante

Hay una fecha relevante para nuestro negocio: el black friday como mencionamos antes, el inicio de las vacaciones de verano o queremos finalizar el contrato con otro proveedor e introducir nueva tecnología que sustituya la anterior. 

Imaginemos que tenemos un equipo que lleva tiempo trabajando junto con este cliente. De pronto, el cliente necesita saber si llegaremos con un alcance concreto a una fecha importante para ellos. En un planteamiento tradicional, se pararía al equipo para que hagan un análisis detallado, después una estimación precisa y, finalmente, si se asume el compromiso de llegar. Asumir un compromiso basado en un análisis realizado en un momento muy temprano, sin experiencia trabajando juntos o con el cliente y sin datos de nuestra capacidad de generar producto es asumir mucho riesgo. Esto es debido a que hay demasiadas variables que no controlamos, lo que aumenta el grado de incertidumbre.  Podemos comprometernos y no conseguirlo, lo que afecta a nuestra credibilidad y a la confianza que depositen en nosotros. 

Para hacer este desarrollo con Scrum, os proponemos lo siguiente. El primer paso es reunir al equipo al completo y trasladar toda la información que tengamos. A continuación, les hacemos la pregunta: “¿Huele bien esta fecha?”. Es una manera de, sin invertir demasiado tiempo, saber el pulso del equipo. Si suena a muy descabellado, podemos retirarnos antes de comprometernos con algo que es imposible y nos afectará a nuestra credibilidad.  

Si decidimos avanzar, el siguiente paso es arrancar el equipo Scrum. Trabajando por iteraciones (Sprints) podemos gestionar riesgos, que es la clave del desarrollo ágil. Si al mes de estar trabajando, descubro que lo que iba a hacer se va a incrementar un 200% puedo tomar la decisión de parar. Con un modelo tradicional, esto es más difícil porque en un mes nos centramos en el análisis funcional sin saber lo que cuesta desarrollar software en ese contexto. Pero para que Scrum funcione y pueda darnos información, es vital que en cada Sprint haya una entrega. Sin entrega, no tenemos información de nuestra capacidad de hacer software ya que no habremos recorrido el camino completo. Por eso, en el desarrollo ágil existe el principio de que el Software Funcionando es la principal medida de progreso de un equipo. 

Después, tras varios Sprints, descubrimos que este producto no va a ser rentable, y que terminarlo puede ser una pérdida de dinero. Abandonar puede ser visto como un éxito, no hemos tenido que gastarnos todo el presupuesto para descubrir que este producto no es viable. Abandonar a tiempo siempre es una victoria. Veamos un ejemplo: 

En la gráfica, tenemos la línea naranja, que representa el coste estimado en cada momento, que se actualiza en cada Sprint. En azul, tenemos el coste real gastado a la fecha. En los primeros Sprints, ganamos experiencia y vemos que se nos dispara el coste porque vamos a necesitar más Sprints para terminar (cuando la línea azul se cruce con la naranja es que hemos acabado, la gráfica representa que harán falta más Sprints). Con Scrum, podemos tomar la decisión de abandonar. De hecho, en los primeros Sprints, se decidió continuar a pesar de la estimación porque se creía que se podría conseguir pero el coste sigue disparado y en el Sprint 4 hemos visto que necesitaremos 4 Sprints más. ¿Paramos?

Existe la cultura de que, ya que has empezado debemos acabarlo. Esto es lo que se conoce como la falacia del coste hundido. Un ejemplo que lo ilustra muy bien: imagina que vamos a un restaurante y nuestro hijo se pide un plato de macarrones. Nuestro hijo a mitad del almuerzo dice que no quiere comer más, y nosotros, para no tirar la comida, decidimos acabarnos su plato. Al final, acabamos engordando por “no tirar la comida”, esta es la falacia del coste hundido. En un equipo de software ocurre cuando decidimos acabar un desarrollo que hemos descubierto que no es rentable porque “no vamos a tirarlo a la basura”. 

Analizamos en próximos posts más contextos donde la fecha y el alcance es relevante y cómo Scrum nos puede ayudar.