Agile o no agile?, Esa es la cuestión

Por Luis Ricardo Martinez Hernández

¿No te ha pasado que siempre que enfrentas un problema o reto, lo primero que quieres hacer es solucionarlo?

Y probablemente ahora estarás pensando… Pero, ¿no es eso lo que se supone que se debe hacer con los problemas?

Y sí, pero no es lo primero que debemos hacer.

¿Alguna vez te has puesto a analizar si la forma en que lo quieres resolver es la correcta? ¿Las cosas que conoces del problema son claras y suficientes? ¿Sabes qué factores del entorno son relevantes?

Muchas veces la experiencia te hará usar las formas que ya conoces, aún y cuando no sea lo mejor o lo óptimo. Es cómo intentar usar siempre un martillo para reparar algo porque es lo único que has utilizado siempre.

Entonces, ¿cómo deberíamos abordar estos retos? ¿Cómo hacer que mi experiencia no genere subjetividad en la elección de la herramienta que debo usar?

Para responder estás preguntas, podemos empezar por poner una clasificación a los retos o problemas que nos enfrentamos. Esto nos permitirá tener un mejor entendimiento del contexto en el que los podemos situar.

Podemos clasificarlos en 4 dominios de acuerdo a que tanto conocemos de la relación causa y efecto de los componentes o factores del problema o proyecto.

El primer dominio, es el de los problemas simples. Y no son simples porque sean fáciles en sí, sino porque las relaciones de causa y efecto son claras y fáciles de identificar, además de que son estables.

Ejemplos de problemas simples pueden ser: reparar un electrodoméstico, preparar un café o la fabricación en serie de un mismo producto.

Para resolverlos, generalmente acudimos a las mejores prácticas, ya que se tratan de soluciones ordenadas y repetibles, es decir, ya se han utilizado en el pasado, se ha comprobado su efectividad y es sencillo aplicarlo ya que podemos encontrar muchos casos similares al que pretendemos resolver.

Las mejores prácticas que podemos usar para nuestros ejemplos son: utilizar el manual del fabricante o un video tutorial para reparar el electrodoméstico, utilizar la receta de la abuela para preparar un rico café o usar un proceso existente para la fabricación en serie del producto.

Solamente hay que enfocarnos en analizar la situación con los datos disponibles, clasificarla y responder con la mejor práctica que encontremos. En resumen: seguir las reglas.

Sólo hay que cuidar de no “simplificar de más” porque podemos perder de vista factores importantes que afectan la situación o cerrarnos a una mejora en la forma en que estamos haciendo las cosas.

El segundo dominio que tenemos es el de los problemas complicados. Aquí las relaciones de causa y efecto no son tan evidentes o fáciles de identificar. Si bien el entorno es ordenado se requiere la participación de un experto para explorar las posibles soluciones.

Ejemplos de problemas complicados pueden ser: que un coche no encienda, problemas de rendi-

miento en un sistema o eficientar una ruta de distribución de mercancía.

Aquí, las buenas prácticas son la mejor forma de abordar estos problemas ya que recurriremos a los expertos en la materia para investigar las diferentes opciones que tenemos disponibles, entendiendo que varias pueden ser adecuadas.

Las buenas prácticas que podemos usar para nuestros ejemplos podrían ser: llevar el carro al mecánico para que revise cuál puede ser el problema, hacer mediciones en las diferentes capas del sistema para determinar dónde se tarda más en procesar o utilizar técnicas de investigación de operaciones para determinar la mejor ruta.

Para este dominio hay que enfocarnos en analizar la situación, acudir con el experto de la materia y responder con alguna de las buenas prácticas que nos proponga basado en su experiencia y conocimiento del entorno.

Y adivina… aquí es donde entran las metodologías tradicionales, predictivas, en cascada o como les quieras decir ya que son un conjunto de buenas prácticas que nos ayudan a gestionar de manera eficiente los proyectos de este ámbito, y como administradores de proyectos expertos, nos toca elegir las prácticas que mejor se adapten a lo que queremos resolver.

