¿Qué hay que tener en cuenta antes del primer Sprint?

Si conoces las metodologías Agile en general y Scrum en particular (y, sobre todo, si la practicas) sé que me dirás que en Scrum no se reconoce la existencia de un Sprint Cero.

Este post no es para contarte qué es un Sprint ni para aclarar lo que implica o no el término “time-box”, sino para darle un lugar a este espacio de tiempo que se necesita en el arranque del proyecto.

Podemos llamarlo como queramos, pero el Sprint Cero es un bien necesario para no llevarnos sorpresas a mitad de partido… o, incluso, al final.

Mi experiencia

Llevo casi quince años gestionando proyectos, antes bajo metodología waterfall, ahora soy agilista (o lo intento) y lo hago desde Scrum.

Cuando la humanidad dio ese gran paso hacia la verdadera entrega de valor, olvidando los interminables documentos del Project Management Plan impresos en A3, se olvidaron de asegurar mediante un time-box este espacio de tiempo para conocer el proyecto, el cliente y el equipo, hacer las primeras tomas de contacto, ponernos cara y empezar a hacernos los unos a los otros.

Establecer las reglas del juego, las necesidades, alimentar el backlog, dar las primeras estimaciones… Todo esto es tan importante como entregar un mínimo producto viable (MVP). De hecho, es imprescindible para que el resultado del MVP sea el esperado por todas las partes.

Porque a veces, solo a veces, ocurre que en esa primera toma de contacto una de las dos partes se da cuenta de que la otra parte no le puede ofrecer lo que esperaba y evitamos que esta conclusión sea tangible cuando ya esté la mitad del pescado vendido.

Bien es cierto que no es lo mismo trabajar en consultoría que si lo haces en cliente final. Los consultores damos servicio a clientes finales que tienen un producto que vender y que, de alguna manera, se convierte también en nuestro producto.

Pero este servicio tiene fecha fin, así que, por regla general, en consultoría tendemos más a solicitar estos espacios de tiempo para tratar de estar alineados y de asegurar el entregable con mayor fiabilidad. En el caso del cliente final, que tiene la información más directa, más rápida y más segura, tiende a pensar que estos espacios en los que el equipo piensa, planifica, acuerda y se informa, no son necesarios.

Esta fase inicial del proyecto nos va a proporcionar una serie de ventajas que nos permitirán arrancar el primer Sprint con una mayor garantía de éxito frente a desarrollar la genial idea de tirarnos a la piscina de ese primer Sprint sin conocer al detalle la profundidad de aquello a lo que nos enfrentamos:

1. Conocerás a tu cliente

Y, para ello, sacarás tiempo de donde no lo haya para hacer reuniones de arranque del proyecto que permitirán al equipo exponer lo que se ha entendido del alcance acordado (o conocido como acta de constitución) y las conclusiones extraídas de esta fase inicial, donde muchas veces uno entiende solo lo que quiere entender (o lo que puede).

De estas reuniones, se extraerán dudas que, posiblemente (o no) cambien el alcance del producto e, incluso, puedan aumentar su valor porque, sinceramente, ni siquiera se habían pensado antes. ¿Y qué mejor entrega de valor que regalarle valor a tu propio producto?

2. Conocerás al equipo y empezarás a estrechar lazos.

Y no hablo de tener “un buen equipo” en abstracto, hablo de crear esa sensación de ir a una, de remar en la misma dirección. En los primeros días también empiezas a ver, y a verte: fortalezas, manías, estilos y cómo reacciona cada uno cuando hay prisa o incertidumbre.

Ese conocimiento vale oro, porque te permite adelantarte y gestionar riesgos y dependencias que al principio ni se ven: malentendidos, expectativas distintas, silencios que se interpretan mal o decisiones que nadie se atreve a tomar si no está claro el marco.

3. Harás que el equipo y el cliente se conozcan.

En esas primeras reuniones de dudas y aclaraciones (de negocio, técnicas y de “esto cómo lo hacemos”) se construye el punto de partida real. Y si en este periodo nos ganamos la confianza mutuamente, luego todo fluye mejor: cuando el equipo proponga algo que no estaba en el guión, el cliente al menos lo escuchará, y cuando negocio cambie prioridades a mitad de camino, el equipo lo gestionará como lo que es: un ajuste incómodo… no un drama imposible.

4. Entre todos estableceremos las reglas del juego

