¿Qué es el sprint 0?

Actualmente hay muchas empresas que implementan Scrum sobre proyectos que han arrancado con metodología tradicional, y debido a que no funciona en escenarios cambiantes, han decidido probar a "salvar" el proyecto con Scrum. Después, cuando Scrum ha funcionado, es cuando las empresas experimentan con la introducción de Scrum desde la propia preparación y planificación del proyecto, y es entonces, en la fase de construcción, cuando suelen introducir el sprint 0. Resaltar que el sprint 0 no es un artefacto de Scrum, es un práctica que en alguna empresas ha funcionado.

El sprint 0 es un primer sprint que no aporta valor de negocio, cuyo objetivo no es producir una parte del producto "tangible" y funcional, sino construir una parte de la arquitectura ágil básica para que los incrementos de futuros sprints puedan añadir valor de forma eficiente al producto. Puede incluir tareas de análisis y/o diseño previos, así como algún trabajo de investigación y selección de herramientas, identificación de políticas de calidad y seguridad y necesidades de formación.

El sprint 0 es un sprint especial diferente a los demás

Se inician los flujos de forma solapada, como son el análisis y el diseño, para refinar y preparar las primeras historias de usuario. Hay que ir con cuidado para no preparar demasiadas historias como si de un análisis tradicional se tratara. Esta tarea inicia la pila de producto, pero el mantenimiento de esta y su refinamiento continuo deben de ser vivos a lo largo de todo el proyecto.

Walking Skeleton, cortesía de i<3vector

El diseño y la arquitectura que se creen en este sprint 0 deben de ser minimalistas para que haya cabida de diseño y arquitectura emergentes en futuros sprints. Es interesante incluir una prueba de concepto, un "walking skeleton", que conecta todas las tecnologías involucradas en el proyecto para garantizar su integración. Con esta práctica traemos todos los riesgos tecnológicos a principio del proyecto y nos evitamos sorpresas a mitad del mismo. No debe de confundirse una prueba de concepto con una maqueta, las maquetas dan idea del aspecto de como será un producto y de como estará interconectado, el walking skeleton no muestra el producto, sólo garantiza la interconexión y funcionamiento de las tecnologías implicadas.

La duración del sprint 0 suele ser más larga y su velocidad más baja que la de los sprints posteriores, y el sprint está vigente mientras no se finalicen todas sus tareas.

En su post "Sprint cero: ¿que necesitamos?", José Vázquez Sánchez, hace el siguiente inventario de las cuestiones que se consideran pueden ser necesarias para el llamado sprint 0:

• Visión del producto: coincidimos todos en ello como una de las cosas más importantes. Visión de lo que hay que hacer y además que esté compartida (y todos los involucrados sepan cual es su lugar y como aportan al proyecto). Saber qué es y que no es el producto.
• Equipo: formado, motivado y con actitud.
• Lista de funcionalidades a alto nivel: epics.
• Plan de trabajo inicial: plan de releases y Road Map. Tiempo aproximado para que el producto tenga sentido.
• Definida la release 1.
• Prioridades del cliente.
• Intervinientes y contactos: quien tiene algo que hacer y qué.
• Fases de aceptación: proceso para conseguirlo, acuerdos de trabajo. Definición de hecho (Done).
• Expectativas de Calidad.
• Detección de dependencias.
• Restricciones o limitaciones: de seguridad, de rendimiento, de disponibilidad, de escalabilidad, de entorno, …
• Tamaño objetivo de la base de clientes esperada.
• Primera versión de la pila de producto priorizada: según valor de negocio.
• Pila de riesgos del proyecto: se pueden intercalar con la pila de producto, para dar respuesta temprana a cualquier riesgo.
• Métricas que se seguirán en el proyecto: Ojo con lo que se mide. Que no cueste mucho esfuerzo. Seguir tendencias, no datos.
• Entorno tecnológico disponible.
• Spike de arquitectura.

¿Puede una misma persona tener los roles de Propietario del Producto y Scrum Master a la vez?

