Ahora tú eres el CEO… ¿Qué metodología elegirías para tu próximo gran proyecto TI?

Pues sí, ya hemos debatido y leído muchos artículos que resaltan las bondades de las metodologías ágiles frente al tradicional modelo ‘en cascada’ (waterfall).

Pero también hemos podido participar en numerosos foros o debates donde se explican las dificultades de dicha adopción:

• “Es algo que debe adoptar toda la organización, no depende sólo de TI”
• “Me dan un presupuesto cerrado con un alcance definido … no puedo ‘estirar’ el presupuesto o hacer menos alcance”
• “Agile no vale para todo … hay proyectos donde no encaja”
• …

Y mientras tanto, seguimos recibiendo propuestas con el mismo patrón: relato prolijo de requisitos, información limitada en fase de propuesta, tiempo ajustado de elaboración de propuesta, enfoque competitivo liderado por compras con varios proveedores, y cierta predisposición a favorecer un enfoque metodológico ágil.

Pero ahí se queda la apuesta por dicha metodología en ocasiones.

Es algo que se valora, que queda bien, pero no siempre la organización y el proveedor adoptan dicho enfoque como una estrategia real de entregar valor de manera continua y maximizando la satisfacción del área de negocio.

Teniendo en cuenta las consabidas dificultades y la tozuda realidad que seguimos viviendo, ¿cuál sería tu aproximación si pudieras decidir la estrategia de implantación de tu próximo gran proyecto TI?

¿Por qué yo elegiría una metodología agile –escalado agile* en caso de un gran proyecto-?

Entre los argumentos que considero más relevantes para tomar esta decisión, destacaría especialmente:

• El alineamiento que se consigue con el flujo continuo de información entre un product owner (o con un product owner by proxy –perfil técnico que se integra dentro del equipo de negocio-) con el equipo de desarrollo es difícilmente superable por un proyecto tradicional.
• La maximización del valor entregado, al permitir cierta flexibilidad en la definición del backlog a implementar en cada sprint, cuando el área de negocio tiene más madurada la funcionalidad clave a entregar a su cliente, es otro argumento difícilmente rebatible.
• La transparencia en la comunicación y en el avance del proyecto, especialmente aplicando metodologías de escalado agile, que permiten participar a distintos stakeholders en las demos de producto (quincenales o mensuales), que están calenderizadas con suficiente anticipación.
• El seguimiento diario de las actividades del equipo, los mecanismos grupales de estimación y colaboración, y las retrospectivas para identificar carencias y áreas de mejora e implantar cambios que los resuelvan, también es otro argumento poderoso.
• Y aún podemos añadir uno más. La propia motivación del equipo, que está deseoso de participar en nuevos enfoques que aporten más valor y que les ayuden a crecer como profesionales.

Lógicamente, uno no puede tomar decisiones de forma independiente y confiar en que todo vaya bien.

Por eso la pregunta hace referencia a ‘¿qué harías si tú fueras el CEO …?’. Se supone que desde esa posición se pueden tomar medidas relativas a: presupuesto, contratación, organización (colaboración entre negocio e TI), asesoramiento externo especializado, …

Y una última reflexión:

Si mediante las metodologías ágiles, conseguimos un mayor alineamiento entre negocio e TI, priorizando requisitos que aportan más valor, con mayor transparencia y motivación, ¿no es esto suficientemente atractivo como para perderlo porque nos hemos trazado una ‘hoja de ruta’ (llámese requisitos rígidos predefinidos, muchas veces con insuficiente nivel de detalle) y porque queremos maximizar nuestra inversión como cliente (incluso, en ocasiones, a costa del margen del proveedor)?

La ola del escalado agile va camino de convertirse en tsunami …

*Escalado agile: dentro de las metodologías para coordinar el trabajo de múltiples equipos agile, cabe mencionar SAFe –Scaled Agile Framework-.