A estas alturas del partido, todos deberíamos saber que no existe balas de plata, así que aunque algunos defiendan a capa y espada SCRUM, CMMI, ISO, o lo que sea, hay que tener muy presente que quizá ninguna de ellas sea la metodología o proceso adecuado para tu organización.
Una metodología se crea en un contexto, y suele funcionar bien en ese contexto, y no en otros. En el caso de las metodologías ágiles, y en concreto SCRUM, nacen en el contexto de desarrollo de productos tecnológicos, con equipos estables, motivados, multidisciplinares y de un nivel muy alto, siempre buscando aportar valor al cliente por encima de seguir un plan preestablecido. Si estás en este contexto y aplicas SCRUM, lo más probable es que tengas éxito. Si tu contexto es otro (por ejemplo, no tienes equipos estables y/o están desmotivados, o no se espera que innoves, sino que te ciñas a un plan de fechas ajustado), entonces aplicar SCRUM seguramente sea como buscar la cuadratura del círculo: además de complejo, no aporta nada útil.
Ante este panorama tenemos dos opciones:
- Que el proceso de implantación de la metodología se convierta en un proceso global de transformación de toda la organización: si crees que lo mejor sería aplicar SCRUM, pero no cuentas con el contexto adecuado, entonces tu primer trabajo es conseguir ese contexto: convertir tu empresa en una empresa ágil: equipos motivados y multidisciplinares, dirección alineada con la visión ágil, estrategia comercial compatible, etc. En este caso, implantar SCRUM no es algo exclusivo del dpto de desarrollo, sino que se convierte en un proceso global que afecta a todos, tal y como propone Scrum Manager. Cuando veas que el contexto está cambiando, entonces introducir SCRUM puede ser un buen método conductor hacia la nueva filosofía de empresa, aplicando prácticas y métodos concretos (la forma) a una forma de ser que ya está echando raices (el fondo). Como habrás imaginado, este es el camino difícil.
- Buscar una metodología que aunque no sea 100% ágil o formal, pueda adaptarse bien a nuestra cultura de empresa. Si por ejemplo tenemos un dpto comercial que acuerda fechas fijas y no dejan margen de maniobra para reducir funcionalidad, o no hay ningún tipo de colaboración continua con el cliente, sino que todo se cierra en el contrato inicial, o si por desgracia no contamos con un equipo suficientemente bueno, sino que es «lo mejor que se pudo encontrar con los recursos que teníamos» entonces, tenemos una serie de obstáculos dificilmente salvables para poner en marcha una metodología 100% ágil. Si además, la forma de actuar del dpto comercial no podemos cambiarla (porque la dirección quiere o necesita ese tipo de estrategia comercial), o si no podemos mejorar el equipo (porque la empresa no tiene recursos para contratar a más y/o mejores técnicos), entonces introducir elementos de procesos más tradicionales, al estilo CMMI o ISO, nos puede resultar mucho más útil que empecinarnos en un enfoque ágil cuando sabemos que la batalla está perdida de antemano. Utilizar prácticas y procesos «tradicionales» no es malo en sí mismo, ni anticuado, ni de gestores del siglo pasado: lo que es malo es seguir utilizándolos en aquellos contextos donde se podría llegar más lejos con otras formas más ágiles. De igual forma, las metodologías ágiles no son buenas por sí mismas, ni son cool, ni de gestores visionarios, sino que lo realmente bueno es maximizar el rendimiento de la organización al completo hasta un punto óptimo de funcionamiento, y recalco lo de «la organización al completo», y no cada dpto por separado.
Elegir una alternativa o la otra depende de muchos factores, pero sobretodo de la capacidad de la empresa y su gente para reinventarse a sí mismos: si tus compañeros y la dirección de la empresa son capaces de cambiar su forma de pensar y actuar, entonces ya tienen mucho del espíritu «ágil», así que posiblemente la opción correcta sea la primera. Si, por el contrario, no tienes garantías de que todo el mundo sea capaz de adaptarse a otros métodos de trabajo más ágiles, entonces quizá un buen comienzo sea utilizar algo más «formal», y más adelante ir reconduciendo hacia el «agilismo» o hacia el «formalismo» según la empresa vaya adaptándose o no a los cambios propuestos.