Aunque no sea recomendable, si no hubiera posibilidad de un Scrum Master dedicado, yo recomendaría buscar primero un rol en el equipo, luego advertir que la Scrum Guide lo desaconseja firmemente y no es buena idea que una sola persona haga de Product Owner y Scrum Master a la vez. Es un arte nada desdeñable, hay que asegurarse en todo momento de aislar los dos modos de pensar y actuar en uno y otro modo según el rol desempeñado.

Las diferencias de foco principales son:

• Mentalidad: externos (interesados) versus internos (equipo)
• Enfoque: qué/cuándo versus cómo
• Principales excepciones: los cambios de alcance versus impedimentos generales

Ambos roles a la vez bajo un mismo gorro

Los dos roles son contrapuestos por definición, el Scrum Master vela para que Scrum se aplique según el modelo, se asegura de que el equipo esté motivado y focalizado en sus tareas y de que nadie interfiera en el sprint. El Propietario del Producto tiende a hacer exactamente lo contrario, dado que su labor consiste en absorber el cambio que se produce en el negocio y mantener una pila de producto cambiante, este está tentado por naturaleza a interrumpir e interferir en el equipo. Desempeñado ambos roles es crucial resistir firmemente esta tentación.

Desempeñar dos roles conlleva cierta jerarquía implícita y no es fácil encontrar un equilibrio entre ambos roles, si prepondera el Scrum Master y no hay nadie estirando hacia el negocio, el resultado puede ser un enfoque más tecnológico de lo debido o marcado por el ritmo del equipo. Si prepondera el Propietario del Producto puede ocurrir que este vaya demasiado lejos y vea en ello una oportunidad para tomar el control directo de su propio equipo de desarrollo.

Para entender los diferentes objetivos de ambos roles, Rafael, uno de mis profesores una vez dijo:

• El Scrum Master quiere el mejor equipo
• El Product Owner quiere el mejor producto

La actividad crítica para quién desempeña ambos roles es la reunión de planificación de sprint, ya que estará a caballo entre negocio y equipo frente a un equipo unilateral. Mi consejo sería hacerse acompañar por un tercero, una persona de negocio que represente de forma unilateral al negocio y de esta forma apoye y permita al Propietario del Producto/Scrum Master estar en ambos lados. Como en la reunión de scrum diario el rol es exclusivamente de Scrum Master no hay conflicto entre los dos roles, lo que si aconsejaría, funciones de Scrum Master aparte, es apartarse lo máximo del equipo durante el sprint. En la reunión de revisión de sprint no hay conflicto, ya que, aunque pudiera haber imparcialidad, no puede haber influencia retroactiva.

Uno de los beneficios al pasar por esta experiencia es que de esta manera el Propietario del Producto se acerca al equipo, obtiene una visión desde dentro del equipo técnico y eso redunda en aprendizaje por ambas partes y una integración más fuerte.

Añadir que si depositamos el rol del Scrum Master en un miembro del equipo también puede haber conflictos, pero de un menor grado. El reto está en no perder el foco, al estar involucrado en el proyecto puede verse condicionado en sus decisiones como Scrum Master. Ha velar por la forma en que se trabaja y que el equipo sea sano y productivo a la vez que formar parte del equipo e intervenir directamente en decisiones sobre el producto. 

En caso de varios miembros interesados en el rol puede hacerse un sistema de rotación, es una buena práctica ya que así los interesados viven Scrum de una forma más profunda, lo que por ende revierte en mejora continua. También pudiera ser interesante cruzar el rol con otros equipos, ser Scrum Master de otro equipo permite focalizarse mejor en los dos roles al no interferirse.

¿Cuánta muda transaccional puede ahorrarse en un proyecto desarrollado bajo Scrum?

Uno de las mudas o desperdicios que nos hacen ser menos productivos en nuestro trabajo y que mencionan Tom y Mary Poppendieck en su libro Lean Software Development, es el código o funcionalidad innecesarias o no solicitadas por el cliente.

Situando el foco del desarrollo en aquello que da valor al cliente se aplica un primer filtro al no incluir en la pila de producto funcionalidades que este no solicita, y un segundo filtro al poner funcionalidades con escaso o nulo valor al final de pila de producto. La pila de producto se reconstruye constantemente en función del mercado, y esto provoca que funcionalidades innecesarias siempre permanezcan al final de la pila. Una manera de decidir si vale la pena desarrollar elementos de la pila de producto es aplicar el ROI (Return Of Investment), cuando lleguemos cerca del final de la pila y si el ROI fuera negativo deberíamos de plantearnos si seguimos desarrollando las siguientes funcionalidades.

