No se es ágil... con una cascada ágil
Muchas organizaciones se describen a sí mismas como ágiles. ¿Quién no querría ser ágil? Si no eres ágil, ¿no eres por definición pesado, lento y torpe?
Pocas organizaciones se describirían así; sin embargo, Agile en el mundo del desarrollo, mejora y mantenimiento de software significa más que poder actuar rápido y ligero. Agile significa que un equipo u organización adopta ciertos principios que moldean comportamientos y llevan a interiorizar ciertos métodos.
Cuando no se actúa como se afirma, frecuentemente la dirección se interpone en el camino de los principios y los profesionales en el de los métodos. Los métodos en las organizaciones suelen estar muy arraigados y requieren un esfuerzo de cambio considerable. Algunas organizaciones afirman utilizar un enfoque mixto y pasar de un enfoque más clásico a una combinación de Scrum, Kanban y Extreme Programming. Esto se considera un enfoque seguro y conservador que permite a una organización cambiar de forma orgánica. Sin embargo, el problema es que esta táctica rara vez funciona y las organizaciones se estancan rápidamente. Cuando no se invierte suficiente tiempo y esfuerzo en la gestión del cambio, esto lleva rápidamente a frameworks híbridos que no son ni una cosa ni otra, y estos solo muy raramente son ágiles.
Señales de organizaciones estancadas (o potencialmente estancadas)
La cascada iterativa:
La clásica cascada iterativa tiene sus raíces en el modelo espiral de Barry W. Boehm. En esta pseudoversión del desarrollo iterativo, se utilizan iteraciones cortas y limitadas en el tiempo para cada una de las fases clásicas de cascada. Un Sprint de requisitos es seguido por un Sprint de diseño, luego un Sprint de desarrollo, etc. Tanto el modelo espiral clásico como la pseudoversión de Agile son, sin embargo, mucho mejores que el modelo clásico de cascada para generar feedback y entregar valor más rápidamente; no obstante, las organizaciones dejan de evolucionar hacia Agile y solo cosechan una parte de los beneficios.
Definir requisitos por adelantado:
En este enfoque híbrido de Agile, los equipos u organizaciones recopilan todos los requisitos (a veces llamados features) al inicio del proyecto y los fijan antes de que comience el trabajo real. Agile se basa en ciertas suposiciones respecto a los requisitos. Dos de las suposiciones principales son que los requisitos surgen continuamente y que, una vez conocidos, desaparecen con el tiempo. Es una contradicción con estas dos suposiciones fijar los Product Backlogs de antemano. Además, lleva a los equipos y organizaciones de vuelta a una época en la que se desarrollaban soluciones que al final no correspondían a las necesidades actuales del negocio. Este enfoque existe principalmente cuando la introducción de Agile se realiza de forma escalonada, empezando con los desarrolladores e incorporando después a los Business Analysts, etc. Entre los grupos que han interiorizado Agile y aquellos que no, puede surgir fricción adicional, lo cual frecuentemente se achaca a los métodos ágiles y así dificulta más cambios.
Probar después de que el desarrollo esté "done":
Una de las formas híbridas ágiles más peligrosas es probar después del desarrollo completado. He conocido esta forma híbrida bajo el nombre de "Desarrollo + 1 Sprint". En este escenario, un equipo desarrolla una solución (código funcional en un problema de software), lo demuestra a los clientes, afirma que está "done" y ENTONCES lo pasa a los testers. Los testers SIEMPRE encuentran algo. Por eso el software se devuelve para trabajar directamente en él (lo que interrumpe el Sprint actual) o mover todo al Backlog para ocuparse de ello más tarde. Los principios ágiles apoyan la finalización de software entregable (o al menos potencialmente entregable) al final de cada Sprint. Entregable significa TESTEADO. Dos variantes no tan dramáticas de este problema son el uso de Hardening Sprints y probar al final de un proyecto. Al menos en estos casos no se afirma ser ágil.
Conclusión sobre Agile y cascada
La forma en que las personas trabajan es el único indicador seguro de si una organización es ágil o no. A veces la forma de trabajar de estas personas refleja un cambio hacia Agile; sin embargo, asumo que pronto se estancarán si este cambio no se realiza con gran empeño. Si un equipo o una organización quieren adoptar Agile, se selecciona un proyecto y se hace que todos los involucrados en ese proyecto trabajen con Agile simultáneamente y durante todo el flujo de trabajo. Si eso significa que hay que hacer coaching a todo un proyecto o todo un equipo, pues así será. Este enfoque se puede comparar bien con una cebolla que se corta en rodajas, alcanzando cada capa con cada corte, en lugar de pelar capa por capa.
Una última nota: aunque con estos enfoques híbridos se llega a un límite en algún momento, probablemente siguen siendo mejores que el/los método(s) utilizados anteriormente. Esto no pretende ser una acusación contra las personas que tienen problemas para cambiar a Agile. Más bien pretende ser un impulso para que continúen.
Este texto proviene del blog de SPamCAST y fue traducido al español.
