Introducción

En los últimos años he sentido, en forma repetida, hablar de “Agile” como de una metodología y a sustituir “Agile” por “Scrum” sin advertir que son cosas diferentes.

“Agile” no es una metodología sino un conjunto de valores y principios que fueron establecidos en 2001, a partir de la reunión que realizaron 17 personas en busca de puntos en común con relación a las mejores prácticas para el desarrollo de Software. Esta reunión dio como resultado el denominado: Manifiesto para el desarrollo ágil de software. En el manifiesto se expresan valores y principios que determinan un tipo de enfoque y existen metodologías que se alinean con éste. A efectos de simplificar decimos que, por ejemplo, SCRUM es una metodología Ágil. Esto quiere decir que la metodología SCRUM se alinea con los valores y principios expresados en el Manifiesto y por tanto es una metodología que sigue un enfoque ágil de gestión de proyectos.

Las metodologías ágiles tienen dos características fundamentales, siguen un enfoque iterativo e incremental. Iterativo quiere decir que trabajo con ciclos cortos de interacción con el cliente. Esto permite recibir retroalimentación sobre un trabajo que no está terminado para poder modificarlo y mejorarlo sobre la marcha, adaptándolo a las expectativas del cliente. Incremental implica que no se espera a tener la última versión del producto para ponerlo a funcionar sino que ni bien tengo algo que le agrega valor al cliente, se lanza al mercado y luego se van realizando las mejoras en función del comportamiento del producto en el mercado.

Ms. Winters plantea un tema clave al decir que Agile y Waterfall resuelven problemas diferentes. Waterfall pone el foco en resolver el problema: “¿Estamos entregando el proyecto en tiempo y dentro de presupuesto?”. Mientras que Agile está diseñado para resolver el problema: “¿Estamos entregando el producto correcto?”.  A través de la técnica del valor ganado, Waterfall mide variaciones de cronograma y variaciones de presupuesto, tratando de contestar la primera pregunta y Agile, a través de las demostraciones del producto y de las puestas en producción de productos que se van incrementando en sus funcionalidades y características, trata de contestar la otra pregunta.

Si tuviera que definir “Agile” con una sola palabra diría: “Escuchar”. Escuchar más al equipo, escuchar más a los usuarios, escuchar más al cliente y, en términos generales, escuchar más a todos los interesados. Se trata de escuchar para poder entender y mejorar.

Por último vale aclarar que los enfoques ágiles no son nuevos, solo el Manifiesto está por cumplir su mayoría de edad y podríamos remontarnos a los años 30 en donde Shewhart planteó ciclos iterativos para mejorar productos y procesos, siguiendo por Deming y las experiencias de organizaciones como NASA, IBM, Honda o Toyota que aplicaban prácticas que siguen un enfoque Ágil. Si quieren ir más lejos, tengan o no fe, pueden repasar el “Génesis” en el que se describe una creación que sigue un proceso “Agile” de lanzamientos que se van verificando e incrementando día tras día hasta llegar al séptimo.

Valores y Mitos

En el Manifiesto por el Desarrollo Ágil de Software se plantean 4 valoraciones relativas:

  1. Individuos e interacciones sobre procesos y herramientas.
  2. Software funcionando sobre documentación extensiva.
  3. Colaboración con el cliente sobre negociación contractual.
  4. Respuesta al cambio sobre seguir un plan.

Si bien el manifiesto aclara: “aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”, parece que nuestra tendencia a la neurosis (Blanco o Negro) nos lleva a la creación de 4 mitos asociados a los enfoques ágiles, que expongo a continuación:

  1. No hay gobierno, cada uno hace lo que quiere.
  2. No se documenta nada, la organización se queda sin ningún registro.
  3. El cliente no asume responsabilidades, cambia las reglas de juego todo el tiempo.
  4. No se planifica, nadie sabe qué esperar ni contra qué comparar.

Los enfoques ágiles tienen reglas claras pero son diferentes a las que estábamos acostumbrados a seguir. Los miembros del equipo tienen un alto grado de autonomía y participación en la toma de decisiones con relación a las tareas que hay que realizar para completar los entregables pero también tienen altos niveles relativos de responsabilidad. Esta forma de trabajo genera un mayor sentido de propósito en el equipo y por lo tanto, mayores niveles de involucramiento y productividad.

Los enfoques ágiles documentan, comparan lo previsto con lo real y obtienen lecciones aprendidas a través de diferentes instancias de retrospectiva, pero lo hacen en forma diferente a lo que estamos acostumbrados. En los enfoques predictivos estamos acostumbrados a realizar un alto grado de documentación de los planes, requisitos, construcción, pruebas e implementación mientras que en los enfoques ágiles la documentación es menos extensiva y ocurre en cada iteración. La documentación es considerada importante en la medida que ayuda entender que es lo que hay que hacer y cómo hay que hacerlo pero el contexto en donde se aplica este enfoque no es posible realizar una documentación completa de los requisitos cuando comienza el proyecto y se considera menos importante que contar con productos que funcionen y aporten valor al cliente permitiendo aprender y obtener retroalimentación para seguir mejorándolo.

Las reglas de interacción entre el cliente y el proveedor son claras, el cliente interacciona con el equipo con mucha frecuencia dando retroalimentación, todos se consideran parte del mismo grupo de personas que tiene un objetivo en común. Los enfoques ágiles son adecuados para entornos de negocio cambiantes donde se tiene claridad de visión respecto de lo que se quiere lograr, pero no hay una definición clara del alcance. Por lo tanto, un contrato realizado al comienzo del proyecto, con alto nivel de detalle no aporta valor a la solución. Por el contrario, es clave poder ir haciendo una lectura del mercado a medida que se van probando las soluciones generadas iteración tras iteración, para seguir avanzando.

En los proyectos que se aplica un enfoque ágil hay planificación pero en vez de realizar el esfuerzo de planificación mayor al comienzo del proyecto, las metodologías ágiles dispersan la planificación a lo largo del proyecto valorando mucho más la capacidad para adaptar el plan al contexto que a tener un plan exhaustivo y ejecutarlo a la perfección, sin desvíos. En el enfoque predictivo también hay cambios pero se procesan ante las solicitudes de cambio pero en los enfoques ágiles (por ejemplo, en Scrum) se revisa y prioriza la lista de temas a realizar constantemente ya que el cambio es inherente al modelo.

En Síntesis

No se trata de tener una perspectiva neurótica en términos de Personas o Procesos, Productos funcionando o Documentación, Colaboración o Contratos, Planificación o Adaptación al cambio. Sino más bien de entender cuál es la esencia del enfoque ágil (iterativo e incremental) y en qué casos y contextos aplica, en qué casos es preferible un enfoque predictivo y en qué contextos necesito un mix de enfoques para diferentes fases del proyecto.

 

*Ver: Why Agile is Failing at Large Companies; Geri Schneider Winters