Escuchamos muy a menudo a profesionales hablar sobre la implantación de la metodología Agile en sus compañías o el uso que hacen del Design Thinking para incentivar la innovación. Las metodologías tienen tanto peso en la industria que incluso se utilizan hoy como reclamo de venta.

Sin embargo, vemos que en muchas ocasiones se confunden las metodologías con las herramientas y procesos.

Parece que muchos creen que el uso de procesos y herramientas basta para poder decir que en una empresa trabajan bajo una metodología. Sin embargo, nosotros creemos que lo importante de una metodología está en su filosofía.

¿Haces Agile o eres Agile?

Muchas veces, nuestros clientes nos preguntan si “hacemos Agile”. Nosotros siempre contestamos que somos Agile. En Machiina creemos firmemente en el manifiesto y lo seguimos teniendo en cuenta nuestras características y necesidades y las de cada proyecto que vamos a abordar. No dejamos que los procesos se interpongan entre nosotros y los objetivos que nos hemos marcado y dedicamos tiempo semanal a investigar y probar nuevas tecnologías que nos pueden ayudar a agilizar nuestro trabajo y mejorar los resultados.

Lo que se suele interpretar como “hacer Agile”es una aproximación desde la que no se profundiza en su filosofía y muchas veces se queda en una aplicación de procesos y herramientas de forma sistemática. Parece que adoptar SCRUM y Kanban como los procesos que rigen los proyectos ya es garantía de que ese grupo de trabajo “es” Agile.

Llegando al punto en el que la aplicación de Agile de esta manera, en nuestra opinión, va en contra del primer punto del manifiesto: “Individuos e interacciones por encima de procesos”. Esto ocasiona que, muchas veces, el cliente tenga las mismas frustraciones que tenía antes con otras metodologías que Agile venía supuestamente a solucionar.

Imagen sobre metodologías

Algunas de las razones por las que creemos que ocurre esto son:

  • En el transcurso del proyecto se pierde la visión global. El tratamiento del proyecto en pequeñas piezas puede hacer que se desdibuje el objetivo para el que nació o que se la hoja de ruta se haya quedado tan obsoleta que ya nadie sabe por dónde seguir para alcanzar el objetivo.
  • Se generan una serie de expectativas en el cliente: agilidad (lo vamos a hacer en mucho menos tiempo), entrega de valor desde el principio (a veces al cliente le cuesta verlo en ciertas entregas parciales), etc, que luego cuando no se cumplen originan el efecto contrario al que se pretendía “haciendo” Agile.
  • El cliente no puede seguir el ritmo de feedback marcado, retrasando el proyecto en cada interacción con él. Aunque al principio la idea de participar tan activamente en el desarrollo del proyecto le gusta mucho, la realidad es que no siempre va a poder seguir el ritmo necesario.
  • Cuando el producto o servicio final se enseña al resto de la compañía y no lo ven ajustado a sus necesidades. Conocemos casos en los que la comunicación entre la empresa cliente y la agencia o consultora se centra exclusivamente en el Scrum Master y el Product Owner. Esto puede ser una gran ventaja, pero si cada interlocutor no se encarga de mantener a su propio equipo bien informado, puede convertirse en un gran problema.
  • Se generan MVPs que carecen de valor para los usuarios. A veces la premura por salir cuánto antes y seguir iterando puede llevar al desastre en la respuesta de los usuarios, como ya comentamos en nuestro post: del MVP al MAP o Producto Mínimo Accionable.

Para evitar que ocurran este tipo de cosas es importante conocer el origen de las metodologías. Debemos ser conscientes de que las metodologías nacen para dar respuesta a necesidades concretas.

Volvamos al origen de las metodologías

El Design Thinking nace como guía para facilitar la resolución de problemas de forma creativa. Además utiliza una visión centrada en el usuario para enfocar todos los esfuerzos en la dirección indicada y se marca unos tiempos con el fin de no perderse en el mundo de las ideas.

En el caso del Agile, nace como respuesta a las necesidades que tenían las empresas de desarrollo de software a mediados de los 90 que, por la naturaleza de su trabajo, necesita capacidad de reacción ante cambios de requisitos durante el proyecto.

En realidad si analizamos la filosofía de ambas metodologías, las dos persiguen fines muy parecidos:

  • Las dos proponen poner a las personas en el centro. Design Thinking a través del user-centered design. Agile en el primer punto de su manifiesto “personas e iteración sobre procesos”.
  • Intentan minimizar riesgos, mediante la generación de prototipos por el Design Thinking o controlando el desarrollo a través de sprints desde el Agile.
  • Procuran involucrar a todos los implicados con la co-creación desde el Design Thinking o con el sistema de reuniones de Agile para que todas las personas sepan en qué punto se encuentran cada uno.

Cada una a su manera y teniendo en cuenta sus peculiaridades, las dos persiguen la eficiencia. Partiendo de dos escenarios muy diferentes, las motivaciones que les mueven son parecidas.

Pizarra de control de desarrollo

Metodologías antes que herramientas y procesos

Para aplicar de forma eficiente una metodología en una organización lo más importante es entender que una metodología es mucho más que sus procesos y herramientas. Estos son meras guías que sirven de ayuda para alcanzar los objetivos que marcan sus filosofías.

Entender el origen de las metodologías y su filosofía, nos permite saber para qué se crearon y entender qué problemas nos pueden ayudar a resolver. De esta forma podremos encontrar paralelismos con problemas del día a día donde su aplicación nos pueda aportar valor.

También es importante conocer nuestra organización. Debemos ser conscientes de nuestros puntos fuertes y débiles para poder extraer de cada metodología lo que más se ajuste a nuestras características y evitar aquello que no nos aporte soluciones.

Por ejemplo, si tenemos a alguien de negocio encargado de la supervisión de un proyecto con una agencia y suele tener una agenda apretada de reuniones y viajes continuos, quizás, SCRUM no será el proceso de gestión de proyecto que mejor se ajuste a sus necesidades.

O en el caso de que nos enfrentemos a un proyecto con un cliente muy tradicional que busca resultados pero no quiere nada fuera de lo común, algunas herramientas del Design Thinking le pueden generar mucha ansiedad y la sensación de pérdida de tiempo.

Seguir unos pasos definidos de un proceso o una herramienta solo nos aportan un orden. Creer que la metodología solo son sus herramientas es creer que existe una receta de éxito infalible. Es imprescindible adaptar la metodología a las características de la empresa y es ahí donde está la verdadera dificultad de aplicación y, a la vez, la gran ventaja.