Desarrollo de software. El uso de prácticas basadas en diferentes metodologías ágiles
Ya sabemos que por mucho que nos quieran vender no hay tallas únicas o fórmulas magistrales en el desarrollo de software. Cada organización, cada proyecto, cada equipo, cada persona es un mundo y además cambia con el tiempo.
Es por ese motivo que la aplicación estricta de determinadas metodologías ágiles de manera generalizada es algo muy complicado, no por el hecho en sí de hacerlo sino porque no resultará efectivo cuando se apliquen a proyectos en donde no encajan.
Coincido con Henrik Kniberg (aunque en la práctica lo olvido casi siempre) en que no se debe confundir el uso de Scrum (por poner un ejemplo, ya que es extensible a cualquier metodología: XP, Kanban, etc…) con el uso de prácticas, estrategias o técnicas de Scrum porque al final se perdería la esencia de lo que es realmente esa metodología. Sin embargo, lo verdaderamente efectivo es conocer esa descomposición de Scrum y aplicar lo que realmente resulte interesante a tu organización y a tus proyectos.
De esta forma no tenemos un conjunto de metodologías sino un conjunto de herramientas y eso resulta mucho más ágil y efectivo.
De fondo pueden existir procesos (o metodologías) que armonicen ciertos aspectos en los proyectos en los que se trabajan, algo que resulta lógico y razonable, es decir, habrá «herramientas» de uso obligatorio pero existirá (o deberá existir) suficiente margen de maniobra para que puedas escoger las que mejor se ajusten al proyecto y su contexto.
Jummp 
Aunque no tenga demasiada relación, este post me recuerda mucho a la casuística del UML. Me explico: no tiene sentido usar siempre todos los diagramas UML existentes en cualquier proyecto. La herramienta está para sernos útil, no para «sobredocumentar». En cada proyecto, situación, etapa en que nos encontremos etc… será útil un diagrama u otro, o incluso ninguno, y el uso correcto e inteligente de los mismos es lo que aportará valor.