Lo viejo y lo nuevo

 

Fuerzas instituidas e instituyentes en el desarrollo del Software

Cuando empecé a sumergirme en el mundo de la gestión de proyectos, una pregunta me dio vueltas en la cabeza desde el inicio: ¿Puede un PM ser realmente ágil si su equipo no lo es?

Esta duda me persigue cada vez que la palabra “cambio” aparece en escena. Durante la facultad, en una materia llamada Instituciones y los grupos en la universidad de Humanidades, aprendí dos conceptos que me marcaron profundamente: lo instituido y lo instituyente. Desde entonces, los aplico como lentes para observar cada proyecto o proceso en el que participo.

Para explicarlo mejor, lo traigo al mundo IT:
En muchos proyectos existen formas de trabajo instituidas, heredadas de mandos anteriores o rutinas que, si bien no son eficientes, son conocidas. Y lo conocido da seguridad. Por eso se sostienen. Es la famosa zona de confort organizacional, donde se privilegia evitar riesgos por sobre innovar.

Ahí es donde entra en juego lo instituyente: aparece un nuevo PM, o un CEO con hambre de mejora. Llega con visión de cambio, con ideas de automatización, optimización de riesgos, y foco en el éxito del producto. Es ahí donde choca lo nuevo con lo viejo. La intención de transformar contra la fuerza de lo ya establecido.

Y, por supuesto, ahí entra la palabra mágica: agilidad.

---

“Somos ágiles. Hacemos daily todos los días.”
— Escuchado en una reunión donde los entregables se gestionaban en una planilla de Excel llamada Urgente_final_2_real_ahora_SÍ_v2

---

La agilidad está de moda. Scrum, Kanban, XP, Design Thinking… todos quieren sumarse. Los post-its se reproducen como si fueran stickers de WhatsApp.
Pero hay una verdad incómoda: 🌟La agilidad no es un rol. Es una cultura.

Y si el equipo no la comparte, el PM se convierte en una especie de actor secundario con acceso limitado a Jira.

El PM que quiere, pero no puede

Podés tener al PM más comprometido del universo. Que arma retrospectivas en Miro, planifica sprints con criterio, y celebra entregas con GIFs de perritos en Slack.
Pero si los desarrolladores no se hacen cargo del producto, si QA vive apagando incendios, y si Producto cambia las prioridades como quien cambia de pestaña…
Houston, tenemos un waterfall con daily.

¿Qué dice la teoría?

Martin Fowler, uno de los firmantes del Manifiesto Ágil, lo resume así:

“Being agile is not about following a recipe, it’s about continuous learning and adapting.”

Y para que eso ocurra, todos tienen que estar en sintonía.

Ejemplo real:

Una startup implementó Scrum. Todo pintaba bien… hasta que los devs se negaron a participar de las retrospectivas (“eso es pérdida de tiempo”) y los stakeholders exigían releases “para ayer”.

😓Resultado: PM frustrado, equipo estresado, y el Scrum Master meditando en la cocina.

Pero sería ingenuo decir que con eso alcanza. Porque cambiar lo instituido no es un proceso mágico. Requiere trabajo, paciencia, acompañamiento, entrenamiento y —sobre todo— convicción.
Cuando se introduce agilidad, muchas veces aparece resistencia, confusión, entorpecimiento. Y ahí, el cambio se vuelve costoso. Tanto, que algunas empresas prefieren dar marcha atrás. Volver a ese método anterior que no era ideal… pero al menos, funcionaba.

Reflexión final

Si tu entorno no permite experimentar, si equivocarse se castiga, si la planificación es solo una excusa para imponer fechas, entonces no sos ágil.

Sos waterfall con daily👀