Entre las afirmaciones más curiosas que he escuchado sobre agilidad, una es la que dice que las metodologías ágiles no sirven para proyectos complejos. 

Lo extraño de esa afirmación es que las metodologías ágiles parecen ser, según la experiencia de muchos usuarios, las que mejor lidian con la complejidad.

Hay dos posibles razones que puedan explicar ese tipo de afirmaciones. La primera es que se suele confundir complejo con complicado. La segunda razón es la incapacidad para lidiar con lo complejo.

Complejo versus complicado

Ya hemos hablado de este tópico en varias ocasiones en este blog. En el artículo "Lo simple, lo complejo, lo complicado" digo más o menos lo siguiente:

Cuando decimos que algo es complejo queremos sugerir que es el resultado inevitable de combinar los elementos, y que esto no implica una falta o un fallo, como cuando decimos que “una receta es compleja”.

Por otro lado, complicado lo aplicamos a lo que presenta gran dificultad para entender, resolver o explicar, por ejemplo “un complicado proceso judicial”.
Lo complicado es engorroso, genera desgaste pues requiere mucha atención a los detalles, no hay que descuidar nada, puesto que un error podría ser desastroso. Lo complicado es la tierra de los micro controladores, son felices ahí. Pero, para abordar lo complicado es importante contar con un plan detallado, una lista de todo lo que se debe construir. Una lista con todos los detalles, un checklist, es esencial en un contexto como este. 

Planificación detallada, controles y revisión, eso es lo que requiere un proceso o un proyecto complicado.

Dividir para reinar es una estrategia adecuada en este caso. Podemos dividir un proyecto complicado en diversas partes y atacarlas una a una. Esto es lo que llamamos desarrollo incremental, o en cascada.

Complejidad es evolución

El problema con lo complejo es que evoluciona, incluso a veces cambia inesperadamente. La complejidad es una propiedad emergente de los sistemas. La complejidad surge de la combinación de elementos.

Para los proyectos complejos es difícil tener un plan detallado y quizás no vale la pena escribirlo, porque las cosas pueden cambiar de manera abrupta.

La complejidad ha sido ampliamente estudiada por los físicos, quienes saben que un pequeño cambio en las condiciones iniciales puede alterar completamente la predicción de un modelo. 

La idea de que podemos controlar un proyecto complejo a alto nivel, desde una torre de control remota y aislada es fundamentalmente errónea.

La clave para manejar un proyecto complejo es sensar y responder.

La forma adecuada para guiar un proyecto complejo es la aproximación experimental.

La Matriz de Stacey

La matriz de Stacey es una herramienta elaborada a partir del trabajo de Ralph Douglas Stacey. Este teórico del comportamiento organizacional fue uno de los pioneros en usar la teoría de complejidad, de las ciencias naturales al ámbito de las organizaciones y su administración.

En 2011 Stacey propuso un esquema, un mapa o modelo para que los tomadores de decisión guiaran sus estrategia en función de dos dimensiones: el grado de acuerdo y el grado de certeza.

En un diagrama Stacey coloca en el eje X el grado de certeza que tiene la organización con respecto a un problema. En el eje Y el grado de acuerdo con respecto al mismo.
Matriz o Mapa de Stacey

El diagrama de Stacey nos permite mapear el ámbito de las decisiones, según el grado de certeza y de acuerdo al que podemos usar las aproximaciones racionales. 

Cuando la certeza es mayor, pero el grado de acuerdo menor se requiere tomar decisiones más políticas. Si hay acuerdo, pero poca certeza, entonces la decisiones requieren un juicio más experto.

En el cuadrante superior derecho tenemos el caos, la anarquía, donde es imposible tomar buenas decisiones.

El diagrama de arriba está tomado del trabajo de Stacey "Strategic management and organisational dynamics: the challenge of complexity."[1].

Las  regiones del mapa de Stacey

Para entender un poco mejor la idea de Stacey, analicemos este diagrama:

Diagrama de Stacey  con las regiones enumeradas.