Para ilustrar la cantidad de desperdicio en funcionalidades he analizado el uso de una aplicación de gestión en cuyo desarrollo participé. El análisis abarca el uso de más de mil quinientas transacciones (páginas) en las que se han producido durante cinco años casi tres millones de clicks de acceso a las mismas.

Si nos fijamos en el siguiente gráfico, en concreto en las páginas que han tenido menos de 50 clicks, podemos ver en el gráfico de tarta de la derecha que ¡casi la mitad de las páginas son puro desperdicio! En el gráfico de tarta de la izquierda vemos que ¡el área que representa su uso casi no se puede distinguir! Tenemos casi un 50% de transacciones innecesarias. Resaltar que estamos hablando de número de transacciones, no de costes, posiblemente el coste represente entre un 10% y un 20% del producto.

Análisis desperdicio en transacciones (páginas)

Entre todo este desperdicio hay todo un sistema gestión de incidencias que nunca se ha llegado a utilizar. La mayoría son páginas de mantenimientos maestros de tablas paramétricas, lo que nos lleva a la conclusión de para tablas que se modifican raramente vale la pena mantenerlas directamente desde SQL/Server u Oracle.

Resaltar que no hay negocio, excepto TI, que acepte un 50% de desperdicio...

¿Cómo gestionar las historias técnicas?

Recientemente estuve hablando en un curso con un "Technical Product Owner". Me chirriaron los oídos, ese rol no existe en Scrum, pero me interesé más y le pedí que me contara. Me explicó en qué consistía su trabajo y cómo interactuaba con el resto del equipo.

¿Technical Product Owner?

La idea es tener dos pilas de producto, una para los requisitos funcionales, en forma de historias de usuario, y otra para los requisitos técnicos, la construcción de infraestructura que soporta las funcionalidades y la deuda técnica, en forma de historias técnicas. Cada pila tiene un responsable que colabora estrechamente con el otro; la primera el Product Owner o Propietario del Producto, y la segunda el Technical Product Owner. Ambos tipos de "product owners" se ponen de acuerdo a principios de cada sprint, especialmente en el inicio de las fases o releases, en donde deciden conjuntamente qué elementos técnicos van a incluir en los sprints.

Desde la perspectiva de Scrum la pila de producto ha de ser única e incluir historias de usuario e historias técnicas, y todas ellas ser responsabilidad sea el Propietario del Producto. Puede ser muy positivo que las responsabilidades recaigan en dos individuos con dos pilas, ya que eso propicia la negociación entre dos personas realmente interesadas en las historias de su rol.

Es importante focalizar los sprints en nuevas funcionalidades para que se produzca la entrega de valor al cliente, ya que las historias técnicas no aportan valor intrínseco, ahora sí, aseguran la capacidad de entrega funcionalidades y por tanto de valor. Alrededor de un 10% de estas historias técnicas son necesarias, a veces imprescindibles, según la fase en la que se encuentre proyecto.

Añadir que historias derivadas de deuda técnica pueden impactar fuertemente en la capacidad del equipo, mientras estas no se resuelvan, y a la vez puede ser positivo tenerla, porque nos hacen ágiles, ser mediocres a veces nos permite alcanzar un objetivo. Por supuesto hay que gestionar la deuda técnica y resolverla en cuanto sea posible.

¿Qué significan DoR y DoD?

DoR - Ready y DoD - Done

DoR (Defintion of Ready) responde a la pregunta ¿Qué tiene que estar listo antes de empezar a trabajar en una historia de usuario para que esta pueda entrar en un sprint? DoR se refiere a la calidad de los requisitos y es responsabilidad del Propietario del Producto. Explicita los criterios para toda historia de usuario susceptible de entrar en el próximo sprint, como por ejemplo:

• Que sea independiente y desarrollable en un solo sprint
• Que los criterios de aceptación que describen la nueva funcionalidad sean detallados
• Que se pueda testear
• Que no tenga dependencias externas
• Que esté estimada por el equipo
• Aprobada por arquitectura
• Aprobada por el usuario

