El otro día asistí a una charla sobre cómo una empresa realizaba desarrollo ágil. Comentaron que ellos hacían desarrollo de producto (perfecto), y que trataban de entregar valor. Para trabajar con un cliente, hacían un Sprint 0, desarrollaban un plan de releases y así le daban al cliente visibilidad sobre fechas de entrega ¿Es esto el concepto de entregar valor y desarrollar producto?
Vamos a analizar el Sprint 0, una de las prácticas fake-agile que más problemas acaban generando en los equipos, debido a que siguen el mismo paradigma de “planificación y control”.
En Scrum no existe el Sprint 0
Hace tiempo, impartía un curso sobre Scrum Master a una seria de compañeros. En el cuestionario que les había pasado, habíamos preguntado lo siguiente sobre el Sprint 0: ¿Qué debe hacer el Scrum Master en el Sprint 0? Rápidamente un compañero se “alteró”: “has dicho que no hay Sprint 0, esta pregunta está mal”. Este compañero no había leído que una de las respuestas, la correcta, ponía que NO existe este concepto en Scrum.
Y es así, el Sprint 0 no es un elemento de Scrum. Es más, hay mucha bibliografía hablando en contra de él, por ser una práctica más prescriptiva (mentalidad waterfall) que adaptativa (mentalidad agile).
El principal motivo por el que el Sprint 0 no existe, es que, un Sprint es un periodo de tiempo en el que debe existir una entrega de valor. Entregar valor es clave en Scrum, nos permite saber si vamos por el buen camino, si estamos acertando o tenemos que pivotar para llevar el producto por otro camino. Sin embargo, el Sprint 0 es preparatorio, lo usamos para que podamos “sprintar con garantías”. En general, el resultado de un Sprint 0 es documentación o promesas al cliente o una arquitectura montada sin ninguna funcionalidad. ¿Cómo sabemos entonces si estamos en el camino adecuado?
Las personas que están a favor te dirán que gracias al Sprint 0, arrancamos con garantías de saber lo que quiere el usuario. Esto tiene sentido si no fuera porque las necesidades cambian constantemente y, solo cuando un usuario realmente incorpora el producto a su vida, entiende la mejora que ello produce. Por ejemplo, imaginemos que eres el inventor de la Thermomix, un robot de cocina muy famoso. Si le preguntas al usuario si quiere un “robot capaz de cocinar por él”, quizás no dude en afirmar que sería una excelente idea. Lo que no se imagina el usuario es el tamaño que va a tener ni que las cantidades que cocina no son muy buenas para personas que viven solas o familias grandes. Además, los platos más elaborados siguen requiriendo de mucha interacción humana. Todo esto es algo que descubres una vez que tienes el robot en tu casa y lo puedes usar. ¡El valor se descubre cuando lo tiene el usuario delante y puede valorarlo!
Sprint 0, demasiado temprano para hablar de fechas
El mundo de las fechas lo hemos tratado varias veces en este blog. Está claro que las fechas en muchas empresas son necesarias para poder arrancar un equipo. Bajo la cultura de control, no queremos empezar algo sin saber el coste final: el conocerlo nos da seguridad. Además, figuras como las del Jefe de Proyecto que se asegura de que ese plan inicial se cumpla, de manera que el coste quede controlado.
Sin embargo, en un mundo donde los requisitos cambian, crear la sensación de que alcanzar una fecha con un determinado alcance es un éxito, es la primera causa de fracaso del desarrollo software en las empresas.
Por ejemplo, muchas empresas utilizan el inception como técnica para arrancar un nuevo equipo en el Sprint 0. Existen dos tipos de inception, uno lo propone Rasmusson en su libro Agile Samurai y el otro es de Paulo Caroli, llamado Lean Inception. En ambos casos, se hacen una serie de dinámicas en las que tratamos de descubrir nuestro producto. Sin embargo, fue Rasmusson el que pintó este dibujo en su propuesta:
[dibujo del inception]
Rasmusson trataba de decirnos que, en momentos tempranos, no hagas promesas, la desviación es muy elevada y generarás expectativas difíciles de cumplir.
El inception puede ser útil para entender lo que vamos a construir, saber qué equipo vamos a componer y estudiar las dimensiones de lo que haremos. Sin embargo, utilizarlo como técnica “molona” para decirle a un cliente una fecha de entrega, es seguir nadando en el paradigma tradicional de “predecir y controlar lo que hemos predicho”.
Lean Inception, una alternativa viable
Hace meses tuve la oportunidad de descubrir la alternativa de Paulo Caroli: Lean Inception. Su función es clara, poner foco en un Producto Mínimo Viable que nos diga si nuestro producto tiene sentido. Lean Inception se compone de una serie de dinámicas que se superponen para clarificar el alcance, objetivos, usuarios y camino viables de construcción para nuestro producto.
Es cierto que, en la parte final, existe una sección para fechas, a mi es la que menos interesante me ha parecido. Un Sprint 0 puede servir para conocernos, pero no para prometer cosas, es muy temprano. ¿Le prometemos amor eterno a nuestra pareja en la primera cita?
Es normal que las empresas que están implantando Agile necesiten un poco de tiempo antes de empezar a entregar. Este tiempo debe ser el más corto posible y siempre debe ser entendido como desperdicio: “si mi competencia no lo necesita, irá más rápido”. Por tanto, debe ser visto como un mal necesario mientras nos encontremos en una etapa de transición (lo más breve posible) de un modelo tradicional a uno Agile de entrega contínua de valor.
Sprint 0: Un waterfall vitaminado
Tal y como reflexionada Robert Gallen en su libro Product Ownership, el Sprint 0 no es necesario cuando tenemos equipos con experiencia en Scrum, la arquitectura es conocida, el alcance está claro… Dado que esto ocurre pocas veces, es normal hacer uso del Sprint 0. También añadía Gallen que es importante que no dure más allá de dos semanas.
Por tanto, el Sprint 0 como elemento de arranque es válido, siempre que su resultado no recoja expectativas de fechas ni de alcances cerrados. Ese es el gran fallo de este tipo de técnicas. El motivo es obvio: tras habernos gastado un dinero importante en varias semanas de estudio, lo mínimo que nuestro cliente espera es que acertemos, si no ¿para qué lo hacemos?
Ahora bien, en muchas empresas el Sprint 0 es un waterfall 2.0, donde ya no existe la figura del analista clásico que tomaba requisitos, el arquitecto que diseñaba los sistemas y el equipo que implantaba. Todo eso lo sustituimos por postits y dinámicas de co-creación que, siendo más efectivas, nos llevan al mismo punto: prometer una fecha demasiado pronto. Después, a este Sprint 0, le añadimos un Sprint de Diseño, donde entregamos el diseño visual final, varios Sprints de Desarrollo, acompañados de un Sprint de Pruebas e Integración y finalmente un Sprint de Subida. Tras la entrega, necesitamos Sprints de Mantenimiento para estabilizar el código. ¡Bienvenidos a Waterfall Vitaminado!
Si queremos cambiar el paradigma del desarrollo software, no podemos apoyarnos en herramientas con el mismo mindset del que partimos, aunque mejoren las herramientas actuales. Hay que pensar diferente si queremos resultados diferentes.
Y tú, ¿utilizas el Sprint 0?
¡Excelente artículo! Utilizo Sprint 0 para que se escriban las primeras historias de usuario; me ha pasado que quiero comenzar el sprint 0 y no tengo las historias o tengo muy pocas para poder estimar. Siempre lo hago muy corto; una o dos semanas y jamás prometo nada de fechas o cosas así