Sprint 0, clave en la gestión de proyectos ágiles.

Por un tiempo, la tecnología marcó la diferencia y aquel producto o servicio que ofrecía más funcionalidades era el que más posibilidades tenía de dominar un mercado. Pero ya no es así: vivimos en la “era del usuario” y ya no se nos pide tal o cual funcionalidad, sino que se espera “la mejor experiencia”. Se nos pide (casi exige) que, sin dejar de ser útil, ese producto sea, además, sencillo, agradable...

Este nuevo enfoque es algo que ya está interiorizado en startups y empresas puramente digitales. Buen ejemplo de ello son Uber y Airbnb. El conjunto, la experiencia… que Uber y Airbnb dan a sus usuarios les hace sentirse VIP y eso es lo que les permite marcar la diferencia con el resto de alternativas… No es la mera “funcionalidad”.

Uno de los problemas con los que nos encontramos es que la gran mayoría de las organizaciones no están estructuradas como Airbnb o Uber, sino que se conforman alrededor de áreas de especialización. Cada una se encarga de una parte del proceso productivo y no están enfocadas “al usuario”.

Así es que, cada vez que surge una nueva iniciativa, aquellos departamentos “transversales”, los que deben dar soporte a la iniciativa, nos pedirán a cambio que les informemos de cuánto va a costar la implantación, en qué fecha se saldrá a producción y cuánto espacio en la base de datos vamos a necesitar, a la vez que nos pasan los formularios a rellenar con esa información.

La forma habitual de implantar nuevas iniciativas de negocio pasa por la elaboración, con mucho trabajo y tras un análisis detallado, de una RFP. Y sin embargo, esa RFP no recoge (no puede recoger) más que la visión personal de aquel o aquellos que la elaboraron. No tiene en cuenta la opinión (cambiante) del usuario al que va destinada. En su lugar, se detallan una serie de requisitos inmutables con una planificación (prefijada) que se adapta perfectamente al calendario presupuestario de la organización, pero no tanto a los cambios en el mercado durante la ejecución del mismo.

Y, sin embargo, sabemos que las iniciativas exitosas de la competencia no se articulan así, sino que lo hacen a partir de una idea, que se implanta rápidamente en una fase embrionaria para ir dirigiendo su crecimiento hacia aquellas áreas que más ROI (en un sentido amplio) ofrecen. Y eso no se hace con “Planes anuales”.

¿Cómo puedo definir lo indefinido?

Está claro que, de los tres parámetros que se estudian en la gestión de proyectos clásica (Precio, Tiempo y Alcance) el más importante es el Alcance. Es lo que motiva la realización del proyecto pero también lo que, intuitivamente, determinará los otros dos parámetros.

Y aunque está claro que no es posible determinar el alcance a priori, sino tras escuchar a los usuarios en las sucesivas entregas, la tozuda realidad es que muchas organizaciones aún siguen necesitando poder planificar sus recursos a medio y largo plazo (presupuestarios, humanos y materiales).

Además, aunque de manera secundaria, otros factores que se quieren conocer son la infraestructura necesaria para ejecutar el proyecto, los equipos de mantenimiento que se verán afectados, la arquitectura tecnológica final... y los sistemas con los que es necesario realizar integraciones.

¿Es mucho pedir?

¿Cómo deshacemos este Nudo Gordiano?

La respuesta tradicional de los proveedores (y de los clientes) es ignorar este hecho y lanzarse todos a la piscina del “proyecto cerrado” sin fijarse en si hay agua o no, confiándolo todo a la suerte y a la capacidad de negociación posterior entre cliente y proveedor para poder cerrar ese proyecto “de la mejor manera posible”. Ese es el problema que preocupa cuando se enfocan así los proyectos… tanto el cliente como el proveedor se centran en cómo cerrar el contrato del proyecto y no cómo poder dar el máximo valor a los usuarios. ¿Me equivoco?

En Paradigma sabemos que en este tipo de proyectos no es posible cumplir las expectativas y, cuando aparentan hacerlo, el (olvidado) cuarto parámetro, la CALIDAD, es el que sufre.

