No es ningún secreto que después de 10, casi 11 años siguiendo la metodología GTD® de David Allen, haya decidido abandonarla por completo, para empezar una nueva y renovada andadura en la senda de las metodologías Ágiles.

GTD® fue para mí y sigue siendo un excelente método de gestión y organización, no tengo nada en contra de GTD®, todo lo contrario, gracias a GTD®, conseguí muchas cosas, pero con el tiempo, dejé de estar “enamorado” de GTD®, dejé de sentir esas mariposas, esa motivación y entusiasmo por la metodología, su aprendizaje y su práctica.

La mente me pedía explorar nuevos caminos productivos, nuevas formas de organizarme, nuevas formas de organizar y gestionar el trabajo, nuevas formas de colaborar y trabajar en equipo, y fue en ese punto que empezó a picarme fuertemente el gusanillo por explorar, investigar y aprender otros sistemas de gestión y organización más allá de GTD®.

Empecé a tontear con las metodologías ágiles allá por el año 2016 – 2017, siendo Kanban y Scrum las que más llamaron mi atención de todas las metodologías ágiles existentes. Quizá porque desde mi inexperto punto de vista, pensé que eran las que mejor se adaptaban a mi entorno y situación personal y profesional.

Durante tres años (2017-2020), tuve diversas aproximaciones a la metodología Kanban, ya que, entre Scrum y Kanban, esta última fue la que más llamó mi atención y con la que me siento más cómodo.

Estas aproximaciones puntuales, quedaron en migraciones ocasionales de mi sistema GTD®, a tableros Kanban, pruebas de sistema, así como diversas lecturas, análisis y autoformación.

Pero llevaba demasiados años con el chip GTD®, y lo tenía demasiado metido en vena (con mis aciertos y mis errores), lo cual hacía que mis migraciones a Kanban fuesen fugaces, y el Mindset GTD® volviese a aflorar al poco tiempo, haciéndome sentir culpable de abandonar la metodología.

Fue una lucha interna, entre querer abandonar el nido y explorar nuevos territorios, o quedarme en la seguridad del hogar, de lo que ya conocía y sabía utilizar en gran parte.

Sin embargo, cada vez que migraba mi sistema GTD® a Kanban, inconscientemente, rompía un poco más esa barrera o bloqueo mental que me hacía sentir culpable y permanecer en GTD®, hasta que finalmente hace ya un año, en enero de 2021, migré definitivamente todo mi sistema personal y profesional de GTD® a Kanban, diciéndole adiós a casi 11 años de aprendizaje de GTD®.

Disclaimer: Vaya por delante que mi formación en Kanban es totalmente empírica y autodidacta, basada en mi propio conocimiento, experiencia y aprendizaje. No soy experto ni tengo ninguna certificación oficial sobre esta metodología, sin embargo, debo reconocer que después de casi cinco años de lecturas de posts y libros, así como de la visualización de algunos vídeos, algo al respecto he aprendido. Seguro que hago algunas cosas mal, pero también estoy seguro de que hago otras tantas bien, esto no ha hecho más que empezar y es un constante camino de mejora continua.

El siguiente paso después de decidirme a abandonar GTD®, debía ser decidir sobre que herramienta o soporte iba a implementar mi sistema Kanban.

Como podrás imaginar, al igual que sucede cuando te metes en GTD®, hay toda una legión de herramientas y aplicaciones “Kanban Friendly”, esperando ahí afuera. Algunas específicas para el método Kanban, y otras más «generalistas».

Cuando digo herramientas específicas para el método Kanban, quiero decir que estas herramientas, ya incorporan o contemplan mecanismos de la metodología, como por ejemplo las clases de servicio, los Swimlanes o carriles horizontales, los portfolios, las dependencias y bloqueos, las políticas explícitas, así como las métricas y gráficas específicas de Kanban, como pueden ser el diagrama de flujo acumulativo, el tiempo de entrega o el tiempo de ciclo entre otros.

Cuando digo herramientas “generalistas” me refiero a herramientas que incorporan algún elemento de la metodología Kanban, como las columnas o etapas del flujo de trabajo, la visualización general del trabajo, pero que carecen de otros de los mecanismos específicos de Kanban como los anteriormente descritos.

Decidí que después de tantos años de probar y pasar por multitud de aplicaciones, no iba a obsesionarme, y no iba a empezar a dar saltos de una herramienta a otra.

