¿ScrumFall puede aportar?

ScrumFall en la forma de acometer las tareas del sprint

ScrumFall es un ScrumBut en el que pretendemos trabajar con Scrum pero seguimos impregnados de la mentalidad de construcción de proyectos por fases en cascada.

Una de las formas de ScrumFall se manifiesta en como acometemos las tareas en los sprint, a la izquierda una imagen del post que escribí al respecto el año pasado.

He observado otra forma de ScrumFall en una compañía cuya oficina de proyectos ha diseñado su propia metodología, y que consiste en definir y llenar todos los sprints a partir de la pila de producto inicial a principio del proyecto. La metodología contempla la posibilidad de cambios a lo largo de los sprints, pero esos cambios difícilmente van a prosperar, ya que en el primer momento ya hemos detallado todo el proyecto y nos resistiremos a incorporar cualquier cambio. Al fin y al cabo hemos hecho un esfuerzo para detallar todo, y lo habremos hecho habiendo pensado en el todo, y habremos diseñado y tomado decisiones desde la perspectiva del proyecto en su conjunto.

ScrumFall en la pila de producto

Como podemos ver una pila de producto detalla en el primer momento va a minimizar, y prácticamente evitar, el aprendizaje y la mejora continua sobre el producto, aunque construyamos este de forma incremental e iterativa mediante sprints. Básicamente eso va a provocar que el producto acabe siendo lo que se haya definido a principios del proyecto.

Pero, ¿no hay algún beneficio al aplicar Scrum en estas circunstancias?

Si, lo hay, el hecho de construir de forma iterativa con sprints va a provocar aprendizaje del proceso, el equipo mejorará la forma de trabajar y diseminará el conocimiento a través la mejora continua con cada retrospectiva a final de sprint.

Aunque esta forma de ScrumFall no sea Scrum, puede ser una forma para iniciar Scrum en una compañía tradicional. Si de esta forma se hace patente que el equipo mejora de sprint en sprint, quizá la compañía sienta curiosidad y se plantee aplicar Scrum de verdad.