¿Cómo vender un proyecto ágil?

Esta es una pregunta recurrente que surge en casi todas las charlas de metodologías ágiles.
Sabemos que realizar una propuesta o definir un alcance cerrado es un riesgo.
Según el Standish Group, la mayoría de los problemas del desarrollo de software no son técnicos, sino que están entre otros, en los requerimientos.

¿Relevamos mal? ¿Deberíamos dedicar más recursos? ¿Lograr mayor compromiso del usuario por lo acordado?
No necesariamente. Muchas veces el relevamiento es adecuado, el usuario lo entiende y lo acepta.
¿Qué pasa entonces? La realidad que sustenta el alcance cambia: cambian las necesidades, la tecnología, la legislación, etc.
¿Es esto evitable? No, y tampoco debemos esperar que no ocurra. Justamente lo contrario: la capacidad de adecuarnos, de ser ágiles para cambiar el rumbo, es la principal ventaja de las metodologías ágiles. Por eso lo de "abrazar el cambio"

Vuelvo a la pregunta inicial: ¿cómo convencemos a nuestros clientes, los usuarios, de trabajar en el marco de un proyecto ágil en lugar de uno con alcance cerrado?
Recuerdo la respuesta de Tobias Mayer en la primer capacitación de SCRUM que se dictó en Latinoamérica. Fue más o menos algo así: "Este es un problema comercial, no del proyecto" Scrum resuelve la problemática de los proyectos, no los comerciales.
La respuesta de Tobias es cierta. Pero no nos deja satisfechos. Es que estamos, en general, en una instancia previa. Antes de convencer a nuestro cliente, debemos convencer a nuestros comerciales, a nuestra dirección.

¿Cómo podemos hacerlo?

• lo primero: buscar entregas cortas que puedan ser puestas en producción rápidamente.
• acordar un alcance macro (por un tiempo macro) del alcance del sistema a ser revisado en cada iteración.
• identificar qué es imprescindible: Siempre hay dos o tres cosas que tienen que estar sí o sí. Que dan forma al desarrollo que estamos planeando. Una vez que las identificamos, resolverlas en las primeras instancias.
• concientizar a los usuarios que un alto porcentaje de software desarrollado nunca llega a usarse.
• dar libertad al usuario para suspender el proyecto al final de cada iteración, sea porque se alcanzó la funcionalidad más importante, o porque se perdió el objetivo del sistema. Esto es parte de ser ágil.