Ver el mundo como una sucesión de acontecimientos es increíblemente apasionante, y nunca deja de sorprendernos, porque esa visión del mundo no posee prácticamente ningún valor predictivo ni explicativo. Al igual que la punta de un iceberg que sobresale del agua, los sucesos son el aspecto más visible de un complejo mayor, pero no siempre son lo más importante. — Donella Meadows. Pensar en sistemas
«El día a día nos consume» es una de las frases que más peligro entraña en una organización. Cuando alguien dice esto suele significar que no alcanza a solucionar lo que llega a su bandeja; se pasa el día en piloto automático trabajando con su sistema de pensamiento rápido y reactivo1. Esto puede suceder no solo a nivel individual, puede también manifestarse en la capacidad del equipo o de la organización para detenerse y analizar un tema en profundidad en lugar de dejarse llevar por la inercia.
Cuando el día a día nos come notamos síntomas de que algo no va bien y, como mucho, tratamos el síntoma sin entender profundamente la causa raíz. Es como tomar un ibuprofeno sin saber de dónde viene la fiebre, en algún momento la causa raíz podría matarnos.
En mi experiencia, muchas veces ese «no nos alcanza el tiempo» es autoimpuesto. Priorizamos hacer dos cosas en lugar de una, o sentimos la urgencia de resolver algo hoy cuando sería aceptable hacerlo dentro de dos meses. Lo hacemos porque el ciclo de recompensas es más inmediato. Esa necesidad de chutes de dopamina por acción y épica combinado con la falta de costumbre de pensar de manera lenta (slow thinking2), a largo plazo y sistémica, son algunas de las principales causas que nos empujan a este círculo vicioso de reactividad.
Ya en la entrega anterior escribí sobre la «trampa de la adicción al parche» y lo difícil que es salir de ella. Hoy escribiré sobre una de mis herramientas favoritas para salir de este círculo vicioso: el modelo del Iceberg.
El Modelo del Iceberg
Un iceberg es una gran masa de hielo que se ha desprendido de un glaciar o de una capa de hielo y que flota en agua abierta. Lo interesante de los icebergs es que la mayor parte de su masa y volumen (generalmente alrededor del 90%) está sumergida bajo el agua, mientras que solo una pequeña porción es visible sobre la superficie del agua.
Edward Hall propuso en su obra Beyond Culture el modelo del iceberg como un modelo mental para describir cómo elementos visibles y ocultos de la cultura interactúan y conforman la experiencia humana. Desde entonces ha ido evolucionando su uso y estudiosos del pensamiento sistémico lo han estado utilizando como una herramienta para abordar problemas de organizaciones o ecosistemas3.
Este modelo es especialmente útil cuando te das cuenta de que una mentalidad reactiva y limitante está frenando el progreso del equipo por no ver más allá.
El modelo divide el iceberg en cuatro niveles que veremos a continuación: eventos, patrones o tendencias, estructuras y modelos mentales.
Eventos
Este nivel, según la metáfora del iceberg, corresponde a la parte visible. Aquí se encuentran los síntomas o eventos directamente perceptibles del problema a tratar. Normalmente detenemos nuestro análisis aquí y reaccionamos, pues ir más profundo requiere un esfuerzo deliberado de «slow thinking». Por ejemplo, podría tratarse de un despliegue fallido, dos miembros del equipo discutiendo acaloradamente, la web va lenta, o el incumplimiento de un compromiso de entrega.
Patrones o Tendencias
Este nivel está justo en la superficie. A veces somos capaces de notar patrones sin demasiado esfuerzo, sobre todo si los eventos han ocurrido con una alta cadencia y en un período reciente. Por ejemplo, es la tercera vez que sale mal un despliegue en la última semana. Pero a veces es difícil encontrar estos patrones sin hacer un análisis deliberado. Por ejemplo, puede que la web lleve una tendencia de ir cada vez más lenta pero con incrementos imperceptibles a no ser que mires un período largo o que haya un patrón que sólo va lenta el segundo martes de cada mes.
Estructuras
Ya más profundo tenemos las estructuras que causan los patrones, normalmente políticas, reglas, limitaciones, restricciones, rituales, interdependencias entre equipos o componentes, flujos de trabajo, arquitectura del sistema, etc. Por ejemplo, la web va lenta el segundo martes de cada mes porque coincide con una newsletter que se envía ese día, que además coincide con el día que se hace un reindexado de una base de datos de la que depende.
Modelos Mentales
Este es el nivel más profundo de todo sistema. Aquí subyace nuestras creencias, valores, principios, expectativas, los paradigmas y la cultura de la organización. Por ejemplo podríamos tener un problema de descoordinación entre equipos o desalineamiento de objetivos, en el caso de la web lenta podría ser que el equipo de marketing y producto estén totalmente aislados. También puede ser que no haya una cultura de experimentación y aprendizaje y esos incidentes no generen análisis de causa raíz.
Ejemplo
Simplifico enormemente el contexto de un equipo de desarrollo cuyos principios y prácticas distan de las recomendadas por Lean y eXtreme Programming.
Eventos
¿Qué acaba de pasar?:
En el último sprint, 3 de las 5 historias de usuario que llegaron a producción tuvieron que revertirse debido a bugs.
Si solo nos enfocamos en esta capa para solucionar el problema, podemos atacar este síntoma a ciegas sin entender la causa más profunda, es decir, solucionando los bugs o despidiendo a las personas que los introdujeron.
Patrones
¿Cuál ha sido la tendencia en el tiempo?:
Existen oscilaciones entre sprints dedicados al desarrollo de funcionalidades y sprints completamente enfocados en solucionar fallos de sprints anteriores.
Un análisis a este nivel indica claramente un problema recurrente; los intentos de abordar el síntoma solo modifican temporalmente la forma y la frecuencia de las oscilaciones del problema, que inevitablemente reaparece. Una solución provisional podría ser informar al equipo de customer success para que estén más atentos durante los sprints de despliegue de nuevas funcionalidades. Sin embargo, si no profundizamos para entender las causas de estos problemas recurrentes, estamos actuando como si simplemente diéramos el pronóstico del tiempo: «sacad el paraguas que viene lluvia y no hay nada que podamos hacer para cambiarlo».
Estructura
¿Qué ha influenciado estos patrones? ¿Cuáles son las relaciones entre las partes?:
Los sprints duran 30 días, durante los cuales se acumulan cambios que se despliegan al final.
No hay pruebas automatizadas, se realiza QA manual antes del despliegue.
A este nivel, podemos intervenir modificando la frecuencia de los sprints, invirtiendo en la automatización de pruebas, adoptando prácticas como pair programming o realizando revisiones de código.
En el mundo físico, cambiar las estructuras es una de las palancas más difíciles de mover, imagina tener que modificar el sistema de carreteras para mejorar el tráfico. Afortunadamente, en nuestro entorno digital la mayoría de las estructuras son modificables, aunque no por ello no deja de ser complejo. El coste de implementar pruebas automatizadas puede ser alto, y a veces el temor a introducirlas se justifica si el problema real requiere un cambio de paradigma, como adoptar prácticas de XP o Lean.
Modelos Mentales
¿Qué creemos, damos por sentado o presumimos acerca de esta situación?:
No se despliega frecuentemente porque es tedioso y manual.
No se automatiza el despliegue porque se percibe que retrasa el desarrollo de nuevas funcionalidades.
No se desarrollan tests porque se considera que retrasan el desarrollo y son más costosas y menos seguros que realizar QA manual.
Como ya mencioné en el nivel de estructuras, cambiar en ese nivel a menudo no es suficiente si no se acompaña de un cambio de mentalidad sostenible en el tiempo. Este es el nivel más difícil de cambiar y cualquier intento de hacerlo debe abordarse con una perspectiva a largo plazo.
Por ejemplo, podemos formar al equipo para que adopte los valores, principios y prácticas de eXtreme Programming. Este proceso implica un cambio profundo de mentalidad y práctica, lo cual probablemente requerirá la asistencia de un coach técnico y varios meses de trabajo.
¿Cómo usar este modelo?
El modelo del iceberg es una herramienta poderosa para mejorar tu razonamiento a la hora de presentar propuestas de mejora. Al profundizar en las circunstancias, podrías descubrir interconexiones que te habías perdido. Incluye estos hallazgos en las razones que fundamentan tus propuestas.
Diana Montalion en su libro Learning Systems Thinking sugiere las siguientes preguntas para guiar la elaboración de una propuesta de mejora:
¿Cómo sabes que algo está ocurriendo? ¿Cuáles son las señales de que una idea, acción o teoría es necesaria?
¿Es esta una circunstancia única o parte de un patrón a lo largo del tiempo?
De ser así, ¿qué mantiene este patrón en su lugar? ¿Cuáles son las relaciones que lo fomentan o lo desalientan?
¿Cuáles son las suposiciones, creencias o valores que apoyan o contribuyen a este patrón? ¿Qué valores o creencias desafía tu recomendación?
En términos generales, las recomendaciones que cambian creencias fundamentales, los modelos mentales básicos, tendrán un impacto más positivo que aquellas que reaccionan a un evento. Si puedes llevar tu recomendación hacia niveles más profundos en el modelo del iceberg, contribuirás con más valor.
— Diana Montalion
Esta herramienta puede utilizarse individualmente, pero lo ideal es involucrar al equipo desde el inicio y abordar el análisis de manera colaborativa. Una opción muy práctica es usar la plantilla Iceberg Reflection en Miro, aunque básicamente apenas necesitas una pizarra real o virtual para dibujar los cuatro niveles, pegar post-its y debatir.
Según la complejidad y la importancia del asunto a analizar, es probable que necesitemos varias sesiones. A medida que profundizamos será más difícil llegar a conclusiones claras. Para identificar patrones, deberemos recolectar o consultar datos; en algunos casos, incluso puede ser necesario comenzar a medir datos desde cero. Al analizar las estructuras, necesitaremos mapear el sistema y asegurarnos de comprender la mayoría de sus componentes, flujos, bucles de retroalimentación, incentivos y propósitos; este proceso podría revelar la necesidad de involucrar a más personas en el ejercicio.
El nivel de los modelos mentales requiere un ejercicio de reflexión mucho más profundo, es aquí donde el trabajo en equipo realmente agrega valor. En esta fase, el trabajo asíncrono puede ser especialmente útil para avanzar hasta la próxima sesión.
Siempre Trade-offs
A medida que descendemos en la profundidad del iceberg, pasamos de enfoques reactivos a enfoques proactivos de resolución de problemas. En la punta reaccionamos al presente, mientras que en las profundidades trabajamos con el futuro. Las soluciones en la superficie suelen ser tácticas y cortoplacistas, mientras que en las profundidades consideramos la estrategia y el largo plazo. Las evidencias tienden a ser más concretas y visibles a medida que nos acercamos a la superficie, en contraste con ser más abstractas y difíciles de discernir conforme descendemos.
Las herramientas y estrategias que requerimos se hacen más costosas y demandan más tiempo conforme profundizamos, lo que nos obliga a evaluar cuidadosamente cuándo y cómo utilizarlas.
Estos trade-offs evidencian que debemos encontrar el equilibrio adecuado entre las perspectivas según la importancia de los problemas y el contexto actual de la organización. Un enfoque excesivo en los eventos y en tratar solo sus síntomas puede llevarnos a puntos de no retorno y a ese «no nos da la vida» que mencionaba al inicio del artículo. Por otro lado, demasiado enfoque en las profundidades del iceberg puede resultar en «parálisis por análisis» e inmovilidad.
Mi recomendación es que si el asunto es de importancia, activemos palancas en varios niveles simultáneamente. Esto implica equilibrar la capacidad de responder de manera efectiva en el presente, mientras simultáneamente preparamos el terreno para desarrollar soluciones sostenibles y profundas en el futuro.
Si has llegado hasta aquí y crees que esta herramienta puede ayudar a otras personas, te agradecería que lo compartas. Además cualquier interacción con el artículo me da pistas de si estos temas son de interés 🙏🏼.
Ver nota 2 sobre «slow thinking».
El «slow thinking» o «pensamiento lento» es un concepto que se popularizó especialmente con el libro Thinking, Fast and Slow del psicólogo recientemente fallecido Daniel Kahneman.
Sistema 1 (Pensamiento rápido): Es automático, rápido, y no requiere mucho esfuerzo ni atención consciente.
Sistema 2 (Pensamiento lento): Es deliberativo, más lento y requiere esfuerzo cognitivo y atención consciente.
Se han realizado diversas atribuciones: Senge (1990, 1999), Kim (1999, 4), Donella Meadows (2009, 88), Dennis Meadows y Sweeney (2010, 243), Bryan, Goodman y Schaveling (2006), Cababa (2023, 139-143).