Tecnofor ha publicado los videos de las charlas del #TechManagementDay esta semana, de modo que he actualizado la entrada del blog que dediqué a mi presentación “Los estados intermedios”. En ella, a la hora de hablar de complejidad, hice referencia a Cynefin. No es la primera vez que cito este marco de trabajo, así que creo que es hora de tratarlo algo más en profundidad. Además, en el artículo de hoy me gustaría presentar algunas aplicaciones prácticas de Cynefin.
Cynefin vs Stacey
Cynefin es definido por su creador, @snowded, como un framework conceptual para ayudar a la toma de decisiones. Yo he encontrado gran valor en él para ayudar a distinguir qué tipos de técnicas son más adecuadas dependiendo del tipo de situación. Me ha sido especialmente útil para distinguir los problemas complicados de los complejos, que es justamente lo que explicaba yo en la charla de “Los Estados Intermedios”.
La relación entre manejo de la complejidad y metodologías ágiles viene de largo. En este artículo cité también la matriz de Stacey, que ya es usada por Schwaber en el primer capítulo de su “Agile Project Management with Scrum” (Microsoft Press, 2004) para explicar la complejidad inherente al desarrollo de software.
La matriz de Stacey nos hace pensar en términos de requisitos (qué hay que hacer) y certidumbre sobre la solución de un problema (cómo lo vamos a hacer) e introduce la diferencia entre complicado y complejo. En el texto de Schwaber dice:
Es posible tener requisitos de software simples. Un único cliente que es la única persona que usará el sistema, puede emplear suficiente tiempo con el desarrollador de modo que ambos pueden acordar exactamente qué construir. Asumiendo que este cliente muere inmediatamente después de proporcionar sus requisitos, estos permanecerán constantes, y no habrá cambios, revisiones ni modificaciones de último minuto. Más habitualmente, hay muchos actores interesados (aquellos con un interés en el software y en cómo éste funciona) que tienen diferentes necesidades y cuyas necesidades cambian frecuentemente y son difíciles de articular. En la mayoría de los casos, los clientes sólo comienzan a entender realmente lo que quieren cuando se les proporciona la impresión de otra persona sobre lo que quieren. Los suyos son requisitos complejos porque no sólo son ambiguos, sino que también están cambiando constantemente. La tecnología simple existe, pero rara vez es usada para desarrollar software. Podríamos definir proyectos de desarrollo de software como la aplicación de tecnología avanzada (frecuentemente poco fiable) para resolver problemas de negocio y conseguir una ventaja competitiva. Para agravar la complejidad de la tecnología, habitualmente se emplea más de una pieza, y las interfaces de la mayoría son mucho más complejas que la complejidad dentro de una única pieza.
Perdón por la (muy) mejorable traducción, pero creo que se recoge bien la intención del autor cuando habla de complejidad. Justo a continuación se apoya en la matriz de Stacey para reforzar el párrafo anterior.
Así, vemos que hay problemas para los que hay consenso sobre “el qué” y “el cómo”, y los denomina simples. A medida que vamos perdiendo consenso en alguno de los dos ejes, diríamos que el problema se complica, habiendo un punto en el que hablamos de complejidad porque no hay consenso sobre el qué hay que hacer y/o tampoco sobre el cómo (los expertos no se ponen de acuerdo). Incluso dice que los problemas caóticos no se pueden trabajar, por lo que hay que resolver algunas de sus complejidades antes.
Muchos (yo incluído) también hemos empleado esta matriz para explicar que Agile no aplicaba en todos los casos como metodología de gestión de proyectos. Era una manera de decir al statu quo: “Venimos en son de paz”. Sin embargo, algunos artículos avisaban desde hacía tiempo que este mensaje se estaba convirtiendo en una excusa para simplificar ciertos problemas y, como consecuencia, aplicar las técnicas y herramientas equivocadas.
Si bien los dominios de Cynefin son prácticamente los mismos que plantea Stacey, Snowden los sitúa de una manera un poco diferente: los de la derecha están “ordenados” (la causa y su efecto son conocidos o pueden ser descubiertos), mientras que los de la izquierda están “desordenados” (la causa y su efecto sólo pueden ser deducidos en retrospectiva, o incluso ni eso). Pero la gran innovación es el estado llamado “de desorden” o “de confusión”, que es en el que estamos cuando no podemos/sabemos distinguir en qué dominio nos encontramos.
Como ya he citado varias veces en artículos anteriores, para mí, la mejor introducción a Cynefin es la de este artículo en el blog de @MartinAlaimo.
Cynefin es un framework para tomar decisiones
Cynefin, además de un mapa para identificar el tipo de problema al que nos enfrentamos, nos ayuda a identificar las técnicas adecuadas al mismo. Te recomiendo leer este artículo porque creo que explica muy bien cómo tomar decisiones con Cynefin.
Así, en el dominio de lo obvio aplicamos las mejores prácticas. Todo el mundo sabe cómo se suma. Multiplicar puede ser más elaborado, pero no hay más que seguir un método y siempre obtendremos el mismo resultado.
Ahora bien, cuando el problema se complica, podemos tener que elegir entre métodos porque unos se ajustan mejor que otros al problema en particular. Eso sí, eligiendo el método adecuado, obtendremos siempre los mismos resultados.
En cambio, en el dominio de lo complejo ya no nos valen las buenas prácticas, sino que debemos aplicar un enfoque experimental para averiguar las relaciones entre las causas y los efectos. De esta manera, lo que tendremos no serán buenas prácticas sino prácticas emergentes o patrones, que nos ayudan, con las debidas simplificaciones, a tratar algunas partes de los sistemas con los que trabajamos. Scrum podría ser uno de estos.
Es fundamental entender que Scrum es una técnica que nos ayuda a entender o simplificar (añadir restricciones) a nuestro sistema para poder manejarlo con buenas prácticas. Pero también incluye, por su enfoque experimental, la capacidad de ayudarnos a manejarnos en el dominio de lo complejo. Por ejemplo, las retrospectivas son técnicas que nos empujan a elaborar una hipótesis (“creemos que tenemos un problema y que haciendo esto lo podremos mitigar”) y a realizar el experimento correspondiente.
El dominio de lo caótico es, generalmente, el gran esquivado en todo lo relativo a Cynefin. Es curioso que la mayoría hablan de un tipo de problemas donde la urgencia por actuar es la clave para identificarlo. Sin embargo, el propio @snowded explica que lo que caracteriza al dominio caótico nada más es la ausencia de restricciones.
Chaos is the absence of contraints. Not a natural condition temporary
— ᗪᗩᐯᕮ SᑎOᗯᗪᕮᑎ 🏴 🇪🇺 (@snowded) March 16, 2018
Por tanto, es clave ser capaces de identificar el dominio en el que se encuentra el sistema al que nos acercamos a trabajar porque de ello debería depender la decisión sobre qué técnicas emplearemos.
Cynefin también es una narrativa
Cynefin permite elaborar una narrativa menos simplista que Stacey acerca de la complejidad: más acercada a la realidad de la toma de decisiones. Probablemente de ahí su éxito.
Por ejemplo, en mi serie de artículos sobre NoEstimates, usé Cynefin y Agile para dar soporte a mi planteamiento sobre planificación estratégica adaptativa. Poder explicar que la gestión adaptativa encaja con los problemas complejos y que la planificación estratégica es un problema inherentemente complejo es mucho más fácil gracias a Cynefin y Agile pues nos proporcionan vocabulario, conceptos, relaciones entre conceptos y, sobre todo, ejemplos.
No sólo permite hablar de complicado y complejo en términos de certidumbre en los requisitos (relación conocida entre causas y efectos) o de certidumbre en la viabilidad técnica (acuerdo entre expertos sobre la solución), que es lo que aporta la matriz de Stacey, sino que pone el foco en que debemos aplicar las técnicas adecuadas al tipo de problema al que nos enfrentamos. De ahí la importancia del estado de desorden.
Éste es, justamente, uno de los mensajes fuertes de mi charla “Los estados intermedios”.
Para manejarnos en el terreno de lo complejo, como es una transformación organizacional, no parece adecuado seguir un enfoque predictivo, como los típicos planes de despliegue del framework de turno. Los típicos “roll out” que tratan de desplegar Agile como una receta que todo el mundo podrá aplicar de la misma manera en la organización. Los que hacen esto están interpretando que están en el dominio de lo complicado, cuando en realidad están en el dominio de lo complejo (o incluso de lo caótico). Mi charla trataba de poner foco en esto y en ofrecer la Improvement Kata como una técnica que podría ayudar enfocar las transformaciones organizacionales como lo que son: problemas complejos (o incluso caóticos).
FOTO: La imagen de cabecera la he tomado prestada del blog de Martín Alaimo que tantas veces he citado. Espero que no le moleste.