Como siempre, no perdamos el norte y no nos equivoquemos, es importante tener en cuenta y recordar que la herramienta no es el fin ni el todo, y al igual que se puede hacer GTD® de forma totalmente analógica con lápiz y papel, el Kanban de David J. Anderson, tiene sus orígenes en pizarras o tablero físicos colgados en la pared, así que, si es factible hacer Kanban con un tablero físico, también es factible hacer Kanban con un tablero digital, por sencillo que sea, otra cosa es que este nos facilite más o menos la gestión del trabajo y/o la obtención de las métricas, pero ese problema, también lo tendríamos con un tablero físico.

Llegados a este punto, tuve claro que no quería meterme en «otra” suscripción, y quería aprovechar lo que ya tenía, así que ya tenía claras tres directrices:

• No obsesionarme con la herramienta.
• No saltar de una herramienta a otra como en mis inicios de GTD®.
• No añadir una nueva suscripción a mí ya saturadísimo inventario de suscripciones.

A título particular, tengo suscripción de Microsoft 365 Empresarial, y mi sistema de productividad basado en GTD® ya estaba montado bajo ese paraguas de la mano de Microsoft To-Do.

Por suerte, las suscripciones empresariales de Microsoft 365, tienen Microsoft Planner para la gestión de tareas y proyectos siguiendo los principios del método Kanban por básicos que sean, y yo, como te he dicho anteriormente, ya disponía de una suscripción empresarial a Microsoft 365, así pues… blanco y en botella. Microsoft Planner era mi nuevo aliado.

Planner es una de las herramientas denominadas “generalistas” puesto que se limita a visualizar el trabajo por carriles o etapas del flujo de trabajo, vendría a ser algo así como la conocida y famosa Trello, pero, a decir verdad, como te había dicho anteriormente, si Kanban se puede montar en una pizarra física colgada en la pared, ¿Por qué no se puede usar Planner para montar el sistema?

Pues claro que se puede usar Planner para hacer Kanban.

Planner no es perfecta, pero para mí es suficiente, y estoy seguro de que para muchas de las personas que puedan leer este artículo, también podrá cubrir sobradamente sus necesidades.

Poco a poco Microsoft Planner va mejorando, está activa en el plan de desarrollo de Microsoft 365, y va recibiendo novedades y mejoras, de hecho, en febrero de este año 2022, llegará el texto enriquecido a las notas de Planner, y en marzo de este mismo año, llegarán las recurrencias a las tareas. Si, lo sé, esas funciones son básicas y deberían estar implementadas desde el principio, pero que le vamos a hacer, ya he dicho que no es perfecta, Microsoft es así, y tiene su particular forma de hacer las cosas. ¿Alguien en la sala con línea directa a Satya Nadella para darle un tirón de orejas?

Además … como dije anteriormente, no quería tener que pagar por otra suscripción, ¿recuerdas? y el resto de mis sistemas ya están montados en diferentes herramientas de la suite de Microsoft, con lo cual obtengo un ecosistema de productividad cerrado e interconectado entre sí, ahorrándome el tener toda mi información repartida por diferentes servicios, y, por consiguiente, también tener que pagar por servicios externos.

El hecho de ser un ecosistema cerrado e interconectado, quiere decir que si creo un documento Word en mi disco duro online (OneDrive) este documento Word, lo podré encontrar y vincular en prácticamente cualquiera de las herramientas de Microsoft que utilizo sin necesidad de sincronizar o tener que ir a buscar el archivo a otro servicio externo.

Este artículo es un ejemplo de ello, lo estoy escribiendo con Word Online desde la carpeta borradores que tengo creada en Microsoft OneDrive, lo cual quiere decir que lo tengo disponible al momento en OneDrive, SharePoint, Teams, Planner o OneNote.

¿Qué me ofrece Kanban que no me ofreciese GTD®?

Como he dicho antes, para empezar, me ofrece un soplo de aire fresco, demasiados años con GTD®, necesitaba un cambio.

A parte de eso…

Libertad

Libertad, si, libertad, la libertad de adaptar mi sistema y mis flujos de trabajo, la libertad de añadir o quitar etapas a mi flujo de trabajo según el contexto en el que estoy sin sentirme mal por modificar el sistema.

Según mis necesidades, puedo crear un simple flujo de tres etapas [Por hacer], [Haciendo], [Hecho].

O puedo crear un flujo más avanzado con un mayor número de etapas o slots. Si el contexto de ese flujo de trabajo varía, puedo ampliar o reducir las etapas del flujo de trabajo según se requiera.

