¿Puede fracasar un Sprint? ¿Es su objetivo entregar una meta o un backlog? ¿Es el aprendizaje un éxito parcial en un Sprint que no entrega lo esperado?
Contenidos del artículo
Adaptando Scrum a la complejidad del desarrollo
Scrum nació como respuesta a la creciente complejidad de los proyectos IT de los años 90. En muchos artículos escritos sobre Scrum se habla de como proporciona claras ventajas respecto a los métodos tradicionales en cascada respecto a valor generado, mitigación del riesgo y satisfacción de los clientes dadas las características de Scrum para mitigar la complejidad como:
- Ciclo de vida incremental e iterativo para inspeccionar y adaptar el entendimiento de lo que debe ser el producto tal y como vamos aprendiendo sobre él a través de todas las actividades del desarrollo y mantenemos el contacto con los usuarios finales y otros actores del desarrollo.
- Equipo polivalente y autogestionado, que permite tomar las decisiones, así como realizarlas y corregirlas sin depender de otras partes de la organización que puedan limitar las opciones o retrasar la inspección y adaptación.
- Cultura de valores como la transparencia, coraje, compromiso, respecto, foco y franqueza.
Esta ventaja es muy clara en los proyectos de alta complejidad, aunque Scrum también puede utilizarse con éxito en muchos desarrollos «complicados» y «simples». Se debe tener en cuenta el grado de complejidad del proyecto a la hora de adaptar el uso de este marco de trabajo, como pasa en el enfoque de los Sprints que veremos en el siguiente apartado.
Sprint orientado a una meta o a un backlog
Cuanto más complejo es un desarrollo, más difícil es determinar sus requisitos a priori, como muestra el diagrama de Stacey del apartado anterior. Esta realidad aplica tanto al inicio del desarrollo (o proyecto), y también aplica la certidumbre que podemos tener en la práctica sobre los requisitos al printicio de los Sprints. En este tipo de proyectos, la cultura predictiva y waterfall de una organización puede obviar esta realidad y orientar a los equipos a definir el objetivo del Sprint como entregar un alcance concreto de requisitos (habitualmente en forma de historias de usuario) que además pueden considerarse especificados y no modificables durante el Sprint. Tres síntomas claros que nos dicen que estamos usando mal Scrum son:
- El Sprint Backlog se convierte en un contrato y no en un plan del equipo.
- El Equipo de Desarrollo está formado por programadores, y los requisitos vienen determinados desde fuera.
- La revisión del Sprint en estos casos es cuantitativa: ¿se ha entregado más o menos parte del Sprint Backlog «comprometido»?
En desarrollos complejos, la organización debe permitir la experimentación y fomentar el aprendizaje. Esto implica el reconocimiento colectivo de la dificultad de los Sprints y, a pesar que puedan definirse con más o menos precisión las funcionalidades que se planifica desarrollar, orientar el Sprint al cumplimiento de una meta que deje espacio al equipo para un trabajo más creativo y le permita la toma de decisiones orientadas a valor generado cuando descubren imprevistos durante el Sprint. Estos imprevistos, habiendo hecho durante el refinamiento un esfuerzo razonable para anticipar los requisitos y las decisiones de diseño, son realmente una oportunidad para generar más valor y no un problema a gestionar.
Sin embargo, en desarrollos simples o no muy complicados, las metas de los sprints pueden estar más orientadas a la entrega de grupos de funcionalidades con una cierta cohesión, si esto no le quita margen de acción al equipo de desarrollo para tomar decisiones respecto aspectos como la prioridad de las funcionalidades, su implementación o decisiones tecnológicas.
¿Cuando se puede considerar fallido un Sprint?
La Scrum Guide nos dice que un Sprint puede cancelarse si su meta es inalcanzable o no tiene sentido. Dado que los Sprints suelen ser cortos, es infrecuente que no se pueda definir una meta viable o que suceda algún evento externo que impida la posibilidad de alcanzarla.
Veamos dos ejemplos de posibles Sprints fallados y porqué no lo son, en un desarrollo con una complejidad elevada, donde hay muchas posibles soluciones a priori (zona amarilla) y es difícil determinar las que satisfarán al usuario (subconjunto verde).
- En el primer Sprint se define y entrega un incremento que realmente no es utilizable por el usuario, y que posiblemente se cancelase por no ser una meta útil. A priori podríamos pensar que esto es un fracaso, pues no genera un incremento «potencialmente entregable». Pero la inspección y adaptación consigue reorientar el desarrollo hacia una solución más cercana a lo que busca el usuario, y además posiblemente determinando en la Retrospectiva que factores habían influido en determinar una meta del Sprint que no contribuía a avanzar hacia un producto necesario.
- En el segundo Sprint, que ya entrega un producto usable para el usuario pero mejorable, se vuelve a inspeccionar y adaptar para mejorar el valor generado.
En estos dos Sprint iniciales, que podrían considerar fracasos en mayor o menor grado, el equipo aprende y avanza hacia la entrega de una solución valiosa para el usuario, por lo que no son fracasos desde el punto de vista de Scrum, que reconoce la complejidad del desarrollo de software y valora el aprendizaje para optimizar las posibilidades de afrontar problemas complejos.
