Existe una excusa frecuente con la que me encuentro dentro de organizaciones que están en proceso de adoptar técnicas ágiles de desarollo, que se conoce como el anti-patrón "Somos especiales". Las personas involucradas creen que su situación es especial, que hay un factor único en su entorno que hace completamente imposible adoptar técnicas ágiles, y por lo tanto necesitan continuar trabajando de la manera que lo hacen, sin importar que tan obviamente ineficiente sea.
La organización comienza a sufrir a este anti-patrón ágil cuando empiezan a dar excusas relacionadas con el dominio o la tecnología de su negocio, explicando porqué no pueden ser ágiles. Por ejemplo, escuché a empleados bancarios decir que "Ágil funciona bien para sitios web, pero nosotros estamos construyendo sistemas financieros y por lo tanto ágil no nos sirve"; empleados de empresas de telecomunicaciones que dicen "Ágil funciona bien para construir sistemas financieros, pero nosotros construimos sistemas embebidos y por lo tanto ágil no nos sirve"; y a empleados del gobierno decir "Ágil funciona bien para sistemas embebidos, pero nosotros construimos sitios web y por lo tanto ágil no nos sirve". Demás está decir que cuando escucho esto pienso "ahí vamos de nuevo...".
La realidad es que el dominio de negocio con el que estés trabajando no condiciona la habilidad para adoptar estrategias ágiles. He visto proyectos ágiles exitosos en bancos, aseguradoras, industrias de manufactura, empresas famaceúticas (si, con aplicaciones críticas de vida), empresas de telecomunicaciones, y agencias del gobierno. También conocí a personas trabajando en estos dominios que dicen que ellos son especiales por los desafíos específicos de su dominio.
A su vez, la tecnología tampoco es un impedimento. Trabajé con equipos que aplicaron enfoques ágiles con éxito usando Java, Visual Basic, COBOL, C, Linux, Windows, System Z, PCs, y mucho más. Seguro que algunas tecnologías antiguas no tienen gran cantidad de "herramientas ágiles", pero con algo de búsqueda en Internet siempre es posible encontrar algunas buenas herramientas de software libre (y por otro lado, ¿qué te detiene a empezar un proyecto así?).
Los principales impedimentos para la adoptación ágil son culturales. ¿Podés ser más flexible en la forma de pensar? ¿Podés ser más disciplinado (Ágil requiere de mucho más disciplina que los métodos tradicionales)? ¿Podés construir un entorno colaborativo con los interesados en el negocio? ¿Podés alejarte de los procesos burocráticos hacia aquellso que se enfocan en agregar valor real? ¿Podés invertir en tu equipo de IT para lograr las habilidades de desarrollo modernas que se necesitan para hacer TDD, integración continua, y técnicas ágiles de bases de datos (sólo por mencionar unas pocas)? La parte dificil de avanzar hacia ágil es superar estos "impedimentos humanos", estos impedimentos culturales.
Si estás buscando excusas válidas sobre porqué tu organización no puede avanzar hacia ágil, acá hay algunos impedimentos válidos que suelen sufrir las organizaciones:
- Nuestra Oficina de Gestión de Proyectos (PMO - Project Management Office) está capacitada y certificada en estrategias tradicionales y no logra entender las técnicas ágiles para la gestión de proyectos.
- No tenemos el presupuesto para capacitar, educar y guiar a las personas en técnicas ágiles.
- La gerencia intermedia se siente amenazada por las estrategias ágiles porque su rol claramente va a cambiar.
- El equipo técnico senior, en particular los arquitectos, no aceptan la necesidad de empezar a trabajar e involucrarse activamente en los proyectos de los equipos.
- Nuestros esfuerzos en el gobierno de IT no es efectivo y está fuera de control, enfocándose en la burocracia en vez de ayudar a que los equipos de desarrollo tengan éxito.
- Nuestro equipo de gestión de datos insiste en trabajar de una forma seriada y basada fuertemente en la documentación.
- Nuestro equipo de QA/testing insiste en tener especificaciones de requerimientos detalladas.
- Nuestro equipo está sobre-especializado, lo que resulta en constantes "préstamos" de analistas, diseñadores, desarrolladores, arquitectos, testers, etc.
Y esta lista es sólo la punta del iceberg. El punto es que los problemas reales a enfrentar son culturales, y no tienen nada que ver con el dominio o la tecnología. Es posible superar estos impedimentos al éxito, pero primero debemos entender que los sufrimos, cuales son las consecuencias, y cómo los vamos a superar.
Entonces, el primer paso fundamental es asumir que NO somos especiales, y que por lo tanto tenemos un arduo camino por delante para mejorar nuestro trabajo en IT. Y esto si resulta motivante, porque nos libera de la trampa del "somos especiales": ¡Podemos recorrer ese camino para aprender y mejorar!