Ya son la mitad del éxito del entregable: duración de los sprints, hora de la daily, agendas de planning/review/retro, cómo vamos a estimar y cómo vamos a escribir las historias. También dejamos encarrilado lo básico de “la casa”: repositorios, accesos, herramientas (¿Jira sí o Jira no?) y unas primeras decisiones técnicas para no improvisar. Y con todo eso, dibujamos un roadmap inicial y ligero para saber por dónde empezamos y qué hitos vemos en el horizonte.

5. El Product Owner puede salir de este arranque con una primera versión del Product Backlog

Ojo, primera versión, pero suficiente para poner en pie un MVP que sirva de raíz para todo lo demás. El backlog, como dicta Scrum, irá evolucionando durante toda la vida del producto pero, si dejamos claras las primeras épicas, historias y tareas que ya conocemos, arrancamos con un punto de partida sólido para empezar a construir (y aprender) desde el Sprint 1.

6. De cada una de las reuniones, impresiones, toma de ideas, decisiones que se acuerden podrá realizarse una gestión de riesgos iniciales

Esto nos permitirá montar una primera foto sobre los posibles escenarios que el equipo se encontrará en su quehacer y tratar de eliminarlos o aliviarlos antes de que se conviertan en un problema.

Todo esto asentará las bases del proyecto y desde aquí se iniciará el camino que nos conducirá, ya no solo al éxito en cada uno de los entregables, sino al buen hacer de las cosas, siempre, siempre, consensuadas.

En la vida real…

Voy a contaros uno de los casos que he vivido que me terminó de confirmar todo esto. Me asignaron un proyecto para un cliente con el que se había trabajado anteriormente y con el que, en teoría, nada debería sorprendernos.

Proyecto corto, con urgencia: el cliente quería un entregable a principios de año y a nosotros nos lo pasaron a mediados de noviembre. Diciembre por medio, con puentes y vacaciones ya cerradas… así que el margen era el que era.

Viendo un poco el futuro, encontramos que era necesario descubrirnos para poder apuntalar el producto e ir construyendo lo máximo posible a la mayor velocidad permitida y entregar, con la previsión que nos daban esas fechas establecidas, un MVP de calidad con la mayor cantidad posible que sirviera para hacerlo crecer en las proporciones adecuadas.

Fueron 2 semanas de conocernos: 10 días hábiles donde, a partir del documento de inicio del proyecto, trabajamos codo con codo con el cliente para resolver todas las dudas que nos fueron surgiendo de los requisitos, extrajimos todas las Historias de Usuario necesarias para llevarlo a cabo, las estimaciones de cada una de ellas y, por lo tanto, de todo el proyecto.

Ante la inviabilidad de poder entregar todo lo deseable en la fecha pretendida por el cliente, la idea era ofrecer una propuesta de MVP que se alimentara en entregas de valor cada dos semanas con funcionalidades nuevas e hitos de despliegues a entornos superiores hasta completar todo lo detallado en el documento de requisitos.

Lo iniciamos con muchas ganas, queríamos hacerlo bien. Comenzamos las reuniones con cliente, le explicamos que los time-box definidos para cada Sprint serían de 2 semanas, utilizamos todos los huecos posibles para solicitar más información sobre temas inconclusos, resolver dudas, definir en qué forma podían ser más efectivas algunas funcionalidades y desarrollar un roadmap con todos los hitos definidos (y sus entregas de valor) hasta completar el proyecto.

La primera semana todo parecía ir sobre ruedas: cliente entregado, equipo ilusionado… ¿qué podía salir mal? A la segunda semana, el cliente empezó a no asistir, se volvió difuso en sus respuestas y dejó de contestar.

Y, antes de que pudiéramos cerrar el roadmap y propuesta de entregables, decidió cancelar el proyecto. ¿Fracaso? Para mí, al revés: fue la señal temprana que nos ahorró semanas de presión y desgaste. Sin ese arranque, lo habríamos descubierto mucho más tarde, con trabajo ya hecho, el equipo agotado y el cliente frustrado.

¿Qué conclusión sacamos de este ejercicio?

Con todo lo hablado, ¿se equivocó Scrum por no “inventarse” un Sprint de arranque, Sprint inicial o Sprint Cero? Si nos ponemos estrictos, desde la ortodoxia Scrum no tendría mucho sentido: un Sprint es un Sprint, y punto.

Pero la vida real, y más en consultoría, no siempre arranca con las condiciones ideales y ahí es donde este timebox de descubrimiento se vuelve un aliado.
En los tiempos que corren, con la sed de adaptabilidad que cada vez demandan más los proyectos y los clientes, no está de más pasar con el cliente por esa fase de descubrimiento, que existe desde los orígenes de la gestión de proyectos.

