Putting it together

by Luismi Cavallé

Antes o después todos tenemos que afrontar el hecho de darnos cuenta de que “al ritmo que vamos” no hay manera de cumplir con la fecha de entrega comprometida. Llegados a esta terrible situación, tenemos varias opciones:

  1. Echar horas como locos y reducir la calidad, pero entregar en fecha.
  2. Retrasar la fecha de entrega, intentando mantener la calidad.
  3. Aumentar el número de personas del equipo, sin variar la fecha de entrega.
  4. Reducir el scope (el ámbito) de lo entregado, sin retrasar la fecha de entrega ni añadir man-power al equipo

Atención, pregunta: Un desarrollador ágil, ¿qué opción eligiría? (no vale mirar el título del post…)

En cuanto a la primera opción, poco hay que decir. Todos sabemos que está mal pero es lo que más a menudo se hace. “De aquí no se va nadie hasta que esto se acabe!!”. La calidad debería ser algo incuestionable, pero…

Respecto a ser respetuosos con la calidad retrasando la fecha de entrega, primero, no siempre es posible (depende de las circunstacias del proyecto y del cliente) y, segundo, aunque sea posible no parece que esto se lleve bien con la idea ágil de entregar valor al cliente a menudo (primer principio del manifiesto ágil). Retrasar la fecha de entrega supone, de momento, entrega 0 valor al cliente, y por tanto no recibir ningún feedback. Y luego ya veremos si conseguimos cumplir con la nueva fecha o nos seguimos retrasando.

Aumentar el número de personas en el equipo es una solución clásica. Tan clásica que el libro The mythical man-month ya la descartaba en los años 70 (es curioso que aún hoy, donde es posible, siga siendo igual de tentadora). El argumento central de este libro, conocido como la Ley de Brooks, es que añadir personas al final de un proyecto no solo no lo adelanta sino que, de hecho, lo retrasa aún más. Conviene echarle un ojo al libro en cuestión.

Así que llegamos a nuestra última opción. Ante nuestro problema de retraso hemos considerado jugar con tres de las cuatro variables: la calidad, que nos ha parecido innegociable, la fecha, que hemos preferido no tocar para no dejar de entregar valor al cliente, y el personal, que no aumentaremos para no retrasar más aún la entrega. Con lo que solo nos queda un factor con el que jugar: el scope. Podemos, sencillamente, entregar menos de lo que teníamos previsto. El desarrollador ágil, en realidad, llegada esta situación desagradable de tener que enfrentarse a la realidad de no llegar a la fecha, más que un problema ve una oportunidad. Una oportunidad de entregar menos. Y es que para el desarrollador ágil menos es más. Una oportunidad para retrasar decisiones. Una nueva restricción que va a obligar a replantear las cosas con el cliente, a repriorizar y a separar aquello que realmente es importante de lo que no.

En cuanto a lo que se deja sin desarrollar, en la próxima iteracción se volverá a planificar —o no, porque ahora es posible que nos demos cuenta de que hay otras funcionalidades más importantes.