Que un proveedor diga "trabajamos con Scrum" no dice casi nada por sí solo. La pregunta que sí importa es qué le entrega a usted esa forma de trabajo, exactamente.
Scrum resuelve la cadencia, no la documentación ni la calidad
Sprints, retrospectivas y un backlog priorizado dan visibilidad de avance y permiten reajustar prioridades cada pocas semanas — eso es real y valioso. Lo que Scrum, como marco, no garantiza por sí solo es que quede documentación de arquitectura, que el código tenga pruebas o que el conocimiento sobreviva si alguien del equipo se va.
Un proveedor puede ejecutar sprints perfectos y aun así entregar un sistema sin memoria técnica.
Lo que sí debería exigirse, tenga el proveedor el nombre de metodología que tenga
Visibilidad real de avance con una cadencia definida y verificable, no solo una promesa. Documentación de arquitectura y decisiones que sobreviva al cierre del proyecto. Trazabilidad de qué se decidió, cuándo y por qué. Y un criterio explícito de calidad —qué se prueba, cómo se prueba— antes de considerar algo terminado.
El nombre de la metodología importa menos que la evidencia de que se sigue
Draco trabaja con un estándar propio —SDD, Estándar de Desarrollo Draco— que exige documentación verificable en cada fase del proyecto, precisamente porque la experiencia mostró que la cadencia ágil sin ese respaldo documental deja al cliente dependiente del proveedor de forma innecesaria.
Cualquier proveedor, siga Scrum, Kanban o un método propio, debería poder mostrar evidencia concreta de ese respaldo cuando se le pregunta — no solo el nombre del marco que usa.
La pregunta correcta no es qué metodología usan, sino qué queda si el proyecto termina mañana
Si el proyecto se detuviera hoy, ¿hay documentación suficiente para que otro equipo continúe? ¿Existe trazabilidad de las decisiones tomadas? ¿Hay pruebas que permitan verificar que el sistema sigue funcionando después de un cambio?
Esas respuestas dicen más sobre la seriedad del proveedor que cualquier nombre de framework en la propuesta.