Luego de cinco proyectos realizados y dos en marcha, la adaptación de este marco de trabajo empírico ha seguido distintos caminos.
Pasar del libro a la práctica, de la teoría a la aplicación, de la filosofía a lo concreto ha tenido dificultades salomónicas, la construcción al ser una industria muy dinámica y variable, cuesta mucho estandarizar pasos o crear modelos típicos de procesos y procedimientos cuando de control se habla. Incluso en un mismo proyecto, la situación se torna compleja en cada etapa y en cada actividad. Al estar en primera fila viendo aciertos y fracasos, logramos esa madurez para decidir el mejor camino para la gestión de la obra. Partimos primero de aceptar que ninguna filosofía, metodología o marco de trabajo es perfecta, tenemos que estar más arriba de ellas y ver el todo como operaciones y estrategias que requiera de todas las herramientas necesarias para sumar en cada proceso y logren lo que más nos importa, la satisfacción del cliente (en procesos y producto entregado).
Scrum no es una metodología, es un marco de trabajo, Scrum no prescribe, no receta y no define como se deben llevar a cabo las cosas, que herramientas o prácticas usar para desarrollar un producto o servicio. No hay fórmulas o pasos establecidos que seguir y adoptar al usar Scrum. Tampoco existen las mejores prácticas que deben usadas una y otra vez sin cuestionar, las mejores soluciones emergen de los equipos autoorganizados de acuerdo al contexto y el problema a resolver, algo que funciona muy bien en una empresa y situación no es necesariamente la mejor solución a seguir en otras situaciones (Joel Francia).