Algo muy importante a considerar es que no debemos caer en la llamada “parálisis por análisis” al recurrir a varios expertos y no decidir a cuál hacerle caso. También cuidemos no excluir la opinión de los que no son considerados expertos, ya que pueden estar más acertados en sus planteamientos.

El tercer dominio corresponde a los problemas complejos. Aquí ya se empiezan a poner más interesantes las cosas porque de inicio no tenemos respuestas correctas, es decir, las relaciones causa y efecto son desconocidas cuando el problema llega a nuestras manos.

Como ejemplos de problemas complejos tenemos los que en su mayoría tienen que ver con personas y sus preferencias; como un nuevo producto o aplicación y su aceptación en el mercado. No existen mejores ni buenas prácticas que nos ayuden a predecir los gustos de la gente, es por eso que necesitamos experimentar. Y aquí es donde entran todos los marcos de trabajo que están bajo el paraguas ágil: Scrum, Kanban, Nexus, TDD, DSDM, etc.

Para empezar a solucionar nuestro ejemplo, podemos experimentar creando una campaña de publicidad o un demo para conocer el grado de interés de las personas en el producto o aplicación. Si vemos que el mercado se muestra interesado, entonces podemos justificar el desarrollo de ese producto o aplicación. Como chisme histórico, este fué el camino que siguió Spotify en sus inicios.

Entonces, para este tipo de retos tenemos que enfocarnos en realizar un primer experimento con lo que suponemos, recibir retroalimentación del mercado o de los usuarios y ajustar las siguientes acciones, de acuerdo a esta retroalimentación, hacia el objetivo que tenemos por medio de más experimentos. Y haciendo esto de manera iterativa podemos solucionar nuestro problema con entregas incrementales de valor sin comprometer presupuesto y esfuerzo en algo que no funcione.

Cuando estamos en este dominio debemos evitar la tentación de volver a los estilos tradicionales de gestión en los que se buscan planes infalibles con resultados definidos, ya que esto puede limitar las oportunidades de innovación, la creatividad y el surgimiento de nuevos patrones de solución.

Por último, tenemos el cuarto dominio, definido por los problemas caóticos. Aquí estamos en medio de una crisis y lo que nos importa es una respuesta inmediata. No hay espacio para prueba y error.

Ejemplos de problemas caóticos pueden ser: la falla del sistema eléctrico de una ciudad o una avería en un avión en pleno vuelo. Son situaciones que deben ser solucionadas en el instante que se presentan.

Lo primordial en este tipo de problemas es actuar lo antes posible para contener la crisis y tratar de poner cierto orden intentando pasar al dominio de lo complejo, donde ya podemos analizar y actuar para prevenir que pase de nuevo.

La herramienta que más nos ayudará es la improvisación para estabilizar la situación.

Afortunadamente las situaciones caóticas son escasas, por lo que hay que tener mucho cuidado en no confundir algo urgente con una crisis.

Hay veces que puedes encontrarte en una situación en la que no consigues saber en cuál de los cuatro dominios puedes situar el problema. Cuando esto sucede podemos decir que estamos en un quinto dominio, el de lo desordenado.

Lo mejor que podemos hacer cuando estemos aquí es descomponer el problema en varias partes que podamos clasificar y manejar en cualquiera de los otros cuatro dominios y tratar cada uno de la manera que se requiera.

Debemos tener mucho cuidado de que nuestras preferencias personales no interfieran en nuestra forma de manejar la situación y mejor tratar de ser objetivos al conducirla.

En este dominio es donde podemos recurrir a los famosos esquemas híbridos, ya que habrá factores complicados que podemos tratar con marcos tradicionales y factores complejos del mismo problema que deberemos manejar con marcos ágiles.

Al final del día, como administradores de proyectos debemos contar con una diversidad de herramientas y enfoques que nos permitan hacer frente a una diversidad de problemas y situaciones, es decir, hay que tratar de ser agnósticos con las herramientas y no tener una preferencia por el marco a aplicar.

No existe un marco que sea mejor que otro así como tampoco existe una solución mágica a todos los problemas o proyectos. Por eso es esencial analizar cada situación, su contexto y factores antes de tomar alguna decisión.

Y ahora, entonces: ¿agile o no agile? Esa es la decisión.