Yo sí creo en el Sprint 0.

Últimamente vengo percibiendo dentro del mundo ágil algunas tendencias que no me gustan nada. La primera de ellas es el mercadeo en el que se han convertido las certificaciones, que provoca que algunas empresas entren en el error de valorar el nivel de agilismo "al peso" con el número de: PSM, PSPO, PSD, SPS, PSK, PAL, etc.

La segunda tendencia, y la que personalmente más me preocupa, es el alto grado de endogamia en el mundillo y, relacionado con esta poca apertura, la excesiva devoción a la Guía Scrum, casi como si fuera una religión.

Creo que el sector ya debería ser lo suficientemente maduro como para aceptar que los métodos son herramientas y no liturgia. Pero, sobre todo, para aceptar que hay otros mundos paralelos que están mucho más avanzados que el agilismo en algunos temas.

Referencias fuera del mundo agile

Es un hecho que, tanto startups como empresas especializadas en experiencia de usuario, saben mucho más de conceptualización de producto que el mundo agilista, y han creado sus propios métodos para estas cosas.

De estos mundos nos llegan diferentes técnicas de diseño estratégico, diseño de producto, validación con usuarios... optimizadas desde un punto de vista de negocio, por startups a las que, literalmente, les va la vida en ello.

Siguiendo esta filosofía, tenemos ejemplos como el Design Sprint de Google, el Innovation Sprint de Strategyzer, o nosotros mismos en Paradigma, hemos creado nuestro propio Rapid prototyping Method, para testear ideas de negocio con usuarios reales utilizando prototipos realistas.

Y si te alejas a otras disciplinas, mucho más allá del mundo del software (sí, hay vida más allá del software), puedes encontrar también un montón de ejemplos de este patrón.

Músicos y pintores utilizan también técnicas iterativas e incrementales para construir sus obras. Sin embargo, parten de una pequeña fase de research que incluye validación con usuarios, ideación, etc.

Por eso me parece ilegítimo, por parte de los agilistas más puros, el predicar que no hay cabida antes del primer sprint para este tipo de técnicas, simplemente porque no están reflejadas en la Guía Scrum.

En mi opinión, el uso de estas técnicas en una fase anterior al primer sprint es necesario, y diría incluso que el no hacerlo es contraproducente en términos de negocio.

Entonces, ¿dónde está la incompatibilidad?

Yo no estoy de acuerdo en rechazar algo simplemente porque no esté en la Guía Scrum. Creo que el Sprint 0 bien entendido, así como otras prácticas como TDD o Continuous Delivery, que tampoco están en la Guía Scrum, encajan perfectamente dentro de Scrum.

Entiendo que la filosofía de la Guía Scrum es servir de referencia, no detallada, para la construcción de un producto Agile. Debe servir más de brújula que de mapa, y deja los detalles a un equipo regido por los valores descritos en el manifiesto.

La Guía Scrum deja libertad sobre cómo crear el product backlog, y no menciona que no pueda haber nada antes de la reunión de preparación del primer sprint. Por lo que, desde ese punto de vista, el Sprint 0 complementa perfectamente a scrum en el plano del diseño de producto.

La misma corriente de Lean Startup te da incluso una solución de cómo diseñar el modelo de negocio, para después validar las hipótesis con usuarios reales y finalmente utilizar métodos ágiles para la construcción iterativa de una solución digital.

Fuente: Steve Blank

Podemos decir que, si no está en la Guía Scrum, no es Scrum, pero no por ello es malo o hay que rechazarlo. ¿Realmente hay un antipatrón? ¿Cuál es el problema entonces? ¿Es simplemente el nombre?

Si es un problema semántico, casi me da igual utilizar cualquier otro, el nombre de Sprint 0 es bastante autoexplicativo y se entiende bien, pero no se puede rechazar algo bueno por un problema puramente semántico.

A mí me gusta la palabra sprint porque creo que es bueno fijar un periodo de tiempo corto y cerrado de antemano, aunque personalmente design sprint o setup sprint me parecen mejores opciones.

¿Cómo es la vida sin Sprint 0?

Estas técnicas se emplean en una fase previa al desarrollo de software y sirven para sentar las bases de lo que viene después. Sabemos que el entorno en que nos movemos es cambiante y que cualquier intento de planificar e intentar adivinar el futuro a largo plazo es una pérdida de tiempo. Pero en el otro extremo, intentar juntar un equipo y empezar a construir sin una visión de alto nivel de lo que vamos a hacer es contraproducente.

Un Sprint 0 puede servir para llegar a la conclusión de que no necesitas una aplicación móvil nueva, sino optimizar una web existente para que se vea en móvil, o que el producto que pensabas enfocar en grandes empresas es mejor enfocarlo en pymes. O incluso que abordar un producto no tenga sentido en términos económicos y sea mejor no abordar más sprints.

Y no, no estoy hablando de una fase de análisis tradicional encubierta, con exceso de papeles y planificaciones, sino de algo lo más corto posible, que siga los principios ágiles y que nos sirva para sentar las bases de lo que será el producto digital: modelo de negocio, visión de producto, principales funcionalidades, versión inicial del backlog, etc.

Por otro lado, en el mundo del software hay gente que piensa que trabaja en una ONG o que el dinero llueve del cielo. Pero al final, cualquier nuevo producto necesita una financiación, ya sea interna por parte de la propia empresa, o bien externa si eres una startup.

En ambos casos no me imagino pidiendo esta financiación sin unas bases de lo que se va a construir, sin una definición de hipótesis a testear, sin un plan de releases de alto nivel…

En el mundo real no podemos pedir a un inversor que financie una idea, que no sabes cuánto te va a costar, que no has probado con usuarios, que no estas seguro de qué equipo necesitas pidiendo, que simplemente confíe.

Los que estáis en contra de estas técnicas, ¿cómo y cuándo creáis la versión inicial del product backlog? ¿Cómo sabéis qué capacidades necesitas en tu equipo si no sabes lo que vais a construir? ¿Consideráis que estas técnicas podrían encajar en el sprint 1?

¡A la hoguera!

Siento ser antipopular, pero yo sí creo en un Sprint 0, con este o con cualquier otro nombre, que cubra la definición estratégica y visión de producto, siempre de alto nivel, antes de abordar el desarrollo de un producto digital.

Me gustaría tener feedback y estaré encantado de leer vuestras críticas, a la par que abierto a cualquier forma mejor de hacer las cosas, pero os aseguro que yo llevo usando muchos años estas y a mí me funcionan, que entiendo que al final es lo importante.