Una de las formas posiblemente más claras para explicar el contexto en el cual Scrum es más eficiente tiene que ver con el enfoque de la complejidad del Marco Cynefin o Modelo Cynefin, acuñado en 2000 por Dave Snowden.
El Marco o Modelo Cynefin compara las características de cinco dominios de complejidad diferentes: simple, complicado, complejo, caótico y desordenado, en el centro. Analicemos cada uno de ellos.
1. Dominio Simple
El Dominio Simple dentro del Marco Cynefin es donde se opera con problemáticas simples. Dave Snowden lo define como un dominio en donde es muy fácil identificar las causas y sus efectos. Por lo general, la respuesta correcta es clara, conocida por todos e indiscutible. En este dominio existen las mejores prácticas, soluciones conocidas para problemas conocidos. Los procesos más eficientes en este dominio son aquellos que especifican una serie lógica de pasos y se ejecutan de manera repetitiva, una y otra vez. Ejemplos de este dominio son la construcción en serie de un mismo producto, la instalación en muchos clientes de un mismo sistema. Si bien Scrum puede funcionar en este contexto, los procesos compuestos por pasos bien definidos son mucho más eficientes.
2. Dominio Complicado
Otro de los dominios del Marco Cynefin es el Dominio Complicado. En este dominio encontramos problemas complejos, buenas prácticas y perfiles expertos. Hay múltiples soluciones correctas para una misma problemática, pero se requiere del involucramiento de expertos para poder identificarlas. Un ejemplo típico de este escenario es la solución de un problema de performance en un software o base de datos, la sincronización de semáforos en un cruce de 3 avenidas, la búsqueda de eficiencia en la distribución logística de mercaderías, etc. Si bien Scrum podría emplearse, no necesariamente sea la forma más eficiente de resolver estas situaciones, donde funcionaría mejor un conjunto de expertos en la materia que releven la situación, investiguen diferentes alternativas y planteen la solución en base a las buenas prácticas. Una práctica habitual de este dominio es el mantenimiento de sistemas y soporte técnico.
3. Dominio Complejo
Dentro del Marco Cynefin de Dave Snowden nos encontramos con el Dominio Complejo. Nos encontramos con un Dominio Complejo cuando nos enfrentamos a problemas complejos, cuyos resultados se vuelven más impredecibles. No existen ni mejores ni buenas prácticas catalogadas para las situaciones frente a las cuales nos podemos encontrar.
Simplemente, no sabemos con anticipación si una determinada solución va a funcionar. Solo podemos examinar los resultados y adaptarnos. Este es el dominio de las prácticas emergentes. Las soluciones encontradas rara vez son replicables, con los mismos resultados, a otros problemas similares. Para poder operar en la complejidad necesitamos generar contextos donde haya lugar para la experimentación y donde el fallo sea de bajo impacto. Se requieren niveles altos de creatividad, innovación, interacción y comunicación. El desarrollo de nuevos productos o la incorporación de nuevas características en productos existentes es un contexto complejo en el que Scrum se utiliza mucho para actuar, inspeccionar y adaptar las prácticas emergentes de un equipo de trabajo.
4. Dominio Caótico
En el Dominio Caótico de Cynefin nos encontramos con problemas caóticos que requieren una respuesta inmediata. Estamos en crisis y necesitamos actuar de inmediato para restablecer cierto orden. Imaginemos que el sistema de despacho de vuelos en un aeropuerto de alto tráfico deja de funcionar. Este no sería un escenario para utilizar Scrum, aquí debemos actuar de inmediato, alguien debe tomar el control y mover la situación fuera del caos. Por ejemplo, solucionar el problema inmediatamente (sin importar la forma técnica), para luego, fuera del caos, evaluar y aplicar una solución más robusta, de ser necesario. Este es el dominio de la improvisación.
5. Dominio Desordenado
Para Dave Snowden, nos movemos en el espacio desordenado cuando no sabemos en qué dominio estamos. En el Modelo Cynefin a esta zona la clasifica como una zona peligrosa, ya que no podemos medir las situaciones ni determinar la forma de actuar. Es muy típico en estas situaciones que las personas interpreten las situaciones y actúen en base a preferencias personales. El gran peligro del dominio desordenado es actuar de manera diferente a la que se necesita para resolver ciertos problemas. Por ejemplo, mucha gente en el ámbito del desarrollo de software está acostumbrada al desarrollo secuencial, por fases, detalladamente planificado utilizando las mejores prácticas de la industria, y este enfoque, que corresponde al dominio Simple, muchas veces se aplica en el dominio complejo. Si nos encontráramos en el espacio desordenado, todo lo que hagamos debe estar enfocado netamente a salirnos de ese espacio hacia uno mejor identificado, para luego actuar de la manera en que dicho dominio lo requiera.
Y entonces… ¿Qué es Scrum?
Scrum es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación. No es un proceso completo, y mucho menos, una metodología. En lugar de proporcionar una descripción completa y detallada de cómo deben realizarse las tareas de un proyecto, genera un contexto relacional e iterativo, de inspección y adaptación constante para que los involucrados vayan creando su propio proceso. Esto ocurre debido a que no existen ni mejores ni buenas prácticas en un contexto complejo. Es el equipo de involucrados (Equipo Scrum) quien encontrará la mejor manera de resolver sus problemáticas. Este tipo de soluciones serán emergentes.
El progreso de los proyectos que utilizan Scrum se realiza y verifica en una serie de iteraciones de tiempo acotado llamadas Sprints. Estos Sprints tienen una duración fija, preestablecida de no más de un mes. Al comienzo de cada Sprint el Equipo Scrum realiza un compromiso de entrega de una serie de funcionalidades o características del producto en cuestión.
Al finalizar el Sprint se espera que estas características comprometidas estén terminadas, lo que implica su análisis, diseño, desarrollo, prueba e integración al producto. En este momento es cuando se realiza una reunión de revisión del producto construido durante el Sprint, llamada Sprint Review, la cual es un evento de Scrum donde el Equipo comparte lo construido con los stakeholders. El feedback obtenido en esta reunión puede ser incluido entre las funcionalidades a construir en futuros Sprints.