La Prisa, la exigente viejecita que domina nuestras vidas, no solo nos hace escoger las tareas más fáciles para acabar pronto, también nos presiona para que le demos algo rápido, lo que sea, incluso si no está bien terminado. No tiene tiempo que perder, quiere algo y lo quiere ya.

Los nervios por perder nuestro cargo o nuestro empleo acuden a la Prisa para que presione al equipo. Quiere que le entreguemos nuestro trabajo cuanto antes. Ya habrá tiempo para florituras después, no puede esperar más. Si no está bien probado o terminado, ya lo haremos después; con suerte no pasará nada cuando alguien esté usando nuestro producto. Si esto sucede, le pondremos un parche rápido y ganaremos algo más de plazo para una futura corrección. Qué lejano parece siempre el futuro, pero solo está a un segundo de distancia.

Después de entregado, respiramos aliviados. ¡Hemos sobrevivido! Han surgido algunos problemas en la reunión de demo, pero en los próximos sprints le dedicaremos tiempo a corregirlo.

Pronto nos damos cuenta de que la corrección de esas incidencias nos consume más recursos de los previstos. Además, no paran de aparecer nuevas: a las de la semana anterior se suman las de sprints previos.

Cuando decidas ignorar un aviso o esconder problemas debajo de la alfombra, ten por seguro que volverán a aparecer. Y lo harán exigiendo al menos tres veces el tiempo que en su momento habría sido necesario: primero necesitará volver a reconocer el problema, después recabar datos y ponerte en la situación necesaria para corregirlo, y por último, tendrás que solucionar todos los problemas que el error haya generado en el tiempo en que estuvo en producción. Todo esto tener en cuenta que puede que tengas que aplacar la ira del cliente, devolver dinero o responder las quejas de los usuarios.

Pero la Prisa no permite que te olvides de ella. Sigue demandando cosas nuevas, aunque apenas has podido hacer algo; los últimos sprints los has estado dedicando a corregir problemas anteriores. «Bueno, entregaremos lo que tenemos hasta ahora, aunque no esté bien, pero saldremos así del paso», pareces pensar. En algún momento, no sabes cómo, saldrás de este círculo vicioso.

Entregas algo, lo que sea, esté como esté. Una solución rápida para escapar y volver a coger resuello. Crees con esto, encontrar algo de paz, pero así no aplacas a clientes y usuarios. Solo creas una situación que se asemeja al famoso meme del dibujo de un caballo que, con las prisas por terminar, acaba siendo garabateado. Empiezas a ir rápido, pero acabas yendo cada vez más despacio. En cada recodo del camino coges una nueva piedra que echas a tus alforjas. Llega un momento en el que apenas puedes avanzar más.

No sucede solo cuando estás preocupado por tu puesto de trabajo o por contentar a un cliente que se puede marchar. A la Prisa, también recurren el Orgullo y la Vanidad. Queremos mostrar lo rápidos y ágiles que somos con nuestro reluciente Scrum; comenzamos a medir la velocidad y a mostrar a todos los Stakeholders todo lo que hemos podido acabar esta semana.

Cuatro funcionalidades nuevas esta semana, seis la próxima, y ocho la siguiente. Insistimos al equipo para que termine ya esto que están haciendo, no importa cómo. Tenemos que entregar más cosas. «¿Cómo podemos enseñar en la reunión de demo solo dos funcionalidades nuevas?», pareces pensar. Pronto tendremos que parar para corregir problemas mal resueltos en sprints anteriores. A menos que sigamos con esta carrera de la rata, y para continuar con este ritmo, continuemos entregando trabajo aún a medio cocer.

Cuando la velocidad y las reuniones de demo de Powerpoints comienzan a importar más que la calidad y el trabajo bien hecho, es cuando comenzamos a caer en un Scrum que hace más daño que bien. Un Scrum hueco, que solo es una cáscara que esconde un producto defectuoso y un estrés que perjudica al equipo de trabajo. No nos pagan por trabajar rápido. Nos pagan por un producto o servicio útiles que resuelve los problemas del cliente.

Algunos, cansados de estos Scrum flácidos, se han orientado hacia el movimiento Software Craftmanship[1]. Sobre esta tendencia, el conocido Uncle Bob, indica lo siguiente en uno de sus artículos (solo por mencionar algunos puntos).

• Estamos cansados de escribir mierda.
• No vamos a crear un desastre solo para cumplir un calendario.
• No aceptamos esa estúpida idea de ya «limpiaremos» las cosas luego.
• No aceptamos la opción de hacer las cosas mal.
• No permitiremos a nadie que nos fuerce a hacer cosas de forma poco profesional.
• Cumpliremos los calendarios porque sabemos que la única manera de ir rápido es hacerlo bien.
• Si algo merece la pena hacerse, merece que se haga bien.
• El paso lento y constante gana las carreras.

[1] Martin, R. Software Craftsmanship: What it’s all about [en línea]. The clean coder. Disponible en http://thecleancoder.blogspot.com/2011/01/software-craftsmanship-what-it-all.html.