¿Qué hubiera pasado con ese proyecto en el que en la segunda semana el cliente decidió retirarse? ¿Nos habríamos dado cuenta en tan poco tiempo, de un lado o de otro, que no estábamos en la misma línea de tiempo o en la misma perspectiva?

Posiblemente, habríamos vivido un mes y medio de presión absoluta para que se llegara a algo a lo que no se podía llegar, equipo estresado, cliente frustrado, metodología en entredicho, calidad en entredicho también… ya por evitar eso, creo que es realmente necesario pasar por esta fase.

Durante años, la gestión de proyectos “clásica” ya contemplaba algo parecido: antes de ejecutar, había que iniciar y planificar, entender el contexto, alinear expectativas y dibujar una hoja de ruta.

Llámalo como quieras, pero la necesidad de conocer al cliente, el problema y las condiciones del proyecto no es nueva; lo que ha cambiado es cómo lo hacemos.

La diferencia hoy es que no buscamos una planificación exhaustiva al estilo waterfall, sino un arranque ligero y adaptativo: empatizar con los objetivos del cliente y del equipo, clarificar necesidades, hacer visibles supuestos y restricciones, identificar riesgos iniciales y salir con una primera visión de trabajo que nos permita empezar a entregar con sentido.

En resumen: pensar lo justo al principio para no pagar después por no haber pensado nada.

Pensemos que todo en la vida es adaptarse. En Paradigma lo hemos llevar a la práctica en cómo trabajamos: con Polaris, nuestro marco de trabajo, buscamos mantener la esencia ágil en proyectos, productos y servicios, pero con suficiente flexibilidad como para adaptarnos al ciclo de vida de cada cliente, buscando la excelencia de los entregables, donde:

• Mantenemos la esencia Agile pero la llevamos a otro nivel, a través de la regla 80/20, en la que entendemos que el 80% de la gestión del proyecto es la actitud del equipo, mientras que el 20% es la práctica, las herramientas con las que trabajamos y la experiencia que tenemos.
• El Scrum Master evoluciona hacia un rol de Agile Delivery Leader, asegurando coordinación, foco en valor y visión clara de lo que estamos construyendo.
• Nos guiamos a través del True North, esa brújula compartida, visible para todos, que nos ayuda a resolver dudas sin caer en debates y a mantener el rumbo cuando el día a día aprieta.
• Trabajamos dentro de un marco 100 % adaptativo con fases y objetivos claros en cada una de ellas: fase de pre-proyecto, fase de arranque (o nuestro Sprint Cero), distintas iteraciones y fase de cierre.
• Ponemos foco a los riesgos en la forma en que se merecen, de cara a tenerlos bajo control desde el primer minuto de vida del proyecto / producto o servicio, yendo siempre por delante en cada una de las fases del proyecto.
• Buscamos un modo productivo, empezando por hacer lo necesario, luego haciendo lo posible y terminando, por qué no, consiguiendo lo imposible. No solo buscamos la productividad dentro del proyecto, creemos que la productividad tiene que empezar por uno mismo.
• Nos basamos en métricas para tomar decisiones con un catálogo en el que seleccionar lo que mejor se adapte a tu cliente, a tu proyecto, a tu equipo y a tu manera de gestionar.
• La calidad no se negocia, ya que nos aseguramos de que el producto sea superior al de la competencia, poniendo la tecnología al servicio del mismo y entendiendo la entrega temprana y continua como una garantía de éxito.
• Entendemos que el desarrollo de software no consiste solamente en entregar funcionalidades, sino en resolver problemas de negocio y por ello, nuestro enfoque siempre va a ir alineado con el del cliente.
• La experiencia del equipo es un must, el equipo es lo primero y la relación con el cliente debe ser cuidada y mimada. Porque sabemos que tenemos que entendernos para garantizar el éxito. Y nos funciona.

Y cierro con algo sencillo: la vida nos da la posibilidad de elegir, también cuando gestionamos proyectos y cuando dejamos nuestro producto en manos de otros.

Nada garantiza el éxito al 100%, pero si podemos elegir, yo lo tengo claro: mejor conocernos antes de sacar conclusiones precipitadas, mejor empatizar antes de llegar a reproches.

Mejor descubrirnos a tiempo que acabar con una lista de “yo te dije” que no lleva a ningún sitio… y mucho menos al éxito del producto.