Mi consejo es no empezar nunca en falso, si una historia de usuario no está preparada o el Propietario del Producto tiene dudas o no ha sabido transmitirla al 100% al equipo, es mejor no incluirla en el siguiente sprint, trabajarla e incluirla más adelante.

DoD (Definición of Done) responde la pregunta ¿Qué tiene que cumplir una historia de usuario para que esté hecha?, se refiere a la calidad del software y es responsabilidad del equipo. Una definición de hecho crea un entendimiento común en todo el equipo/compañía de lo que significa hecho. Explicita los criterios para que toda historia de usuario sea considerada hecha, a diferencia de los criterios de aceptación que son específicos por historia. Ejemplos:

• La historia ha sido analizada y se ha hecho el diseño
• El código escrito
• El código documentado o comentado
• El código se ha integrado
• El código probado apropiadamente (pruebas unitarias, de integración, de regresión, etc.)
• La historia ha pasado las pruebas de forma manual o automática según los criterios de aceptación
• La documentación y otros requisitos que requiere el proyecto/producto están hechos

Las historias tienen que entrar "Ready" en el sprint y salir "Done"

DoD también puede incluir acuerdos para considerar el incremento como hecho. Por ejemplo si se dedica un sprint a una página de búsqueda y en el sprint no cabe la página con el resultado, se puede explicitar el acuerdo como mostrar un xml con el resultado en la revisión de sprint para poder validar la búsqueda.

¿Cómo han de ser los incrementos resultantes de un sprint?

Primero recordar que el incremento es la suma de todos los elementos de la pila de producto producida durante un sprint. Estos deben de estar completamente terminados, ser operativos y potencialmente entregables al cliente independientemente de que el Propietario del Producto decida o no liberarlo a producción.

Como terminado se entiende que el incremento se basa en un código probado, bien estructurado y bien escrito y que se ha compilado en un ejecutable. Si el proyecto o el sistema requieren documentación técnica, archivos de ayuda, documentación para el usuario, procesos de validación y verificación documentados u otros requisitos adicionales del producto, todo ello debe de estar hecho conforme se recoge en la definición de hecho (DoD).

Ilustración tarta a porciones, de Sabrosa Alquimia

Esto implica que la arquitectura y el entorno técnico para poder ejecutar ese incremento deben de estar incluidos, pero sólo lo necesario para el sprint y los anteriores. Por ejemplo cuando desarrollemos un primer incremento este debe de incluir lo necesario para que se pueda ejecutar, pero no mucho más allá. Quizá así incurramos en deuda técnica de escalabilidad, pero así nos focalizamos en nuestro incremento y construimos sólo aquello donde la incertidumbre sea baja, lo que nos hace ser ágiles. Probablemente habremos de incluir la deuda técnica en un futuro sprint, pero cuando lleguemos, no antes.

Una forma de imaginarnos los incrementos de Scrum es como si construyéramos una tarta a partir de sus porciones. La idea es entregar porción (incremento) tras porción, dónde cada una tiene una base de bizcocho (arquitectura, entorno técnico), su relleno (funcionalidades) y su decoración (documentación). Para que el incremento sea entregable es importantísimo que el repostero (el tester, uno de los miembros del equipo) la haya probado antes de exponerla a los clientes, no vaya a ser que algún ingrediente falte o sobre y la porción sepa mal.

Por tanto los incrementos han de ser lonchas verticales en la medida de lo posible, a diferencia del desarrollo de proyectos bajo metodología tradicional donde se suele planificar y desarrollar horizontalmente por capas (capa de base de datos, capa de negocio, capa de presentación...).

Siguiendo con la analogía de la repostería, la división vertical de un producto no sólo permite construir los incrementos guiados por valor, sino también nos da la oportunidad de ir adaptándonos hasta el punto de poder crear nuevas funcionalidades no previstas inicialmente, otros postres muy distintos, como los muffins por ejemplo, que son posibles a partir de los mismos ingredientes que tenemos disponibles.

Quiero dar mis agradecimientos a María por abrirme a la repostería y por la foto del post, a José López por algunas ideas como los muffins y a raq por el repostero y recordarme que la calidad no puede ser una variable en Agilidad.