Simplicidad

Simplicidad, una simple tarjeta con un enunciado es suficiente, no hace falta que redacte largas descripciones para el título de la tarea. Ojo y que conste que es verdad que reconozco que una descripción bien detallada de una tarea aporta claridad sobre su objetivo a la hora de elegir de entre una lista de acciones a realizar, pero sinceramente yo, Josep María Martínez, en mi caso particular y concreto, con una descripción más simple y escueta tengo más que suficiente para saber de qué se trata la tarea solo viendo su enunciado.

Además de lo dicho anteriormente, volvemos de nuevo a los flujos de trabajo, un simple flujo de tres etapas puede ser suficiente para gestionar tareas o proyectos. No sería lo más adecuado teniendo la posibilidad de definir más etapas o estados, pero en caso necesario, sería suficiente.

Claridad

Imagina una lista de tareas con 50 o 100 tareas, una debajo de otra, es abrumador, ¿verdad?

Esas tareas, pueden tener diferentes estados, es decir, las tareas no son binarias, no son 1 o 0, no son pendiente o hecha, no son encendido o apagado, las tareas pasan por diferentes etapas.

Como mínimo, las tareas, en esencia, seguro que pasan por tres etapas.

Es imposible que una tarea que está «Por hacer”, pase a “hecho”, sin previamente pasar por “haciendo”, creo que en eso estaremos todos de acuerdo, ¿no?, aunque no uses Kanban, aunque uses cualquier otro sistema de productividad, cualquier tarea activa que vaya a realizarse, tiene que estar en algún momento en uno de esos tres estados.

A partir de aquí, como te decía antes, Kanban aporta claridad, en una lista de tareas con 50 o 100 tareas, no tienes constancia de que tareas están por hacer, y que tareas se están haciendo, doy por sentado que las que ya están hechas las tachas y desaparecen de tu sistema.

La lista de tareas sería el equivalente a ver una ciudad a pie de calle, imagina que estás en una calle y miras hacia adelante, como mucho tendrás el detalle de lo que hay a pocos metros alrededor de ti, sin embargo, si subes a un helicóptero y miras la ciudad desde las alturas, tendrás una vista más amplia y detallada de todo lo que hay y te podrás hacer una idea mucho más concreta de dónde está cada cosa.

Lo mismo sucede con Kanban, el hecho de visualizar el trabajo plasmado en un tablero te aportará una vista de pájaro y hará que rápidamente te puedas hacer una idea sobre la situación del trabajo de ese tablero, ya sea que el tablero represente un proyecto, o una lista de tareas de departamento.

Gestión de prioridades

En GTD®, y en productividad en general, se enseña que vivimos en un mundo VUCA, Volátil, Complejo, Incierto y Ambiguo, y es verdad, los entornos personales y profesionales actuales son totalmente líquidos y cambiantes, y más desde que irrumpió en nuestras vidas el maldito Coronavirus.

Como decía, GTD® está en contra de las prioridades, Urgente, Importante, Prioridad alta, prioridad media, prioridad baja…. y eso es bueno, porque en un entorno VUCA, lo que hoy es urgente, mañana no lo es, lo que ahora es prioritario, en 60 minutos deja de serlo, y, por lo tanto, establecer prioridades del tipo P1, P2, P3, o urgente, importante, o Prioridad alta, prioridad media, prioridad baja, es absurdo, porque se tendrían que estar cambiando las prioridades constantemente.

Kanban gestiona prioridades, pero lo hace de otra forma que desde mi punto de vista tiene mucho más sentido que no el simple concepto de prioridad urgente o no urgente.

Kanban gestiona prioridades a través de dos entidades las cuales van unidas

CoS o Clases of Service (Clases de Servicio)

CoD o Cost of Delay (Coste de Retraso)

Básicamente de forma resumida y rápida.

De forma muy muy pero que muy simple y para que lo entiendas fácilmente, las CoS o Clases de servicio, son nomenclaturas o “etiquetas” que se ponen a las tareas para saber el CoD o Coste de retraso.

Las CoS (Clases de servicio), son una forma altamente configurable y versátil, para hacer frente a situaciones complejas, ambiguas, cambiantes e impredecibles. Las Clases de Servicio, son un conjunto de políticas que ayudan a los equipos a priorizar los elementos de trabajo y los proyectos, porque si, en Kanban se puede priorizar tareas y proyectos, e informar de las Clases de Servicio en ambos elementos.

