¿Qué es Ágil?

Desde hace más de 20 años tenemos el manifiesto Agile (https://agilemanifesto.org/). Sin embargo, 20 años después, no parece que haya un acuerdo sobre lo que realmente significa ágil. De alguna manera, el manifiesto no fue suficiente, nuevas personas se metieron en “agile” y surgió la necesidad de crear nuevos conceptos como el MVP, MLP, lean, etc.

Por ejemplo, he estado en varias entrevistas de productos en las que algunas personas de productos dijeron que estaban haciendo/siendo ágiles porque estaban usando scrum. No creo que ágil se trate de seguir cualquier marco, sino de tener una mentalidad particular. Es bien sabido que hubo marcos/metodologías incrementales e iterativos antes de Agile.

Estaba pensando en cómo resumir qué es ágil y por qué hay tanta confusión al respecto. En definitiva, creo que ser ágil pasa por aceptar que hay cosas que no sabemos y que no es posible saber qué va a solucionar determinados problemas. Resolver los problemas de los clientes mediante la creación de software es una disciplina probabilística, cuando pensamos en una solución, tenemos ciertas posibilidades de resolver esos problemas.

Si podemos aceptar que no sabemos cuál es la mejor solución -y a veces ni siquiera entendemos completamente cuál es realmente el problema-, entonces todo lo que viene después tiene más sentido:

• Necesitamos mitigar el riesgo de no saber/resolver el problema mediante iteraciones (tanto de descubrimiento como de entrega).
• Esas iteraciones deben ser significativas para que podamos saber si vamos en la dirección correcta (no necesitamos llamarlo MVP o discutir qué es un MVP si entendemos el espíritu de lo que estamos haciendo).

• Cuando no necesitamos hacer validación porque sabemos.
• Cuando no entendemos el problema pero estamos haciendo lo que nos dicen.
• Cuando “hecho” es cuando hemos entregado algo en lugar de solucionar un problema.
• Cuando sepamos lo que haremos en los próximos 6/12/36 meses

No, no es cierto que todos los problemas sean nuevos. Para algunos de ellos, existen muchas soluciones funcionales que han sido validadas por años de uso y buenos comentarios.

Sin embargo, he visto muchas veces equipos que agregan creatividad a las soluciones conocidas y al final no resuelven el problema.