El hecho de trabajar con metodologías ágiles como Scrum, y aplicar técnicas de productividad personal, como GTD, deja ver lo parecidos que son ambos sistemas.

Scrum define un conjunto de prácticas, que son llevadas a cabo por un equipo,  cuyo objetivo es la colaboración para crear juntos un proyecto. Se definen una serie de roles con ciertas responsabilidades, que favorecen el flujo del trabajo y productividad de todos los miembros del equipo.

GTD es una técnica de productividad personal, que nos permite tener una visión de nuestros objetivos (personales y laborales) junto con  las tareas que hemos de llevar a cabo para alcanzarlos. Propone un flujo de trabajo que hemos de repetir periódicamente y revisar, para poder adaptarlo a nuestras necesidades y contextos de vida. Este proceso nos permite tener más control sobre nuestras acciones, saber qué, cómo y cuándo hemos de hacer las cosas, y así liberarnos del estrés lo máximo posible, ese que se genera cuando dejamos todo para última hora.

La forma más sencilla para ver la similitud de estos sistemas, es identificando las diferentes fases de sus flujos y explicando el objetivo de cada una de ellas.

Scrum Product Backlog vs. GTD Collect

En esta fase recopilamos todo lo que tenemos que, supuestamente, hacer. Esta información puede tener orígenes diversos, desde las personas que nos piden algo, los contextos del proyectos si son personales o laborales e incluso, los  medios de comunicación desde el cual nos llega la petición como son un email, llamada de teléfono, una nota de una reunión, una idea. La información debe ser almacenada en algún sistema a partir del cual, nosotros podamos empezar a trabajar.

En el desarrollo de software con metodologías ágiles, se crea una pila de producto (product backlog), con todas las tareas que se desean llevar a cabo para su creación/mejora/corrección de errores. En GTD se definen contextos donde se agrupan (collect) los proyectos que hemos de llevar a cabo.

Scrum Sprint Backlog vs. GTD Process

Ahora que tenemos todas las tareas agrupadas, debemos analizarlas, procesarlas,  entrar en detalle. En primer lugar hemos de decidir si es algo que realmente debamos hacer, y sólo en caso afirmativo, debemos indicar el objetivo que se pretende alcanzar, la motivación, y qué hacer en la tarea poder completarla. Puede darse el caso en el que, la tarea sea de gran tamaño y debamos dividirla.  Debemos tener objetivos que podamos cumplir en poco tiempo para tener una sensación de avance constante. Evita la sensación de hacer algo donde te sientas estancado y tenlo en cuenta a la hora de definir tus acciones.

La pila de trabajo de un Sprint (sprint backlog), periodo de tiempo en el que un equipo se centra en ciertas tareas, debe tener todos los requisitos de cada tarea que lo componen, de la misma forma que cada acción en GTD al ser procesada.

Scrum Sprint Planning vs. GTD Organize

Una tarea, desgranada con acciones definidas, hemos de hacerla pero no en cualquier momento. Elegir cuándo, marca la planificación de un periodo de tiempo de trabajo, sea un día, semana o mes. Conocer la prioridad de la tarea es fundamental, para seleccionar la fecha de nuestro calendario donde deseamos abordarla. Una vez la tarea tiene una fecha, podemos olvidarnos hasta entonces, ya que durante ese tiempo, habrá otras acciones ya programadas sobre las que debamos concentrarnos, ocuparán nuestro atención, energía y esfuerzo.

La fase organize de GTD, tiene su pareja en la planificación de una iteración de trabajo, denominada sprint planning en Scrum.

Scrum Development vs. GTD Do

Llega el día, la hora, el minuto, en que el que hemos de ponernos en acción. Sabemos lo que tenemos que hacer, pues ya procesamos la tarea para crear una  acción que posee un inicio y un fin.  Lo más importante en este punto es, elegir el mejor personal para la tarea que vas a hacer. Si requiere mucha concentración, opta por las horas en las que estás más fresco y con mejor rendimiento mental. Si es una tarea mecánica, elige esas partes del día en las que quizá tu factor de concentración sea más bajo, pero el suficiente para hacer el trabajo correctamente.

En GTD esta fase se denomina do, y en Scrum orientado a procesos de ingeniería de software, lleva el nombre de development.

Scrum Retrospective vs. GTD Review

La revisión es fundamental para que todo sistema, mejore de forma continua, prospere y se adapte a nuestras necesidades. Preguntas que debemos hacernos para extraer buen feedback de la revisión.

  1. ¿Qué hemos conseguido de lo planificado?
  2. ¿Qué no hemos conseguido? ¿Por qué? Es necesario poder evitarlo en la siguiente planificación.
  3. ¿Qué nuevas tareas/proyectos han entrado para procesarlos y planificarlos?
  4. ¿Qué tareas se han quedado por hacer y hemos de replanificar?

En GTD esta fase de review se recomienda hacer semanalmente. Su homóloga en Scrum que se denomina retrospectiva, las decisiones de mejora del sistema se toman en equipo, y debe hacerse cada fin de Sprint.

Principios fundamentales:

  • Respeta y sigue siempre el flujo de cada sistema. Cada fase depende de la anterior y es necesaria para la siguiente, se realimentan. Saltarte un paso sólo provocará que pierdas información, control y debas volver a empezar.
  • Mantén el flujo simple y funcionará.
  • Fuerza de voluntad y constancia. De esto depende el éxito de todo flujo de trabajo, en equipo o personal.
  • Mejora continua. La revisión del sistema es obligatoria para hacer el procedimiento evolucione y aporte cada vez más valor.
  • Asume que todo lo planificado, puede hacerse otro día. La vida está llena de sorpresas, la planificación permite elegir el mejor día para hacer algo, pero si no es así, simplemente cambia la fecha de la acción.
  • Los imprevistos son parte de tu día a día. Deja siempre tiempo para atenderlos, acepta que consumen un porcentaje de tu tiempo. Si éstos no aparecen, puedes adelantar tareas del día siguiente
  • Conócete a ti mismo. Piensa cuáles son tus horas más productivas y aprovéchalas para las tareas que requiere mayor concentración y/o son los objetivos del día más importantes.

A continuación se muestra una imagen con un breve resumen de cada uno de los puntos anteriores.

Agile y GTD

5 pensamientos

  1. Yo también creo que el GTD es una buena solución para los problemas de productividad pero muchas veces se necesita algo más, y hablo porque lo probamos durante mucho tiempo, pero al final tuvimos que echar mano de un software de productividad con el que realmente conseguimos alcanzar nuestros objetivos. Dejo link con diferentes softwares de productividad por si le pudiera interesar a alguien.

  2. Hola Vanesa,

    Mil gracias por el post!

    Sabes algún libro de Agile o Scrum para empezar? Un equivalente al gran libro de Jose Luis Bolivar para GTD?

    Un saludo,

    Andreu

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s