Al igual que en GTD® existen los contextos @Ordenador, @Teléfono @Persona @Lugar @Herramienta …. en Kanban, como hemos dicho, tenemos las CoS (Clases de servicio), la metodología propone cuatro clases de servicio, pero, estas se pueden adaptar a tu escenario actual, añadiendo más CoS según tus necesidades o las de tu equipo.

Las clases de servicio propuestas por Kanban son:

• Expedite (Urgente o prioritario)
• Fixed Delivery Date (Fecha de entrega fija)
• Standard (Estandar)
• Intangible (Intangible)

Yo en mis sistemas Kanban personal y profesional, tengo una clase de servicio más llamada «Preferential» (Preferente) y estaría situada entre Fixed Delivery Date y Expedite

Así pues, las CoS no son más que identificadores para priorizar los items de trabajo o los proyectos, ahora bien…. la priorización de estas clases de servicio depende del coste de retraso de la tarea, es decir, que impacto va a tener en el cliente, en la empresa o en nuestros resultados.

Por ejemplo:

• Restablecer Servidor ERP (Expedite)

Coste de retraso elevado, si no restablecemos el servicio cuanto antes, tendremos serios problemas, dado que todos los usuarios están parados. Cuanto más tiempo tardemos en solucionarlo, mayor es su coste de retraso. Puede poner en riesgo la supervivencia de la organización

• Instalar procesador de textos al usuario x (Estándar)

Coste de retraso medio. Cada día, horas, semanas o meses que se retrasa su ejecución, va aumentando el coste de retraso, no ponen en juego la organización, pero pueden llegar a convertirse en Expedite si la demora en su ejecución es importante.

• Mejorar el mobiliario de la oficina (Intangible)

Coste de retraso bajo. Pueden retrasarse mucho tiempo con un coste de retraso muy bajo, no obstante, en el futuro si demoramos indefinidamente su revisión o ejecución, pueden llegar a tener un coste de retraso más elevado o incluso llegar a convertirse en Expedite.

Como ves, las clases de servicio nos permiten gestionar riesgos en lugar de prioridades, así como la previsibilidad en los plazos de entrega.

Así pues, aplicando Clases de servicio a mis tableros, puedo priorizar mucho mejor que elementos de trabajo hago antes o cuales requieren una mayor atención.

Para no alargar más este artículo, en otro post, te contaré con más detalle cómo funcionan las Clases de Servicio en Kanban.

Métricas y evolución

Vale, no vamos a obsesionarnos con las métricas, pero es importante tenerlas en cuenta para saber cómo de efectivos somos, y como podemos mejorar.

Existe una frase que erróneamente se atribuye a Peter Druker, la cual era originaria de William Thomson, físico y matemático británico.

La frase me encanta, y dice tal que así:

“Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre”.

Kanban y Kaizen van de la mano. En japonés, Kaizen significa mejorar o cambiar a mejor, y su filosofía es la de mejorar los procesos aplicando pequeños cambios, positivos, evolutivos, incrementales y continuos en todos y cada uno de los niveles de la organización, eso quiere decir desde el empleado de rango más bajo hasta el directivo con cargo más alto.

Mejorar los procesos de negocio y flujos de trabajo, puede compararse con afilar una sierra. Para que un leñador pueda realizar su trabajo de forma efectiva, tiene que mantener la sierra afilada y proporcionarle unos cuidados, no es algo que se realiza una sola vez y la sierra se mantiene afilada de por vida.

El objetivo de Kaizen es aplicar esos pequeños cambios evolutivos e incrementales constantemente para mejorar los procesos y que la organización, el proyecto o el sistema siempre se mantengan a pleno rendimiento y de forma evolucionada.

Saber cuál es el tiempo de entrega y el tiempo de ciclo de un ítem ya sea tarea o proyecto es importante para poder hacernos una idea de cuánto tiempo tarda un ítem desde que entra en nuestro sistema hasta que lo finalizamos, o por el contrario, poder saber cuánto tiempo pasamos trabajando en un elemento de nuestro sistema desde que lo iniciamos hasta que lo completamos. Estas dos métricas son de las más importantes en Kanban, y son el Lead Time (tiempo de entrega) y el Cicle Time (tiempo de ciclo)

Gracias por llegar hasta aquí y leer este artículo. En otro artículo te cuento más sobre las prioridades en Kanban.

Créditos Imagen de cabecera: Photo by Lala Azizli on Unsplash