¿Cómo podemos modelar un sistema?

Equipo de miembros de un sistema modelándolo

System Thinking nos enseña que debemos de tomar una perspectiva holística de los sistemas y optimizar el todo. LeSS, el entorno de escalado Scrum, y SAFe®, el marco de escalado Lean-Agile, dan capital importancia a esta disciplina a través sus principios. Para ello System Thinking nos dota de herramientas como System Modelling que nos permiten desvelar el sistema y tomar decisiones adecuadas para su mejora continua.

Sin una herramienta adecuada los directivos y los responsables de la toma de decisiones pueden acabar aplicando su instinto con "soluciones de sentido común" y soluciones rápidas "incorrectas" que no crean una mejora del sistema que sea duradera. ¿Qué pretendemos? ¿Optimizar un equipo? o ¿que la compañía como un todo sea capaz de adaptarse a un mercado cambiante?

La mayoría de los sistemas de construcción de producto tienen un comportamiento no lineal a través de complejos circuitos de retroalimentación positiva y negativa. System Modelling nos desvela conocimiento sobre la dinámica del sistema, sus circuitos de retroalimentación o refuerzo, y nos permitirá encontrar y entender más fácilmente las causas de raíz de los problemas.

Como la mayoría de las herramientas de la Agilidad, el modelado se hace ante un tablero, y su parte esencial es la de tener conversaciones y debates para generar aprendizaje y una comprensión compartida. Su visualización se materializa en un diagrama fácil de ver que permite que las ideas sean concretas e inequívocas

Para empezar con el modelado comenzamos escribiendo en post-its las variables de nuestro sistema.

Elementos, las variables, que se escriben en post-its, y la notación de las flechas que representan sus relaciones

Para un sistema de construcción de software con Scrum un ejemplo de variables puede ser (y puede haber muchas más):

• velocidad
• #bugs
• calidad código
• #miembros del equipo
• presión para aumentar la velocidad
• #sprints
• retención de grandes profesionales
• habilidad para mejorar el mentoring
• #desarrolladores mediocres
• %código limpio
• %tiempo en codificación limpia
• %tiempo de resolución de bugs
• motivación del equipo

Empezamos pegando los post-it en un tablero y esbozamos las flechas con las relaciones entre las variables. Habrá, o debería de haber, mucha reescritura, borrado y redibujado durante la sesión de modelado. El resultado más significativo de esta fase es la comprensión del sistema.

Una vez llegado a las variables más representativas, para entonces se habrá minimizado la conversación y se habrá llegado a un alineamiento general, pasamos a buscar las sutilezas del sistema, los ciclos de refuerzo o retroalimentación negativa y positiva. Los ciclos de refuerzo son como bolas de nieve que podemos utilizar para impulsar o degradar el sistema.

Podemos encontrar ciclos de refuerzo positivo buscando ciclos con un número par de relaciones de efectos opuestos.

Ejemplo de un ciclo de refuerzo

En el ejemplo de la derecha hemos encontrado un ciclo de refuerzo del que podemos comprender que:

• Si aumentamos la presión para ser más rápidos, lo que realmente ocurrirá es que la velocidad disminuirá y la calidad del producto se degradará.
• Si aumentamos la calidad del producto, estableciendo una definición de hecho DoD por ejemplo, la velocidad aumentará y la presión se verá limitada.

Lo más potente de esta fase es que son los propios responsables de la toma de decisiones que habrán llegado por ellos mismos a las conclusiones, y por tanto no hay lugar para excusas y justificaciones, solo para decisiones nuevas que vayan a favor del sistema.

Una vez hayamos identificado los ciclos de refuerzo buscamos aquella variable con más valor para la compañía, la que queramos optimizar, esta es la que se denomina optimization goal.

En una esquina de su post-it apuntamos un "100", y seguimos su relaciones, si es de mas a mas apuntamos en el otro extremo el mismo número, "100" en el ejemplo, y si es de mas a menos, apuntamos un "0". De esta manera populamos nuestro diagrama con "0" y "100" representando como se interrelacionan las variables entre si. Cuando si al llegar a una variable haya conflicto porque de sus relaciones con otras variables una dice que debería de ser "0" y la otra "100", es que hemos descubierto un malentendido o una o varias asunciones ocultas. Este conflicto hay que dilucidarlo y resolverlo, es justo aquí donde las debilidades del sistema salen a la luz.

Una vez obtenido el diagrama completo podemos buscar diferentes maneras de influenciar en la variable que queramos optimizar a través de otras. A veces no podemos cambiar una variable concreta, pero podemos hacer que se refuerce o se degrade a través de otras utilizando los ciclos de refuerzo.

Tablero con el modelado de un sistema constructor de software

La herramienta es escalable, podemos modelar los diferentes sistemas contenidos en nuestra compañía para luego establecer relaciones entre variables de cada uno de ellos y así obtener un diagrama del sistema al completo. Por ejemplo un diagrama de desarrollo de producto, otro de finanzas y otro de marketing tienen variables en común... recordemos, los flujos de valor cruzan las áreas de negocio como requieren y todo está conectado en una compañía.

---

Y para aquellos que queráis modelar un sistema de forma remota quiero invitaros a echar un vistazo la aplicación de Nicky Case llamada LOOPY.

Esta aplicación proporciona herramientas mentales para comprender y modelar sistemas complejos del mundo que nos rodea, permite simulaciones con preguntas "y si" para obtener percepciones de cómo funcionan estos sistemas.

Gracias a Leonardo Tapia que nos mostró LOOPY en su sesión
"Systems Thinking en Scrum a gran escala LeSS" de AgilityTRes60