Marc Löffler dio una breve charla sobre 7 mitos alrededor de Ágil: muchos existen en el mundo de los gerentes y líderes, pero otros tantos todavía persisten incluso dentro de desarrolladores y practicantes de Ágil. La documentación, la velocidad, la falta de control, y tantos más... desmitifiquemos Ágil juntos!
Ágil = no documentar
Este es uno de los mitos más famosos, y el culpable es el manifiesto Ágil. La línea que dice "el software que funciona por sobre la documentación exhaustiva" suele entenderse mal y pensarse como "sin documentación". Pero si esto fuera cierto, ¿cómo podrían sobrevivir implementaciones Ágiles como Scrum en ambientes muy estrictos como la medicina o la industria financiera? Obviamente que hay documentación, pero no desperdiciamos tiempo en documentos que no entregan valor al proyecto.
Ágil = anarquía
El mayor temor de cualquier gerente es perder control de sus equipos ágiles, porque creen que la auto-organización es igual a la anarquía. Es cierto que el rol de la gerencia cambia, pero siguen teniendo un papel fundamental en la empresa. Se los necesita para definir una visión y metas claras, y las restricciones de los proyectos. Recien dentro de estos "límites" puede trabajar un equipo auto-organizado. También se los necesita para ayudar al equipo a lograr su máximo potencial. Nada de esto tiene que ver con la anarquía.
Ágil = más rápido
En mi opinión fue una mala idea que Scrum llamara a sus iteraciones "sprints". Esto parecería indicar que todo ocurre muy rápido en Ágil. Pero, al menos al principio, ocurre justo lo opuesto. Agregarle calidad a un producto lleva tiempo, y la calidad no se discute. Vamos a recolectar los frutos más tarde a medida que tengamos menos bugs y el software sea más mantenible; allí es donde ágil comienza a generar velocidad.
Ágil = bala de plata
No existe la bala de plata en el desarrollo de software. Lo repito: no existe la bala de plata en el desarrollo de software. Seguro, el proceso del desarrollo de software tiene algún impacto, pero al final lo que realmente importa son las personas del equipo. Vi productos geniales creados por "equipos en cascada", y productos horribles creados por equipos ágiles. Al final de cuentas, todo se resumen a las pesronas correctas en el lugar correcto, o como lo dice el manifiesto ágil: las personas y sus interacciones por sobre los procesos y las herramientas (y esto también aplica a Scrum, Kanban, XP, y otros procesos).
Ágil = cambio simple
Para decirlo rápido: no es simple. El marco de trabajo en si mismo puede explicarse en 10 minutos. Pero lo que suele olvidarse es la mentalidad y los principios subyacentes sobre los que se basa (pensamiento Lean, Pull vs Push, control empírico de procesos, iteraciones e incrementos, auto-organización...). En las empresas más grandes, puede llevar años hasta que se pueda hablar de una empresa Ágil. No es suficiente enviar a un equipo a un entrenamiento de ScrumMaster de 2 días.
Ágil = fácil
¿Cómo podría resultar facil entregar un producto potencialmente productivo cada 1 - 4 semanas? En el pasado no lográbamos hacer esto en 1 año. Lleva mucho trabajo llegar a esta meta, y no es facil lograrla. Y ni siquiera estamos mencionando al despliegue continuo...
Ágil = desarrollo de software
A menudo el viaje ágil comienza con el desarrollo de software, pero no debería detenerse aquí. Tener un equipo de desarrollo Ágil en un entorno no-ágil es como plantar un árbol en el desierto: no va a sobrevivir. La cultura de la empresa entera tiene que cambiar, todos necesitan adherir a los principios del manifiesto. Sino, la transición ágil va a terminar en un callejón sin salida y con mucha frustración.
¿Qué otros mitos ágiles conocen? ¿Qué experiencias tienen con estos mitos?
