Cuando una empresa adopta métodos ágiles, lo primero que baja es el número de proyectos que llegan al comité de arquitectura. Nadie tomó esa decisión: los proyectos se partieron en piezas más chicas y dejaron de alcanzar el umbral de revisión. Esto trata de qué se rompió, y de las cuatro palancas con que el estándar O-AA lo repone.
«Las empresas que despliegan formas ágiles de trabajo reportan que el primer impacto visible sobre el gobierno de TI es una reducción en el número de proyectos que revisan los comités.»
O-AA §8.2La mecánica es sencilla y por eso pasa desapercibida. Al partirse en piezas más chicas, los proyectos dejan de administrarse como un todo, y esas piezas ya no alcanzan el tamaño mínimo que dispara una revisión.
Pero además cambian de naturaleza: dejan de ser proyectos y pasan a ser productos entregados por equipos ágiles. Y el gobierno clásico está armado alrededor de proyectos y programas revisados por comités — una estructura que, en palabras del estándar, resulta incongruente con formas de trabajo que ya no son centradas en proyectos.
El resultado es un punto ciego. El gasto en tecnología no bajó, las decisiones de arquitectura se siguen tomando todos los días, pero se mueven por debajo del radar. Nadie decidió dejar de gobernar: el umbral se quedó donde estaba y el trabajo se hizo más chico.
Hay un segundo efecto, menos comentado: como los equipos ágiles son multifuncionales y los encabeza un dueño de producto con criterio de negocio y de tecnología, el papel del gerente de proyecto pierde relevancia. Si el gobierno seguía anclado a ese rol, se queda sin interlocutor.
El estándar es inusualmente franco aquí. Empieza por constatar que el gobierno clásico no evita que los proyectos grandes fracasen, y cita dos casos de cientos de millones: una firma de servicios financieros que tuvo que matar un sistema de manejo de valores destinado a varios países europeos, y un banco que no logró consolidar dos plataformas core, descarrilando el caso de negocio de una fusión.
No son técnicas. Son de comportamiento, y por eso ningún rediseño de proceso las corrige:
· Miembros del comité que incumplen sus compromisos sin consecuencia.
· Decisiones contaminadas por luchas de poder o batallas de territorio.
· Gobierno ad hoc que debilita al gobierno establecido.
· Poca cooperación entre silos antes de que el comité decida.
· Miembros que influyen en decisiones sin ser responsables del
resultado.
Los integrantes del gobierno clásico no están lo bastante cerca de la operación. Suelen decidir sobre información de segunda mano que puede no reflejar la realidad actual.
Cuando la autoridad fluye de arriba hacia abajo, la dirección corre el riesgo de tomar decisiones no ancladas en la realidad: los problemas y las oportunidades reales quedan oscurecidos por la simplificación y la abstracción de los reportes. Y si la comunicación de abajo hacia arriba se reduce a estatus de proyecto discutidos en comité, se reducen las interacciones y aumenta todavía más la distancia entre la realidad y los pocos que mandan.
El estándar lo dice sin rodeos: el pensamiento de mando y control no es una forma efectiva de alinear equipos autónomos, porque las decisiones defectuosas que bajan desde arriba van a chocar con ellos.
De ahí una advertencia que conviene leer dos veces: el gobierno ágil no debe sustituir un giro verdadero de la empresa hacia lo ágil. Cambiar el reglamento del comité sin cambiar nada más es maquillaje.
No se trata de quitar el gobierno, sino de cambiar con qué se alinea. El estándar plantea cuatro palancas para alinear equipos autónomos sin agregar jerarquía.
El «norte verdadero»: la visión estratégica y filosófica de la organización. Incluye metas duras —ingresos, utilidad— y también objetivos de brocha gorda que apelan a la convicción. Sin un norte, la autonomía se dispersa.
Compartir un entendimiento fundamental y holístico del entorno de operación y de la propia organización, preservando al mismo tiempo las capacidades distintas de cada equipo. No es que todos sepan todo: es que todos vean el mismo tablero.
Lineamientos, restricciones, requisitos o compromisos que «fuerzan» o dirigen hacia un resultado deseable sin tener que administrar todos los detalles de cómo ocurre. Es la diferencia entre una norma que dice qué tareas hacer y una que expresa la intención de una política.
Mecanismos que ajustan el comportamiento de los equipos autónomos con evidencia y no con instrucción. Es también el axioma 3 del estándar: buscar ciclos rápidos para verificar los supuestos.
Debajo de las cuatro hay una idea que las sostiene: las organizaciones ágiles promueven autonomía y alineación al mismo tiempo. Lo hacen dando objetivos distintos a equipos autónomos y alineándolos sin introducir capas de jerarquía; estableciendo mecanismos formales para compartir que sincronizan conforme crece el número de equipos; y definiendo barandales de arquitectura que facilitan la autonomía justamente porque garantizan que los componentes vayan a ser compatibles entre sí.
A medida que los equipos ágiles se vuelven responsables de entregar y desplegar software que afecta directamente la experiencia del cliente, el alcance y el tamaño de la organización central de TI disminuyen. Según el estándar, lo que permanece en el centro es principalmente esto:
| Se queda en el centro | Por qué |
|---|---|
| Funciones corporativas | Estrategia de TI y la oficina de arquitectura |
| Infraestructura y operación | Entregan servicios a los equipos ágiles |
| Servicios transversales | Desde identidad federada hasta colaboración |
| Sistemas de alto cumplimiento | Obligaciones regulatorias o ante inversionistas |
Es una lista corta, y esa es la noticia. Si su área central sigue haciendo mucho más que estas cuatro cosas mientras sus equipos se declaran autónomos, hay una contradicción que se va a pagar en tiempo de espera. Vale además notar que la empresa digital no solo opera plataformas de infraestructura: también desarrolla y opera plataformas de negocio, y éstas necesitan su propio gobierno — reglas sobre quién participa y cómo se reparten costo y valor.
«Un modelo de gobierno por sí solo no puede arreglar problemas que están arraigados en el sistema social o en la cultura de la empresa.»
O-AA §8.1El estándar da los ejemplos, y son incómodos a propósito: cuando los miembros del comité no respetan sus compromisos; cuando los silos usan los comités de gobierno como campo de batalla política en vez de cooperar antes; y cuando los líderes encuentran «buenas razones» para no acatar las decisiones de gobierno.
De ahí la conclusión: el despliegue de un gobierno no será efectivo si no atiende los problemas del sistema social o de la cultura organizacional. Es una advertencia rara de encontrar en un estándar técnico, y es la razón por la que rediseñar el reglamento del comité casi nunca alcanza.
Por eso el gobierno no se puede tratar aislado. Es parte de un conjunto mayor que incluye el sistema social de la empresa y su organización — y por eso conecta directamente con el axioma 12, el de moldear la organización para que refleje la arquitectura.
Si reconoce su comité en esta página, la primera conversación no es sobre herramientas. Es sobre qué decisiones deberían dejar de subir, y qué barandales hay que poner para que eso no dé miedo.