¿En qué consiste System Thinking?

Dependiendo del nivel de su complejidad un sistema
puede operar bajo un proyecto en cascada o Scrum

Hace poco Alexandre Magno dio una clase magistral sobre System Thinking. En este post quiero exponer mis aprendizajes más algunas ideas de mi cosecha.

La wikipedia define un sistema como una entidad con límites y con partes interrelacionadas e interdependientes cuya suma es mayor a la suma de sus partes.

Un sistema tiene como objetivo entregar valor al entorno que le rodea, lo hace partiendo de un input para crear un outcome que entrega en forma de outputs. En el caso de proyectos de TI es el cliente/usuario quien recibe el valor, y por tanto este forma parte del entorno.

Imaginemos un interruptor y una bombilla, estos forman un sistema cuyo input es la acción sobre el interruptor, el output es la bombilla que se enciende o se apaga, y el outcome, el beneficio, es que las personas en la habitación puedan ver.

De igual manera un sistema en TI es aquél que, dadas las necesidades de un cliente/usuario, tiene todo lo necesario para construir el software, el output, que da solución a las necesidades de este, el outcome.

Un sistema incluye a las personas y a los recursos necesarios para construir, como los son herramientas, procesos y restricciones. System Thinking es la disciplina que se focaliza en el sistema de forma holística para que funcione de manera optimizada. El system thinker es aquel que lo comprende a alto nivel, tanto en comportamiento como en arquitectura, y lo lidera, apoya e impulsa. Los Scrum Masters son system thinkers de equipos, los coaches ágiles de tribus y equipos de equipos, y los líderes ágiles lo son a nivel de la compañía y sus áreas.

Un system thinker comprende que:

• El flujo de valor de un sistema pasa a través de sus interconexiones, por tanto analizar el flujo para optimizar el sistema es clave
• Un sistema no puede evolucionar más rápido que su punto de integración más lento, fijándonos en retrasos y cuellos de botella sabemos donde debemos de actuar
• Optimizar un componente, un equipo sin tener en cuenta las dependencias con otros equipos o áreas por ejemplo, no optimiza el sistema
• Sólo el entorno, en nuestro caso el cliente/usuario, quien tiene la necesidad y es consumidor del software, puede validar los outcomes del sistema

También hay que comprender que hay sistemas dentro de otros sistemas, y que debe de haber lideres system thinkers a cada uno de los niveles existentes. Podemos tener un sistema en forma de equipo muy optimizado, pero si la compañía dentro de la cual opera no está optimizada por un system thinker, la optimización del equipo no trascenderá e incluso puede crear frustración en sus miembros por sentirse encorsetados y limitados.

Como ejemplo pensemos en un telefonista de una pizzería que entrega pizzas a domicilio. Este puede ser un vendedor excelente que haga que sintamos que estamos comprando la mejor pizza del mundo, pero si la cocina no está optimizada y el producto que recibimos es mediocre, la empresa como sistema es un sistema mediocre.

Matriz de Stacey que nos muestra los
diferentes niveles de complejidad

Cuando tratamos con sistemas de construcción de software, ¿Scrum es siempre la mejor forma de operar? Para ello nos puede ayudar la matriz de Stacey:

Sistemas simples: en estos sistemas la incertidumbre respecto a "qué" construir y "cómo" construirlo es muy baja. En estos sistemas es muy fácil identificar las causas y sus efectos, las decisiones que tomemos podemos tomarlas de forma correcta y clara en el primer momento. Para este tipo de sistemas la gestión clásica en cascada es ideal para optimizar la construcción de la solución de forma completa.

Sistemas complicados: en estos sistemas la incertidumbre de "qué" y/o "cómo" construir tiene peso pero es manejable, las decisiones que tomemos tienen consecuencias predecibles por lo que hay múltiples soluciones correctas. Con el involucramiento de expertos y buenas prácticas se puede llegar a identificar la mejor solución al principio. Scrum podría emplearse pero no sería la forma más eficiente de construir, una gestión de proyectos clásica en casada sería una excelente forma de trabajo ya que la solución puede identificarse completa al principio.

Sistema complejos: es cuando la incertidumbre del "qué" y/o del "cómo" construir es alta, cuando somos capaces de entender las consecuencias de nuestras decisiones pero no las interacciones entre estas consecuencias. Los resultados se vuelven impredecibles y no podemos identificar una solución al principio, solo podemos examinar los resultados y adaptarnos. Esto requiere contextos donde haya lugar para la experimentación y donde esté permitido fallar, con un bajo impacto de los fallos y se donde se pueda aprender rápidamente. En este tipo de sistemas, en los que se requieren niveles altos de creatividad, innovación, interacción y comunicación, Scrum, con sus ciclos de inspección y adaptación, es un marco de construcción ideal.

Sistemas caóticos: cuando la incertidumbre del "qué" y/o del "cómo" construir son muy altas el sistema se considera caótico, su evolución es tan sensible a las más pequeñas variaciones que en la práctica, más allá de un corto intervalo de tiempo, su evolución resulta impredecible. Para poder lidiar con un sistema caótico necesitamos que los profesionales tengan poder de decisión al nivel de la información con la que tratan para poder adaptarse rápidamente y continuamente. Este sería otro escenario para utilizar Scrum, probablemente con ciclos lo más cortos posibles, como sprints de 1 semana por ejemplo. Otra opción sería aplicar Kanban dando respuesta en forma de flujo continuo y con limites WIP que permitirá mantenernos siempre en lo más prioritario.

Mis agradecimientos a Alexandre por su clase magistral y sus dibujos del post :-)