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.

Mi rol es diseñar proyectos de Internet y hacer que salgan bien. Es lo que me gusta hacer y a lo que me he dedicado los últimos 12 años. Siempre en busca de nuevos retos, me interesan temas tan diversos como Agile, Cloud o el diseño de productos digitales. Para hacer buenos productos, procuro siempre crear un marco de trabajo que permita a las personas mejorar y dar su mejor versión.

Ver toda la actividad de Jose Ignacio Herranz

6 comentarios

  1. Javier Martin De Agar Tirado dice:

    Buenas Nacho. La primera lectura casi me da algo, pero al leer el detalle creo que me alineo bastante. Precisamente Scrum en delivery va genial pero hay un gap sobre el antes. Al final el Sprint 0 depende de cómo se use puede ser positivo o negativo. Si dura 3 meses y esconde un análisis detallado es malo y si es corto y con una idea de sacar algo pronto. ¿Por qué no?

    Lo único que hay que tener cuidado con el argumento “funciona”. He visto clientes que esto del Sprint 0 les cuadra porque lo asocian al análisis de toda la vida. Sin embargo, van aprendiendo. Esta semana he estado en un banco que no goza de fama por Agile y he visto en dos reuniones como rechazaban la figura del Product Owner Proxy porque han aprendido que les va a dar más problemas.

    Es verdad que el tema del nombre lo pondría en duda, aún así, ojalá ese fuera el mayor de nuestros problemas. A mi me mola más el de Discovery Product por aquello de introducir ya el concepto de descubrimiento y el de producto (sobre proyecto).

    La parte de que si algo no aparece en la guía es malo no estoy de acuerdo. Eso es lo bueno! Al ser pequeña tu puedes llenar esos “gaps” con autoorganización. De todas maneras por encima de seguir una guía es mejor entender porqué esa guía es así y ahí tenemos mucho margen de mejora los agilistas.

    Un saludo.

    • Israel López dice:

      ” Al ser pequeña tu puedes llenar esos “gaps” con autoorganización.” > Cuidado…. Un equipo, en su autoorganización, puede decidir (y de hecho así ocurre en la realidad muchas veces) que “nuestras dailys las hacemos sólo los lunes” o “no necesitamos Scrum Masters”.

      Preguntas (con la respuesta que yo daría):

      1. ¿Es eso “legítimo” como ejercicio de autoorganización? > Sí

      2. ¿Esas decisiones rellenan los gaps de Scrum? > No. Al contrario, esas decisiones lo que te están diciendo es que Scrum no es válido para este equipo. Necesitan otra cosa. Decidido por el equipo.

      3. Si se llevan a cabo estas decisiones, ¿seguimos siendo Scrum? > No. Serás otra cosa, pero no Scrum, Y tampoco hace falta que seas Scrum.

      4. Si se llevan a cabo estas decisiones, ¿qué hace entonces el Scrum Master? > Irse. Aquí empiezan los problemas: la mayoría de organizaciones dice que “hay que tener Scrum Masters por cachavas”. Si un equipo considera que el rol NO aporta, entonces este framework NO aporta. El Scrum Master debería identificar los impedimentos que han llevado al equipo a decidir esto, y en un 80 % de los casos descubrirá que el impedimento raíz es el propio Scrum Master (ya sea el rol como tal o la persona).

      5. Si se llevan a cabo estas decisiones, ¿ya no somos Agile? > Eso va a depender del contexto. En principio no serás Scrum, pero eso no imposibilita que seas Agile.

      Digo todo esto porque no todo ejercicio de autoorganización queda dentro de los límites de Scrum, que, dicho sea de paso, es un framework muy restrictivo. Tanto que casi el 99 % de la gente lo confunde con un método.

      Los autores de la guía deberían reflexionar… y mucho.

      • Nacho Herranz dice:

        Gracias Israel, creo que todos estamos de acuerdo que la autoorganización no puede contradecir la guía (que para mi no es tan restrictiva).
        En cualquier caso, me gustaría saber tu opinión sobre contenido del post y las dudas que plantea.
        Un saludo

    • Nacho Herranz dice:

      Gracias Javi por el comentario!

  2. Un cóctel explosivo dice:

    El sprint 0 es y debe ser un ejercicio de reflexión conjunta. Conjunta entre el cliente y el proveedor. Y para los más escépticos que lo ven como una preventa encubierta, decirles que más caro aún es poner de acuerdo a un montón de usuarios internos de la empresa sin un método para hacerlo y encorsetados en la cultura propia de la compañía. La empresa se ahorrará el coste de toda esa gente desperdigada montando una RFP para la cual necesitan mucho tiempo personal, ergo coste, y al final el resultado pretende ser una guia cerrada para un proyecto. Al final en la mayoría de los casos el coste de hacer ese RFP es mucho mayor que un sprint 0, y el producto que sale de un RFP incompleto o erróneo es todavía más caro, si cabe. Por eso el sprint 0 debería ser un “must” y no un “nice to have”.

    • Nacho Herranz dice:

      Gracias!
      Está claro que si hay un escenario de scrum donde hay un cliente y un proveedor complica las cosas sobre un escenario de empresa de producto, y eso es un factor adicional.

Escribe un comentario