¿Las metodologías ágiles funcionan?

Para poder determinar esto primero debemos entender qué son las metodologías ágiles, ya que he notado que el principal detonante de que estas no funcionen es que se implementan de forma errada. He conocido Agile Coaches con poco criterio del tema argumentando que todo se debe seguir al pie de la letra según el marco de trabajo — Scrum siendo el más popular —, y con esta premisa se está fracasando desde el inicio.

Marco de trabajo flexible

Entender que Agile no es seguir un marco de trabajo al pie de la letra es complicado para algunos, acostumbrados a seguir pasos religiosamente estructurados (Waterfall). La idea es entender las virtudes y defectos de tu equipo para lograr los objetivos de negocio de forma eficaz y a un ritmo incremental.

El Scrum Master como orientador debe conocer a su equipo y tratar que en cada iteración puedan entregar valor a través del software. No es solamente convocar las ceremonias de Scrum y ver el burndown chart. Aquí también fallan muchos "Scrum Masters".

Bajo mi perspectiva, un Scrum Master que no tenga el más mínimo conocimiento técnico realmente aporta poco. Sé que muchos me cuestionarán, pero analicemos lo siguiente: "Desbloquear al equipo de dependencias externas es labor del Scrum Master". Mi pregunta es: ¿cómo desbloquearás una dependencia técnica con otro equipo si no tienes idea del porqué de esa dependencia?

Entiende los problemas de tu organización

Para que Agile funcione, debe nacer con voceros que realmente entiendan agile y los problemas de la compañía. Por ejemplo, si en la empresa donde estás los procesos son burocráticos, lentos y fuertemente estructurados, implementar agile al pie de la letra tendrá un impacto negativo total — es un cambio cultural muy fuerte que puede generar discordia interna.

Lo más idóneo es empezar con pequeños proyectos orientados al negocio. ¿Por qué el negocio primero? Porque los equipos deben integrarse con él. La figura del Product Owner es fundamental: entiende las capacidades de cada equipo para construir software y elimina esa línea en la que negocio define sus necesidades y estas pasan por un Project Manager, analistas, proveedor, etc.

En Waterfall, cuando estamos a mitad del proyecto y faltan requisitos, estos deben pasar por toda esa cadena de nuevo — el terrible "cambio de alcance". Si en tu organización son "ágiles" y escuchas cambios de alcance a cada rato, no hay nada de agile allí.

Luego que logras que negocio trabaje junto al equipo de desarrollo, si el marco es Scrum necesitarás un Scrum Master. Un equipo que no logra sacar proyectos de forma ágil tiene al Scrum Master como responsable: debe conocer al equipo, entender las dependencias externas, motivar la mejora continua y encontrar el marco que se adapte al equipo.

Tomemos como ejercicio solo las dailys. Digamos que al inicio las tienes todos los días con las mismas preguntas de siempre (qué hice ayer, qué haré hoy, si tengo algún bloqueo). Si después de 3 meses ese equipo tiene las mismas dailys todos los días, ese Scrum Master ha fallado. ¿Qué valor le ha sacado a esa reunión de "15" minutos?

He estado en equipos donde duran casi una hora, convirtiéndolas en reuniones de seguimiento del Product Owner — Waterfall disfrazado. En equipos maduros, las dailys las decide el equipo y se reúnen solo ellos para comentar algún bloqueo y generar una estrategia para solucionarlo.

En resumen

Que la metodología ágil funcione en tu organización depende de los facilitadores (Agile Coaches, Scrum Masters, Product Owners) y de que la cultura de tu compañía sea capaz de adoptar estos cambios. Para esto deben ver resultados: empieza por proyectos pequeños que sean verdaderamente ágiles y que muestren resultados en tiempo y coste.