Tengo prácticamente listo un artículo sobre cómo mejorar la agilidad empresarial con Team Topologies, pero decidí posponerlo para leer la nueva edición del libro que, por cierto, ya ha salido y me está gustando. Mientras tanto, pedí ayuda a mi red en LinkedIn para escoger tema: podía hablar de desarrollo de producto, de Wardley Mapping o de qué estoy haciendo ahora. Y la opción más votada fue precisamente esta última. Así que aquí va el resultado, contado sin saltarme ninguna cláusula de confidencialidad. Espero. 😅
No es la primera vez que trabajo para una organización grande, con muchos departamentos, roles difusos y procedimientos que no siempre encajan entre sí. Esa experiencia de años me ha enseñado a no esperar un terreno despejado, sino a ir leyendo el contexto para decidir dónde tiene sentido intervenir y dónde lo más inteligente es no estorbar. Hoy desempeño el rol de Scrum Master en un área de la compañía llamada Digital Platform, un trabajo en el que procuro combinar la cercanía —estar muy pegado a la parte operativa y también a las personas, independientemente de su rol— con una visión estratégica que favorezca la agilidad de todos.
He llegado en plena transformación
Digital Platform está en medio de una transición. Durante años, su foco principal ha consistido en sostener la infraestructura sobre la que se despliegan muchas de las aplicaciones clave de la compañía. Ahora, además, impulsa la construcción de una Digital Experience Platform (DXP), lo cual amplía el alcance mucho más allá del soporte técnico.
En este contexto conviven equipos que trabajan en la migración de páginas web desde sistemas previos hacia soluciones más modernas, otros que desarrollan un sistema de diseño, o los que coordinan despliegues y cambios críticos para que todo siga funcionando de forma segura y consistente. Puede parecer invisible desde fuera, pero el trabajo de Digital Platform evita que cientos de desarrolladores tengan que ocuparse de estas tareas de manera descoordinada, con la complejidad y el riesgo que eso supondría. Esta posición, tan transversal como estratégica, explica por qué su transformación es clave dentro de esta compañía: una gran aerolínea.
¿Qué es eso de DXP?
El concepto de Digital Experience Platform (DXP) es la respuesta a una cadena de necesidades crecientes. Al principio bastaba con los Content Management Systems (CMS), diseñados para crear y publicar páginas de manera sencilla. Pronto se vio que no era suficiente: había que personalizar contenidos, incorporar analítica y coordinar distintos canales, lo que llevó al surgimiento del Web Experience Management (WEM). Pero también WEM se quedó corto, porque las organizaciones necesitaban que todo esto estuviera conectado con sus datos, servicios y procesos internos.
De esa evolución surge el concepto de DXP: un entramado de tecnologías que no sólo gestiona contenido, sino que integra lo necesario para ofrecer experiencias digitales consistentes y personalizadas a través de los múltiples canales de la compañía. En el caso de Digital Platform, el objetivo no es adoptar un producto cerrado, sino construir su propia plataforma sobre la que se apoyen las distintas iniciativas digitales de la compañía. Esto explica por qué el área es tan transversal. En una aerolínea, la experiencia digital está en casi cada punto de contacto con el cliente: desde buscar un vuelo hasta recibir notificaciones sobre un embarque.
Mi rol
Yo no estoy implicado directamente en los detalles de lo que construyen los equipos. Mi papel no consiste en entender cada aspecto de la experiencia digital ni de la infraestructura que la soporta: eso lo saben mucho mejor los equipos especializados en cada parte de la cadena de valor. Yo sólo me centro en cómo trabajan.
En una misma semana puedo estar hablando de flujos de despliegue, revisando la planificación de un sistema de diseño o creando una automatización en Jira. Aunque los focos varían, hay un hilo conductor: los procesos. Me interesa mucho cómo se coordinan, cómo resuelven dependencias, o cómo se enfrentan a la complejidad del día a día. No me preocupa tanto qué hacen, sino cómo lo hacen. Esa perspectiva me permite moverme entre contextos muy distintos sin necesidad de convertirme en especialista de cada uno, y a la vez aportar valor ayudando a que los equipos encuentren mejores maneras de colaborar.
Aunque todo agilista dirá que lo importante son las personas y sus interacciones, yo prefiero fijar la atención en los procesos. Porque son ellos los que marcan el terreno de juego, los que facilitan o entorpecen las interacciones y, en última instancia, los que hacen posibles ciertos comportamientos y bloquean otros.
Donella Meadows lo expresó con claridad al hablar de sistemas:
Si queremos entender los fallos más graves de los sistemas, tendremos que prestar atención a las reglas y a quienes tienen poder sobre ellas.
— “Thinking in Systems” (Edición en español: “Pensar en Sistemas”, Capitán Swing)
Dejo aquí apenas la semilla. En otro artículo me meteré de lleno en este debate.
Entre irritar y acompañar
Justo debido a este enfoque, cuando llego a un nuevo entorno, lo primero que hago no es cambiar cosas, sino observar. La experiencia en empresas grandes me ha enseñado que los equipos viven bajo una maraña de dependencias y procesos heredados, y que mi papel como Scrum Master empieza por distinguir lo que es ruido de lo que es realmente un bloqueo.
Mi caja de herramientas es amplia: talleres, documentación, configuración de Jira, métricas, conversaciones incómodas… Todo lo que sé hacer lo pongo al servicio de una idea sencilla: incomodar lo justo para identificar los problemas y ofrecer alternativas viables para mejorar. Hace ya muchos años escribí sobre irritar al sistema, y aún hoy sigo practicando ese arte parecido al funambulismo: un equilibrio constante entre provocar y acompañar, entre hacer visible la incomodidad y no detener el avance. Irritar para movilizarnos, pero sin romper la cuerda por la que caminamos.
Hace años me inclinaba más por transformaciones radicales. Con el tiempo, trabajando en organizaciones grandes, he descubierto que lo más efectivo suele ser apostar por pequeños cambios que generan dinámicas positivas y que otros pueden extender al resto de la organización. Ay, el viejo debate entre kaizen y kaikaku. 😅
Por cierto, en Reparando en vuelo describo cómo enfoco ahora la transformación de una organización cuando no hay margen para parar máquinas, aprendiendo a mejorar mientras se sigue avanzando. Ésa es la forma en la que entiendo hoy la agilidad empresarial: no como grandes gestos, sino como la capacidad de ajustar el rumbo sin detener la marcha.
Y hasta aquí por ahora
A estas alturas quizás te preguntes qué papel juego yo en todo esto. Me gusta mucho recordar que mi puesto no tiene poder, pero sí influencia: no soy jefe de nadie, y por tanto no puedo decidir qué deben hacer los demás, aunque sí aspiro a modificar mi entorno para que suceda lo que debe suceder. Para explicar esto, me gusta recurrir a una imagen sencilla: soy una especie de acompañante del grupo con una linterna en la mano. No marco la ruta; sólo alumbro lo que tenemos delante para que el equipo vea mejor dónde pisa y pueda elegir con menos miedo.
Alguna vez me han comparado con un sherpa, pero esa metáfora no me termina de encajar. Demasiada épica para mi gusto. Y la épica, en el trabajo, suele ser postureo: grandes gestos que esconden más vanidad que resultados. Yo prefiero algo más discreto. La linterna no promete hazañas, solo claridad. Y en entornos llenos de incertidumbre, ya es bastante.
Y hasta aquí este “qué estoy haciendo ahora”. Gracias por acompañarme en este recorrido. El siguiente artículo será ya el que tenía en mente sobre cómo mejorar la agilidad empresarial con Team Topologies, y después vendrá la reseña de la segunda edición del libro, que estoy disfrutando y creo que merece dedicarle espacio propio.
LA FOTO: La linterna que ilumina el camino como metáfora de mi manera de abordar mi trabajo.
Foto de Subhro Vision en Unsplash