Por otro lado, los métodos ágiles requieren, para comenzar el desarrollo un “Product Backlog” que el cliente no suele estar capacitado para elaborar por sí mismo: el “Product Backlog” no define un alcance cerrado ya que no es un documento de análisis tradicional. Sin embargo, es la lista de “funcionalidades que nos gustaría incorporar” al proyecto en el futuro y es necesario tenerlo identificado antes de comenzar con el desarrollo.

Parece que seguimos teniendo un obstáculo insalvable: seguimos sin poder ofrecer respuesta al QUÉ, al CÓMO y al CUÁNTO antes de comenzar el proyecto.

La propuesta de Paradigma: el Sprint 0

El primer paso, previo a la ejecución del Sprint 0 (luego veremos en qué consiste) es identificar con el cliente en qué punto del proceso de definición se halla la idea, para identificar en qué áreas concretas y con qué herramientas, podemos ayudar.

El Sprint 0 es un trabajo conjunto, en el que Paradigma y el cliente (en el sentido amplio) exploran todos los aspectos del proyecto que se va a emprender, por supuesto, también de forma incremental e iterativa.

En un plazo corto (entre 3 y 5 semanas) se obtiene, como resultado, una definición de alcance mucho más detallada de la que podría producir el cliente de manera autónoma. El Product Backlog estimado y priorizado, en el que se han recogido, mediante diversas técnicas las influencias de usuarios y stakeholders (técnicos y arquitecturales, presupuestarios, dependencias de otros proyectos, análisis de la competencia, etc.)

El Sprint 0 permite enfocar el proyecto

Se supone que el alcance del proyecto debe venir guiado por la opinión de los usuarios, pero no es posible obtener ese feedback si no hay un producto ya “liberado”. El Sprint 0 nos permite identificar los objetivos del proyecto y reducir la incertidumbre respecto al alcance (en forma de Product Backlog) y respecto al enfoque tecnológico: así se clarifican las expectativas dentro de la organización.

La definición rápida es que “el Sprint 0 produce todo lo necesario para poder comenzar a trabajar con un enfoque ágil”. Esto incluye, sobre todo, un Product Backlog en el que se plasma la visión que se ha identificado conjuntamente.

Comenzamos por identificar cuál es el estado de definición del alcance y, en función de ese estado, definimos qué herramientas y dinámicas se van a aplicar en ese Sprint 0. El objetivo último es obtener una visión clara de:

• Qué queremos implementar, en forma de Product Backlog y prototipos.
• Cómo lo queremos implementar, en forma de Arquitectura técnica.
• Y cuánto (tiempo y dinero) aproximadamente nos va a costar llegar a cada una de las posibles fases principales de la implementación del proyecto.

Dentro de ese Product Backlog es habitual encontrar clasificadas las Épicas en estos tres grupos: MVP (Producto Mínimo Viable), MMP (Producto Mínimo Comercializable) y Funcionalidades futuras. Evidentemente, las Épicas de los dos primeros grupos se habrán descompuesto en Historias de Usuario y se habrá estimado su complejidad lo que ha permitido priorizarlas, apoyadas además por Prototipos y Propuesta Gráfica (desde el punto de vista de Usabilidad) y por una Arquitectura propuesta e, incluso, Pruebas de Concepto de aquellos elementos tecnológicos más innovadores.

Pero, dado que en este punto ya se tiene una orientación de alcance (MVP y MMP) lo que permite a “Negocio” obtener una visión muy aproximada de cuál será el resultado del proyecto, también es posible minimizar las inquietudes tanto de la Gerencia (orientación en cuanto a Costes y Plazos), como de los equipos de Tecnología (cuándo se estima que deberán estar disponibles los entornos y equipos que sustenten el nuevo producto, qué personas formarán el equipo, que recursos harán falta, qué nuevos productos o frameworks se introducen en el ecosistema a mantener, etc).

En este punto, tanto los responsables del negocio, como el equipo del proyecto han tenido tiempo de trabajar juntos en un objetivo común, construir un lenguaje y unas herramientas de colaboración que facilitan la comunicación y sirven para cimentar una relación de confianza entre quién ha de decidir finalmente qué y con qué prioridad se debe implementar (el Product Owner) y quién está capacitado para decidir cómo se implementa (el equipo Scrum) el producto.

Es sólo en este momento cuando estamos preparados para arrancar el proyecto desde una base sólida.