Ya había post en el blog de 2013, hace 7 años, hablando sobre el Sprint 0, pero, ciertamente, no traté el tema con la profundidad necesaria. Y hoy me he decidido a escribir sobre el «famoso» Sprint 0 a raíz del post de Los rebrotes del Lado Oscuro.
Como en casi todo en Agilidad, en este caso tampoco existe una definición «de libro» de qué es el Sprint 0 (lo podéis encontrar en inglés como Sprint Zero). De hecho, ni aparece en lo que vendría a ser el documento más oficial que hay sobre Scrum, la guía de Scrum (la buena).
Aún así, por lo general, se entiende que el Sprint 0 es un Sprint (en ocasiones son varios, el 0.1, el 0.2, etc., o uno muy largo, que no sé qué es peor) previo a los Sprint «buenos».
Entendiendo por «buenos» los Sprints que terminan con un incremento, es decir, «working software» (que es un producto con nueva funcionalidad, testeado y listo para su uso por parte de los usuarios, en pre o producción, para más info lee este post «Working software» es la principal medida del avance y este Mmm, pero… ¿Sabemos cómo debería terminar un Sprint o iteración Ágil?). De hecho, yo diría que los Sprint que ya se ha previsto que no terminen con Working Software… quizá no sean ni Sprint.
Ciertamente, hay que tener en cuenta que en el Universo hay muchas casuísticas, que no hay una verdad absoluta, que se evoluciona planteando dudas, etc., pero, de manera general… los Sprint 0 son Oscuros y sospechosos.
Fuente: Ron Jeffries en un debate en Twitter sobre el tema del Sprint 0.
Fuente: Mike Cohn en https://www.mountaingoatsoftware.com/blog/sprint-zero-a-good-idea-or-not
Fuente: Esta frase es de Ken Schwaber, co-creador de Scrum. La traducción sería algo así como que «Exactamente… el sprint 0 se ha convertido en una frase mal utilizada para describir la planificación que ocurre antes del primer sprint… y dado que la planificación crea artefactos que a menudo cambian, debe minimizarse antes del primer sprint, y luego ocurrir cada sprint en la reunión de revisión/planificación de sprint». En mi primer post sobre el Sprint 0, el de 2013, puse la referencia, originariamente es de el foro de Scrum en Yahoo… que ha desaparecido (por eso ahora prefiero dejar pantallazos de estas cosas, porque algunas luego desaparecen)
Las sospechas oscuras del Sprint 0
Son muchas las cosas raras, Oscuras, sospechas que hay detrás del uso del Sprint cero. Así que vamos con las más destacadas, teniendo presente que la principal cosa extraña viene de que después de un Sprint 0 los usuarios y Stakeholders no van a ver nada, porque son Sprints que se han planificado para terminan sin «working software». Y eso provoca que…
Se limita una idea de base Ágil… aprender rápido enfrentándose cuanto antes a la realidad
El, o los, Sprint 0 limitan la inspección adaptación, el empirismo, al no terminar con algo que pudiera tener valor para los usuarios y aprender, y adaptarse, enfrentándose a la realidad.
El cascada ataca de nuevo
Los Sprint 0 suelen ser una puerta al Lado Oscuro, al cascada, a la prescripción, al papeleo previo a la creación.
En los Sprint 0 se suelen colar desde largos Diseños, diseños UX muy extensos, planes de arquitectura, etc., sin olvidar hacer grandes backlogs de historias antes de empezar, lo que recuerda mucho a «fase de requisitos». Mucha teoría alejada de su puesta en el mundo real.
Todo esto huele demasiado a las fases de «papel» del siempre presente ciclo de vida en cascada.
Tiene pinta de que nos gestionamos por los peligrosos proyectos frente a equipos o productos
Independientemente del número que le pongamos, es cierto que siempre habrá un primer Sprint, y si sólo hay un primer Sprint en la vida de un equipo… el tema no va más allá. Ojo que usé antes la palabra equipo de manera muy intencionada.
Pero el verdadero problema viene de que en muchos sitios hay «muchos Sprint cero», se usa la idea de Sprint 0 en numerosas ocasiones y eso suele estar escondiendo un problema mayor… una orientación por proyectos (en vez una orientación a equipos o productos, que encaja mucho más con la naturaleza de una gestión Ágil), hay un Sprint 0 por inicio de proyecto.
Y esto si que es un problema, porque está poniendo en serio riesgo la orientación a equipos.
Y, ojo, sin ser lo ideal podéis hacer convivir el mundo proyecto con la gestión Ágil, equipos, pero la manera no es condicionando el trabajo de los equipos en función de proyectos. Esto ya lo he escrito en muchos post y hasta hay un vídeo muy antiguo que lo explica.
En este sentido, los Sprint 0 or pueden llevar a todos los problemas de los proyectos, todos esos problemas de los que queremos salir con una gestión, cultura, Ágil.
Si alguien se anima, estaría interesante un debate sobre esto. Abajo está la sección de comentarios para ello.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
En Scrum no existe fase de inicio definida. Se usa INCEPTION para definir las necesidades (a muy alto nivel, por eso dice Ken Schwaber que debe minimizarse (en tu imagen)). ¿Quizás alguien pueda estar llamando «sprint 0» a un inception?
Saludos desde Sevilla 🙂
Lo que es peor EY se invento el sprint z
O sprint en el que prepara la salida a producción, si hay problemas ellos se quedan en el sprint z y puede durar n semanas y cada que se hace una review el equipo sigue en el sprint z.
Lo que se inventa cada proveedor para enredar mas el tema y ser poco transparentes
En Agilidad no se debería utilizar nunca el término Sprint cero.
Solo se debería admitir el término Inception = «Fase de arranque del equipo».
El Inception se utilizaría para:
– Definir las reglas del equipo (DoR, DoD, Historia Base).
– Configurar entornos.
– Montar herramientas DevOps.
– Esbozar el roadmap del producto.
– Refinar las historias del primer sprint.
Me parece que el Sprint Cero o inception como otro lo identifican, siempre será necesario para alinear alcances, expectativas, necesidades y sobre todo asignar ese Timebox fijo para sincronizar los roles, PO, SM, Team, refinar las primeras historias de usuario antes de arrancar un Sprint, Acordar el Definition of Done y Definition of redy, entre muchas otras cosas necesarias técnicas como ambientes, usuarios, para arrancar un proyecto. Si bien no hay un working software como mencionas, si hay valor para el DevTeam como usuarios internos que reciben insumos (información) para transformar a un producto (Software).
Siento que una buena forma de ayudarnos a evitar el caos en el Sprint 0, es priorizar de los alcances del proyecto y trabajar sobre esa pequeña pieza del proyecto. Si se solicitan tener todas las historias antes de iniciar los sprints entonces caemos en la bonita cascada. Si bien mencionas que la agilidad es adaptación, apoyo que se tenga el enfoque a lo prioritario.