La fecha de publicación de “Organízate con eficacia” coincide en el tiempo con el “Manifiesto Agile”. Justo en 2001, cuando llegó un grupo de expertos a señalar las diferencias entre las metodologías Waterfall (válidas para entornos sencillos y repetitivos) y las metodologías Agile (válidas para entornos complejos e imprevisibles), nació GTD®. Y aunque decía satisfacer las necesidades de los trabajadores del conocimiento (flexibilidad, adaptación al cambio, modernidad,...) la realidad es que se alinea en su definición con los esquemas de funcionamiento del modelo Waterfall y así queda retratado tras su publicación.
GTD® QUIERE SER “AGILE” PERO ES “WATERFALL”
MANIFIESTO AGILE: Waterfall vs. Agile
El Manifiesto Agile, fechado el 12 de febrero de 2001, no es más que una declaración formulada por un grupo de profesionales del sector de desarrollo de software. Su intención era poner en común sus experiencias respecto a las formas mejores de trabajar y extraer conclusiones válidas que pudieran resultar de ayuda a terceros.
Aquello supuso una manera muy explícita de marcar distancias con las técnicas tradicionales de gestión de proyectos (modelo en cascada o Waterfall), por su falta de adecuación a los nuevos modelos de negocio, nacidos al amparo de la era digital.
Efectivamente, Waterfall es un sistema de gestión de proyectos en el que el desarrollo de producto sigue un ciclo secuencial de etapas que se ejecutan una tras otra. Se asocia habitualmente a entornos industriales, donde las actividades son más repetitivas y el proceso es más previsible. Las distintas fases que componen el proyecto, colocadas una encima de otra, fluyen de arriba hacia abajo, como una cascada. Lo vemos en el siguiente gráfico:
Lo que hace Agile es, justo para diferenciarse del modo de hacer imperante hasta la fecha (Waterfall), definir una serie de valores y principios:
- Prevalecen los individuos e interacciones sobre los procesos y herramientas.
- Es más importante que haya producto funcionando antes que documentación extensiva.
- Se pone por delante que exista colaboración con el cliente antes que negociación contractual.
- Se da más valor a la capacidad de ofrecer respuesta ante el cambio que a la de seguir un plan.
Que la balanza se decante por la parte de la izquierda no implica que tengamos que renunciar a la parte de la derecha. Ser Agile no significa renunciar a las herramientas, pues son elementos necesarios que facilitan nuestro trabajo, pero teniendo claro que son solo eso. Ni que vayamos a dejar de documentar, pero sí que esta documentación sea la estrictamente necesaria. Tampoco vamos a renunciar a los contratos, pero debemos saber que los contratos ágiles deben ser más abiertos al cambio y estar más basados en la colaboración. En último término, huelga emplearse a fondo en elaborar un plan sabiendo que vamos a tener que gestionar el cambio para adaptarnos a nuevas necesidades.
LA CONTRADICCIÓN SUPREMA DE GTD®
GTD® se autodefine como un método flexible que se adapta a los requerimientos de los trabajadores del conocimiento. Además, critica de un modo rotundo a los métodos tradicionales de gestión del tiempo del siglo pasado por su incapacidad para adaptarse a los tiempos modernos. Justifican su existencia con el argumento de que la naturaleza del trabajo ha cambiado, desde el entorno industrial de la producción en cadena al trabajo del conocimiento.
Sin embargo, a reglón seguido, entra en contradicción flagrante consigo mismo y se deja caer, sin tapujos, en los brazos de la producción en cadena o del trabajo en serie. En 2015, uno de sus más fervientes seguidores y referentes, lo describió así:
“En mi opinión, la idea más innovadora de toda la metodología GTD® está encerrada precisamente en este método de los cinco pasos. Lo que hizo David Allen fue tomar una solución que ya se había demostrado eficaz en otro campo y aplicarla al trabajo del conocimiento. Me refiero, en concreto, a los principios de la producción en cadena, es decir, al proceso conocido como trabajo en serie”.
"Productividad personal" (Spanish Edition) (pp. 68-69). Penguin Random House Grupo Editorial España. Edición de Kindle.
De hecho, cuando a uno le vienen a la cabeza las cinco fases del proceso de pensamiento fundamental que David Allen plantea en GTD®, le resulta casi imposible no establecer una comparación con el esquema Waterfall. El parecido es, ciertamente, razonable. Por supuesto, esto no es malo en sí mismo. De hecho, no existe un único sistema válido para todos los entornos, sino que dependerá de las características propias del trabajo que se esté llevando a cabo.
El modelo Cynefin y la matriz de Stacey
El modelo Cynefin y la matriz de Stacey nos permiten relacionar los distintos escenarios ante los que nos podemos encontrar con los sistemas que resultan más recomendables en cada caso. En función de lo repetitivas y simples o de lo caóticas y complejas que sean las tareas a ejecutar nos encontramos con dos grandes grupos de esquemas de funcionamiento:
- el modelo Waterfall (“en cascada”) y
- las metodologías ágiles (Kanban, Scrum, Lean y eXtreme Programming).
Tan inapropiado resulta utilizar GTD® para gestionar los entornos complejos de los trabajadores del conocimiento como utilizar, por ejemplo, SCRUM para gestionar entornos obvios por predecibles y repetitivos. Cada método resulta idóneo para un tipo de entorno e inadecuado para otros.
Insisto, sin ser nada de lo que uno deba avergonzarse, lo que crea confusión es que, por un lado, se critiquen los antiguos métodos de gestión del tiempo por su falta de capacidad para adaptarse y, por otro lado, se declaren admiradores de la producción en cadena. Parece que no reconocen su esencia Waterfall pues les gustaría, quizá, ser más Agile. Sin embargo, desde el punto de vista de Stacey y Cynefin, GTD® parece a todas luces estar concebida para entornos simples, obvios y repetitivos, predecibles y con un grado de complejidad bajo.
Albergo la sospecha razonable de que uno de los principales motivos que justifican la dificultad de implementación de GTD® a entornos de trabajo propios del siglo XXI (que son complicados, complejos e incluso caóticos) se encuentra en esa traslación de los principios de la producción en cadena (trabajo en serie) al trabajo del conocimiento.
“Usando la metáfora de la cadena de producción, si estás montando ruedas, céntrate en montar ruedas”.
"Productividad personal" (Spanish Edition) (p. 133). Penguin Random House Grupo Editorial España. Edición de Kindle.
Al animarnos a aprovechar las sinergias que ofrece la producción en cadena, y al criticar a los que fabrican los coches uno a uno, Bolívar arremete contra aquello que predican las metodologías ágiles. Recordemos que en el modelo TPS (Toyota Production System) de Taiichi Ohno, que apuesta por mayor orientación hacia el cliente a través de una producción flexible y ágil, el cliente es quien “tira” del proceso al emitir una orden de trabajo (pull). Cuando una persona compra un libro físico de tapa blanda en Amazon, está lanzando la orden de su impresión, encuadernación y distribución. No hay stocks ni posibilidad de desajustes entre oferta y demanda.
Ante las grandes alabanzas que José Miguel Bolívar realiza en su libro al sistema de producción en cadena del siglo pasado, cabe preguntarse: si tan espectaculares fueron los incrementos de productividad conseguidos gracias a este modelo:
- ¿Cómo es que no seguimos trabajando como lo hacían entonces?
- ¿Se debió a un hecho casual el que TOYOTA, con su sistema de producción (TPS) propio alejado del fordismo y del trabajo en serie, acabara liderando el sector mientras que FORD quedara completamente superada?,
- ¿Cómo encajamos en ese planteamiento las críticas al modelo Waterfall formuladas en el Manifiesto Agile?