La región 1 es la de la decisión racional, técnica, y es la que más cubre la literatura sobre administración. Acá tomamos datos del pasado y los usamos para predecir el futuro. Es el mundo de los planes, con caminos de acción con salidas identificadas que pueden ser monitoreadas. Queremos que todo sea repetible, para asegurar eficiencia y efectividad.

La región 2 es el de las decisiones políticas. Acá hay certeza de los resultados, pero un alto grado de desacuerdo sobre cuales resultados son deseables. No hay planes ni misión compartida. Acá la política es muy importante, construir coaliciones, negociar y hacer compromisos, con el fin de dar una dirección y una agenda a la organización.

La región 3 es la de la decisión juiciosa. Algunos asuntos tienen un alto nivel de acuerdo, pero no hay mucha certeza sobre las causas y efectos de los resultados esperados. En este caso el monitoreo sobre un plan predeterminado no funcionará. Acá importa más tener una visión y misión compartidas, por sobre un plan preciso. Las comparaciones se hacen sobre la visión y la misión, más que sobre el plan.

La región 4 es el caos. Un alto nivel de desacuerdo e incerteza. A menudo esto lleva a la anarquía. Los métodos tradicionales de visión, negociación y planificación son insuficientes en estos contextos. La estrategía habitual es evitar los conflictos, pero esta actitud a la larga resulta desastroza. No quieres que tu organización caiga en esta zona.

La región 5 es la de la complejidad. En esta zona los métodos tradicionales de gestión no son muy efectivos, pero es la zona de la mayor creatividad, innovación y de romper con el pasado para crear nuevos modos de operar. 

El problema con los administradores o gestores actuales

Lo malo es que a los gestores, los ejecutivos y administradores actuales se  les ha entrenado en el manejo de las áreas 1, 2 y 3. Son los modelos tradicionales. Las técnicas necesarias para administrar las regiones 4 y 5 aparecen como demasiado "blandas", con falta de predicción, alta inseguridad y certeza, pero la realidad se da más en esas zonas. 

Si te encuentras en las zonas 1, 2 y 3 hay técnicas conocidas que es mejor que apliques. El problema está en que muchos ejecutivos quieren administrar todo lo que está en otras regiones como si estuvieran en la zona 1. 

Metodologías ágiles y la matriz de Stacey

En el ámbito de las metodologías ágiles se ha adoptado una versión de la matriz de Stacey que es más o menos la siguiente [2]:

Lo que nos dice esta versión de la matriz, es que en escenarios complejos es bueno usar procesos empíricos, como Scrum, por ejemplo. Pero aún, en escenarios caóticos tenemos espacio para usar el triage, o evaluación caso a caso, eso se llama Kanban, donde podemos ir priorizando lo que tenemos que hacer, hasta lograr dominarlo.

Para lo simple, basta tener una lista de lo que se requiere hacer y ejecutarlo. O podemos usar técnicas tradicionales, como Waterfall. Pero nada impide usar las metodologías ágiles en esos ámbitos, aunque probablemente no aporten mucho. El valor de la agilidad se da en la complejidad, en la medida que la incerteza aumenta y el grado de acuerdo se diluye.

Así que no es cierta la afirmación de que las metodologías ágiles no sirven para los proyectos complejos, esa es una falsedad absoluta, y quien diga eso simplemente está tratando de llevar todo a su zona de confort, porque no entiende o no conoce algo tan básico como la matriz de Stacey.

Notas:

[1] "Strategic management and organisational dynamics: the challenge of complexity. tercera edición, Prentice Hall, 2002.

[2] On Complexity (Cynefin Framework & Stacey Matrix): Why Your Software Project Needs Scrum https://www.linkedin.com/pulse/complexity-why-your-software-project-needs-scrum-christiaan-verwijs/






¿Te gustó? Danos tu auspicio en Patreon Become a Patron!

Comentarios

La Naturaleza Del Software © Eduardo Diaz Cortes

Publicado usando Prosa - release 0.3.7