La elección de una metodología adecuada para un proyecto dado es, sin duda, una de las claves del éxito del mismo. Decir que las metodologías ágiles han llegado al panorama del mundo de la gestión para quedarse y que están irrumpiendo con fuerza es sin duda una afirmación anacrónica: no han llegado ahora, sino que han adquirido un nivel de madurez suficiente como para no ser vistas como un modismo, una excentricidad, entre los directores de proyectos medianamente bien informados.
Sin embargo, no son el bálsamo de Fierabrás, la solución mágica a todos los problemas de la gestión, como pretenden hacer creer sus más acérrimos defensores. Como tampoco lo es cualquier otra metodología que uno quiera imaginar. Cada proyecto, cada empresa, cada cliente, tiene un contexto y unas necesidades que marcarán la metodología más adecuada a utilizar.
Las metodologías ágiles, como puede ser SCRUM, tienen una especie de canto de sirena que hace que te lances a sus brazos sin saber los peligros que pueden esconder. Peligros que, bien gestionados, son precisamente una de las fortalezas de las mismas. Y si el peor enemigo de cualquier proyecto es la falta de involucración de los diferentes actores del mismo, en el caso del agilismo ataca a su línea de flotación, a su esencia. El peor enemigo del agilismo es el escapismo.
Cuales avezados discípulos de El Gran Houdini, uno intenta mantenerles encadenados (figuradamente hablando, por supuesto) al proyecto, pero al final siempre escapan.
Centrémonos en SCRUM. Si el Product Owner es un escapista profesional, sencillamente no hay proyecto. Si, como representante del cliente, no aporta la perspectiva de negocio, no detalla las historias de usuario y las prioriza adecuadamente, no hay nada que hacer. Y además son los más complicados de gestionar, tanto en cuanto, siendo parte del cliente, se dispone de poca (o nula) capacidad de dirigir la situación hacia el interés común. Se requieren las más altas sofisticadas técnicas de persuasión para ello (recordemos la historia de Catón El Viejo). Otras veces, no queda más remedio que escalar el problema en la organización (u organizaciones) involucradas, para que pueda ser gestionado por quien tenga la potestad para ello.
En otras ocasiones el escapista es el Facilitador (SCRUM Master). Dicho muy superficialmente, El SCRUM Master debe eliminar todas las barreras que se presentan en el proyecto, permitiendo al equipo de desarrollo centrarse precisamente en eso: el desarrollo. Al mismo tiempo, vela por la correcta implantación de la metodología. Si el SCRUM Master es un campeón del «No es asunto mío», si malinterpreta la autoorganización de los equipos SCRUM con el «estos chavales son muy espabilados y seguro que lo resuelven solos», si no es garante del cumplimiento de la metodología y los planes establecidos, no tenemos SCRUM. Tendremos, a lo suma, un conjunto de aguerridos soldados que tratarán de sobreponerse a las vicisitudes de la batalla de la mejor manera posible.
Que haya escapistas en el equipo de desarrollo de un proyecto SCRUM, como en cualquier proyecto en general, no hace sino contribuir al mal desempeño y mal ambiente en el mismo. En SCRUM los equipos trabajan como relojes perfectamente sincronizados y todo está orientado a la alta eficiencia de los mismos. Se les da la confianza y empoderamiento suficientes para ello. Deben tener sentimiento de equipo. Debe existir una comunicación fluida, honestidad y confianza para reportar diariamente los avances conseguidos y problemas encontrados. Con solo un escapista profesional que haya … Os podéis imaginar.
Por supuesto, también puede haber escapismo entre las partes involucradas (stakeholders) y la dirección de las organizaciones, pero los efectos en el proyecto no son (siempre) tan inmediatos.
¿Has sufrido escapismo en tus proyectos? ¿Pudiste revertir la situación? ¿Cómo? Ya sabéis que los comentarios en este blog sirven para aprender unos de otros, como de muro de las lamentaciones 🙂
¡Gracias por compartir tu experiencia!
Deja un comentario