Cuando desarrollas una nueva aplicación generalmente lo haces con un framework, por ejemplo Spring, Laravel, Django tan solo por mencionar algunos.
Los frameworks por sí solos no hacen un trabajo en particular. Por ejemplo, para desarrollar un sistema de punto de venta ninguno tiene un punto de venta ya incorporado que puedas utilizar.
Por tanto, para que pueda ser útil el framework necesitamos adaptarlo a nuestras necesidades, es decir tomar sus capacidades, herramientas e incluso principios y filosofía para construir las soluciones que requerimos. En consecuencia usamos el framework para contener y construir algo.
En muchos casos se usa el término metodología para referirse a los marcos ágiles como Scrum. La agilidad implica una transformación cultural mientras que la metodología implica un proceso basado en pasos predefinidos. La metodología no fomenta y por el contrario puede impedir el descubrimiento y empirismo.
Joel Francia
Muchos profesionales de hoy en día se refieren a Scrum como «La metodología Scrum«. Este error se ha extendido al grado en el que podemos escuchar esto de profesionales de gestión de proyectos, directores de ingeniería de software y demás. En algunas situaciones se puede observar organizaciones que en teoría adoptan Scrum, pero esa adopción no se refleja en un cambio cultural en el cual el desarrollo del software trabaje de la mano de operaciones para lograr la entrega de software funcionando en cada Sprint (Francia, 2017)
Tal como los frameworks para desarrollo de software Scrum plantea un marco de trabajo, un cambio cultural para contener prácticas, herramientas, procesos, etc, que el equipo de desarrollo elegirá como más conveniente para construir productos con alta calidad y excelencia técnica.
Adopción de Scrum
Resulta común percibir a la adopción de Scrum como un cambio de nombres a las ceremonias para los proyectos más no en la cultura de la organización. Estimaciones con tiempo fijo, carencia de priorización del Product Backlog, etapa de análisis y diseño definidas dentro un Sprint, la falta de un Product Owner, la falta de un Scrum Master, la carencia de un refinamiento de producto que fomente el empirismo y el descubrimiento, Jefes de Proyecto tradicionales con un enfoque de control sobre el equipo o los proveedores de software que no fomentan la colaboración y van en contra de las principios ágiles, sólo por mencionar algunos factores son los que llevan a finalmente no entregar producto funcionando listo para ser usado y en lugar de eso se entreguen productos incompletos y con errores que son rechazados por los clientes en cada Sprint y con ello se provoque la insatisfacción del equipo, la empresa y los usuarios involucrados. (Francia, 2017)
Scrum no es una receta mágica de moda, es un marco de trabajo que bajo los pilares del empirismo, la transparencia, inspección y adaptación, sacará a la luz aquellos inconvenientes que no permiten avanzar en el trabajo a un equipo. (Yorman, 2017)
Referencias:
https://www.scrum.org/resources/blog/scrum-no-es-una-metodologia-es-un-framework