Modelo Cynefin: identifica el escenario de tu proyecto

En el 2012 cursaba el 5to semestre de la carrera de ingeniería en sistemas, y había una materia que nos mencionaba las metodologías de desarrollo de software, cuando mencionaron Scrum en particular me llamó fuertemente la atención, en aquel momento era solo un estudiante que tenía la curiosidad, sin embargo esa curiosidad fue el ingrediente que me llevó a conocer más de los métodos ágiles y a especializarme en ello, pero en mi travesía (aún vigente) de este movimiento he escuchado a muchas personas hablar mal de los métodos ágiles particularmente mencionan que los métodos no dan buenos resultados.

Nadie puede decir que los métodos ágiles no han venido a por lo menos hacernos cuestionar la manera de hacer software, y como en todos los aspectos siempre hay personas que apoyan este cambio y personas que no lo hacen, podrían enunciar infinidad de “motivos” por los cuales los métodos ágiles no son buenos, según los detractores de este movimiento, mencionan que no existe análisis, que no hay certidumbre, que es una simple moda, que involucrar al cliente en el desarrollo no es una buena opción, entre otros mitos que rondan alrededor de este movimiento. Y no es para menos, darte cuenta que llevas varios años construyendo software t de repente aparece un movimiento a decirte que la manera en que lo haces esta mal, y que debes de cambiar, no es fácil enfrentarse a ese tipo de situaciones. En mi opinión no creo que los métodos ágiles sean “la manera correcta universal de hacer software”, pero debemos reconocer que nos otorgan más herramientas para llevar nuestros proyectos de manera correcta y ayudar a reducir la incertidumbre en proyectos complejos, considero que como profesionales desarrolladores de proyectos debemos realizar la selección de la herramienta o método basándonos en las circunstancias del proyecto y elegir la que mejor convenga al proyecto en general, no con la que estemos más cómodos, es cierto que podemos tener una afinidad o una especialidad, en mi caso son los métodos ágiles, pero eso no debe ser una excusa para querer hacer todos los proyectos con este método. Pero lo interesante es responder la pregunta ¿Qué método debo usar? Para contestar esto David Snowden crea en 1999 un modelo que ayuda a identificar estas características, es conocido como el modelo Cynefin y nos aclara una pregunta que es vital para muchas organizaciones, ¿Porque un método a veces funciona y otras no?.

Escenarios según el modelo Cynefin

Una buena guía para saber qué métodos usar dependiendo las características del proyecto es usar el modelo Cynefin, que describe estas características que puede presentar un proyecto en forma de escenarios, este modelo describe 5 posibles escenarios en los cuales un proyecto de software puede estar, estos escenario son creados de acuerdo a su complejidad que es el resultado de dos variables importantes, la primer variable es elementos de su entorno (estructura), es fácil de comprender o no y el segundo es el comportamiento de los elementos (predictibilidad), lo que realizaremos es predecible o no, la combinación de estas 2 variables genera 5 posibles escenarios, los cuales te los describo a continuación.

1. Simple y obvio: en este escenario todos sabemos como hacer las cosas y como resolverlas, no existe incertidumbre y conocemos todo el proceso, su estructura es fácil de comprender para nosotros (primera variable), y el comportamiento de los elementos es muy predecible (segunda variable). Para darle más sentido a esto, lo enfocaremos un poco a proyectos de software, si tu vas a realizar un software que representa un escenario simple para ti, quizás un método tradicional es tu mejor opción, no necesitas hacer reuniones de presentación (Scrum review), porque lo que haces es obvio y no es necesario que sea validado por el cliente, no es necesario la reunión de planeación (scrum planning) y las estimaciones serán muy certeras, pues dominamos el proceso y el desarrollo de ellos. Un ejemplo de proyecto simple podría ser una página web empresarial, de la cual ya tenemos los textos y plantillas y el cliente solo tendrá que elegir cuál desea.
2. Complicado: Un proyecto complicado requiere de la participación de un experto, que generalmente es de un tema que no está relacionado directamente con programación, por ejemplo un sistema contable requiere la participación de un contador experto que resolverá las dudas del equipo de desarrollo y las personas interesadas, aunque la estructura no es fácil de comprender para el equipo (primera variable), es un proyecto predecible (segunda variable), pues contamos con el asesoramiento de un experto. Este tipo de proyectos pueden desarrollarse con métodos ágiles o tradicionales, la decisión podría caer en otros factores, como la disponibilidad que tendrá el experto para atender los requerimientos solicitados por el equipo o que tanta dependencia tenemos del experto, pero una vez más que la decisión sea tomada basándonos en las circunstancias del proyecto. Algo importante de mencionar es que si tienes un equipo de desarrollo que trabaja proyectos complicados puede resultar aburrido o abrumador para el equipo, porque se convierten en proyectos repetitivos, que no aportan creatividad ni representan un reto para el equipo.
3. Complejo: Este escenario o entorno es donde mejor funcionan los métodos ágiles, aquí la estructura no es fácil de entender para el equipo (primera variable) y no existe algún experto que pueda apoyar al equipo por que generalmente en este escenario se da la innovación, el conocimiento emerge mientras el proyecto avanza, muchas cosas no se han realizado antes, la incertidumbre es alta, el modelos tradicional se vuelve poco recomendado, pues si se piensa realizar requisitos detallados muy probablemente tiempo después tendrán que ser desechados porque poco a poco se va teniendo nuevo conocimiento que antes no se tenía y que termina modificando los requerimientos. Este escenario es el más cómodo para los equipos comprometidos y que les gusta enfrentar nuevos retos.
4. Caótico: No existe orden en este escenario, tenemos que entregar como sea, se necesita respuesta inmediata para regresar a tener un poco de orden, este no es un escenario para usar Scrum, quizás Kanban podría ayudarnos pero generalmente no importa el método, el objetivo es resolver de cualquier manera una problemática que se presenta, un ejemplo de este escenario podría ser la caída de un sistema bancario, cada segundo que está fuera de línea son miles de transacciones perdidas, por ello la prioridad es resolver el problema y una vez establecido el orden implementar medidas para resolver y corregir los problemas que ocurrieron.
5. Desordenado: Este escenario es sumamente peligroso, pues no sabemos en qué situación estamos ni hacia dónde tenemos que avanzar, si nos encontramos en este escenario debemos usar todos nuestros recursos para movernos a un escenario mejor identificado para actuar de manera que el escenario lo requiera.

El modelo es útil para entender porqué ciertos métodos funcionan en algunos proyectos y en otros no, un caso común es tratar proyectos complejos como si fueran complicados, intentar definir los requisitos y observar como caen al momento de ir avanzando y descubriendo más acerca del proyecto, bajo este escenario lo mejor es generar conversaciones, explorar, documentar y descubrir.

Lo importante es saber identificar estos escenarios para actuar acorde al escenario del proyecto, maximizando las posibilidades de éxito de nuestro proyecto.