No se trabajar sin fechas

Mañana tengo que comprar el pan, la semana que viene voy al teatro, en verano vamos de viaje a Italia. El ser humano siempre ha vivido con una fecha bajo el brazo para todo, medir el tiempo lo llevamos en la sangre y funcionamos de esa manera.

Las fechas nos sirven para planificarnos, para prepararlo todo con antelación y que salga perfecto. A mi esto me recuerdo a cuando estudié en la Universidad, en Octubre ya tenías las fechas de los exámenes de Febrero, y luego acababa la noche antes empollando los últimos apuntes. Un día descubrí la palabra procrastinar y empecé a entender el problema.

¿Qué tiene que ver esto con el desarrollo de software?

Mucho más de lo que creemos. Un día me contaron que se hizo un experimento con un equipo de desarrollo. Se les dió 3 meses para realizar un proyecto y necesitaron 4. Si a ese mismo equipo le dabas 4 meses entonces necesitaban 5. ¿Por qué ocurre esto? ¿Por qué no les doy un mes y así tardarán 2? ¿Por qué si hubieran retrasado los exámenes a marzo seguro que habría acabado la noche antes igual?

El ser humano es malo estimando en tiempo, se nos da mal, y es un hecho totalmente empírico, todos lo hemos experimentado. Ocurre siempre hagamos lo que hagamos, no busquemos órdenes de magnitud, ni busquemos aproximaciones que no existen, estimar en tiempo falla. Si algo hemos aprendido es que hablar de fechas con clientes con los que no has construído ni una línea de código es “lanzarte a la piscina” y reza porque tenga algo de agua. Al final, estás prometiendo algo que no vas a cumplir y eso puede romper una relación de confianza futura, y sin confianza no hay Agile.

Vamos a luchar contra alguna de las típicas frases que nos solemos encontrar relacionadas con las fechas.

“Al cliente siempre hay que darle una fecha para que sepa lo que le va a costar”

Esta frase la podemos oír mucho. Es una frase que destroza la profesión del software desde hace décadas. El software es complejo, no es determinista, y la cantidad de variables que influyen en el desarrollo impiden saber fecha y alcance con exactitud. Sin embargo, tenemos un cliente que necesita saber lo que le va a costar el trabajo. La realidad es que no se puede hablar de fechas en fases tempranas como nos enseña el cono de incertidumbre.

En estas fases, hacer promesas que no puedes mantener te puede matar. Esto no quiere decir que nunca hables de fecha, necesitamos ganar experiencia y aprender para empezar a ser predecibles. Esta es la base de Scrum, el empirismo, y se basa en la toma de decisiones en base a la experiencia. Al cliente hay que darle confianza, esto se consigue con transparencia y trabajo. Si el cliente ve que no le engañas, que toda la información está sobre la mesa y que en cada iteración entregas el mayor valor posible, seguramente la relación funcione.

Vale, sin embargo el cliente quiere saber cuánto le va a costar. Podemos seguir varias estrategias. Por un lado podríamos tratar esto como una inversión y cambiar la pregunta a ¿Cuánto quieres invertir? Y entregar la mayor cantidad de software con valor con ese dinero, esto es lo llamamos maximizar valor y es labor del Product Owner. Por otro lado, podríamos reducir el alcance a 3 Sprints que es más manejable y firmar una cantidad de dinero pequeña. Una vez finalizamos, podemos hablar del resto de funcionalidad que se quiere desarrollar porque ya tenemos experiencia.  

“Vale, una fecha no, pero demos un orden de magnitud”

Los órdenes de magnitud son una trampa que usamos muchas veces, no obstante la realidad es que son unas ventanas tan amplias que no ayudan. Los expertos en materia te dicen que en fases tempranas de un producto software dar una estimación puede variar hasta un 400%. Esto quiere decir que al cliente le puede costar 250 o 1000. La ventana es tan amplia que al cliente no le ayudas y, de hecho, puede llegar a la conclusión de que vas a trabajar lento y mal para cobrarle los mil. La única manera de luchar aquí es transparencia, la transparencia genera confianza.

“Necesitamos la fecha para coordinar otros equipos que tienen que integrarse”

Este argumento lo hemos oído muchas veces. Y es cierto, en desarrollos software de cierta importancia generalmente antes de finalizar tienes que integrarte con otros equipos, no eres una isla. Cuando se ponen fechas de integración casi siempre pasa lo mismo “este web service no hace lo que me dijeron”, “este microservicio no devuelve nada”, “este fallo no estaba contemplado”. Desarrollar en base a pactos de largo alcance suele llevar a muchos dolores de cabeza y discusiones. Si a esto le sumamos que diferentes proveedores hacen partes diferentes, difícilmente colaborarán y realmente cada uno tratará de salvar “su parte”. Al final, el cliente no tendrá el software deseado y perderemos negocio.

La manera de combatir esto es mediante equipos multidisciplinares y autoorganizados. Esto es, si para que un equipo termine una funcionalidad necesita de otros equipos, júntalos a todos. Crea equipos capaces de sacar funcionalidades completas. Aunque sean de diferentes proveedores, si están unidos por un bien común, sentados juntos y rindiendo cuentas como equipo ,es mucho más probable que colaboren y que las cosas funcionen. Hacer equipos por capas y poner proveedores en cada capa retrasa más que agiliza.

“¿Llegarán al Black Friday?»

Si has llegado hasta este punto, habrás visto que no soy amante de las fechas. ¡Pero en el mundo hay fechas! Un Black Friday está ahí, es un día del año concreto, ese día o llegas o estás fuera, lo hagas con Scrum o no, eso al mundo no le importa. En este caso, la solución es plantearte llegar a esa fecha con la mayor cantidad de funcionalidad posible que de valor. Dado que no va a estar todo (lo asumimos), la priorización es clave, y si está basada en los que los usuarios finales demandan probablemente tengamos éxito. El mejor consejo que puedo dar,  es que, no pienses en añadir personas a última hora, ni en echar horas extra o peor aún, ¡renunciar a la calidad! Tener menos funcionalidad es el camino, quitar funcionalidad secundaria hace menos daño que un software que falla.

“Sin fecha no os estáis comprometiendo”

Esta es la frase que últimamente más nos llega. Cuando hablamos de crear un equipo Agile hablamos de que tiene que haber confianza y hay clientes con los que aún no nos la hemos ganado. Pedirles que confíen en nosotros sin habernos visto trabajar es para ellos lanzarse al vacío y eso no podemos negarlo. En este caso, hay varias cosas que podemos hacer: reducir alcance, llegar a un compromiso pequeño, añadir cláusulas de escape para el cliente etc. Sin embargo, el mejor consejo es ser sincero, utilizar la transparencia, que el cliente detecte que no le engañas y que el software que has creado en el Sprint es el máximo que ha sido posible. ¡Pero mejorarás en el siguiente Sprint!

Esto es lo que nos pasa con las fechas, mañana seguramente nos volverán a pedir una estimación para cosas que no hemos hecho nunca y lo haremos. Nuestra profesión está aprendiendo y nos queda un camino muy largo por recorrer. En mi experiencia, he aprendido que raro es el cliente que trabajando en modelo Agile no quiera continuar ¡Acaban por ver los beneficios de ser flexible versus fechas cerradas! Para el resto, tendremos que evangelizar, enseñar, ser pacientes y poco a poco demostrar que es mejor no pensar en fechas y pensar en sacar valor.