La agilidad no es burocracia

“La burocracia mata a las organizaciones”

Al terminar la frase el expositor, el joven Cristino la anotó en su libreta dejando de lado todo lo que pudiera distraerlo.

Era una conferencia que le habían enviado, un proveedor de BancoT que les apoyaba con gestión de proyectos, les compartió dos entradas para dicha conferencia, con un gurú en estos temas, para Cristino era un mundo nuevo, algo que se enteró era muy famoso en muchos lados: La AGILIDAD o <<agile>> en inglés como le llamaban la mayoría de las personas.

Le vendieron que era la panacea para gestionar los proyectos, alinear expectativas y responder a un mundo cada vez más cambiante, el joven CTO estaba asombrado.

El lunes de regreso a BancoT, encontró “coach agiles”, tal era la denominación que les daban, apoyando en las diferentes iniciativas de la organización, un mundo de conceptos surgió para Cristino.

“La agilidad no es burocracia”

La reunión había empezado con esta frase, tenía la total atención de Cristino, sus dos empleos anteriores, estaban llenos de reuniones interminables, de llenar documentos de requerimientos, procesos burocráticos para pasar de desarrollo a pruebas y luego a producción, muchas autorizaciones para firmar, había que andar buscando las aprobaciones de mucha gente, y pobre de ti, si algo salía mal, tenías que regresar por todo ese proceso, explicando lo que había pasado, ahora con estas ideas tan interesantes, un nuevo mundo se abría ante sus ojos.

Los meses pasaron, poco a poco, Cristino entendía los procesos, ceremonias (le corregían) tenía la curiosidad de por qué siempre le corregían, como si les gustará mucho usar el término correcto, aunque no fueran tan estrictos en los procesos, le encantaba el manifiesto ágil, pero sentía que en la práctica … dejaba mucho que desear.

Scrum es una metodología, había dicho alguna vez, la discusión que siguió posterior al comentario, les tomo varias horas, los coach agiles, dijeron que era un marco de trabajo no una metodología, se devanaron los sesos en dar explicaciones (a modo de dogma, sintió Cristino) para dejar clara la definición, que decidió usarla, para evitar complicaciones, sin tener claro, por qué debía “tener clara” la definición

– Debe ser un área de oportunidad de este coach ágil, en específico – pensó

Una de las “ceremonias”, en su mente y pronunciación siempre lo entrecomillaba, es que al ser joven le sonaba a religión = dogma.

Una de esas “ceremonias”, qué mas incongruencia tenía casi en todas las ocasiones, era el Daily Scrum la una reunión diaria de 15 minutos en la que participa exclusivamente el Development Team”, les habían dicho.

Era rara, por muchas razones:

  1. No solo estaba el equipo de desarrollo
  2. Nunca duraba 15 minutos
  3. Y querían que fuera de pie (“Standup Meeting”)

Pero como era remota … ¡pues nunca era de pie!

Y en esencia, entendía el proceso, hasta que pasaron tres eventos que cambiaron todo el panorama de entendimiento de Cristino.

Primero: Kanban como herramienta de visibilidad de trabajo sobre carga de trabajo y capacidad instalada (con desperdicio incluido)

Segundo: PI Planning como ceremonia trimestral sin avisar que SAFe aparecía saliendo de Scrum

Tercero: Burocracia con un disfraz para verse esbelta (chiste lean), se urgía por el proveedor tener todas las “ceremonias”, no podía faltar ninguna, entonces ¿Eso no era burocracia?

Pero la gota que derramó el vaso, se habló de Large-Scale Scrum (LeSS) y Disciplined AgileDelivery (DAD), alguien agregó, OKR no más KPI por favor, estamos evolucionando y empezó una nueva discusión de las diferencias entre una y otra estrategia, idea, marco de trabajo o metodología, a estas alturas, le daba miedo a Cristino que palabra usar para cada concepto, ya que podía desencadenar otra discusión innecesaria.

Luego de unos días, de pensar en estos temas, llegó a una conclusión fruto de la observación.

“En las reuniones, un porcentaje del tiempo se usaba para explicar conceptos o <<dejarlos claros>> en lugar de la planeación, ejecución y seguimiento de procesos de la organización”

Y recordó algo del manifiesto ágil, que tanto le había gustado:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

¿Hasta dónde seguir un manifiesto o marcos de trabajo se contraponen?

¿Si gestionamos de manera ágil nuestros proyectos, somos una organización ágil?

¿El objetivo es gestionar de manera ágil o ser una organización ágil?

Pero esas reflexiones, de un joven CTO, dan para muchas otras historias…