10 valores de un sistema de productividad ágil

Nuestra habilidad para adaptarnos al cambio determina nuestro éxito

J. D. Meier

En su interesante libro “Getting results, the agile way”, J.D.Meier trata de aplicar las ideas de las metodologías ágiles a la productividad personal. El desarrollo de software ágil (agile, en inglés, pronunciado  /ˈædʒaɪl/) está de moda de nuevo, no sé si gracias a libros como “Lean StarUp” que ya hemos aconsejado aquí varios veces o por qué exactamente.

Resumiendo de manera bastante grosera podríamos decir que las metodologías ágiles nos proporcionan las herramientas adecuadas para obtener resultados en entornos altamente cambiantes y se basan en ciclos cortos y en el aprendizaje mediante el feedback que estas exposiciones ante el usuario produce.

Vale, pero, ¿es posible aplicar esto al mundo de la productividad personal?

Al igual que las metodologías ágiles se contraponen a las metodologías en cascada en el mundo del desarrollo del software, Agile Results, el método de Meier se puede contraponer al sistema GTD desde la perspectiva de que ambas (cascada y GTD) son métodos complejos y obsoletos, según los agilistas.

Personalmente, creo que tanto unos como otros no dejan de “vender un producto” y seguramente la virtud esté en el término medio (el “camino medio” al que se refiere Buda o el “medio dorado” del que hablaba Aristóteles).

Enunciaré aquí los 10 valores que, según J. D.Meier, constituyen un sistema de productividad ágil:

1) Acción frente a la “parálisis por el análisis”.

No te quedes puliendo tu sistema hasta que este sea perfecto sino pasa a la acción en cuanto puedas. Implementa un hábito, luego otro y aprende de tus errores.

2) Aproximación frente a resultados.

No puedes controlar tus resultados, sólo puedes controlar tu actitud, acciones y tu respuesta.

3) Energía frente a tiempo.

Prima la calidad las horas que dedicas a algo sobre la cantidad. La calidad viene dada por la energía así que enfócate en tu energía. La clave de la energía está en seguir tu pasión y vivir tus valores.

4) Foco frente a cantidad.

Esto no va de hacer más sino de hacer las cosas correctas.

5) Suficientemente bueno frente a la perfección.

Es mejor producir algo que puedes mejorar con ciclos de iteración que el bloqueo continuo que produce el estar centrado en la perfección.

6) Mentalidad de crecimiento frente a mentalidad fija.

No des nada por sentado. Una mentalidad de crecimiento viene dada por el hecho de que puedes aprender y obrar en consecuencia. La flexibilidad se convertirá en la clave de tus resultados.

7) Resultados frente a actividades.

Pasar más tiempo haciendo cosas no es una buena medida de la productividad. Los resultados son la mejor medida. Si tienes claro lo que quieres conseguir, puedes ser flexible en tu aproximación.

8) Fortalezas frente a debilidades.

Mejor que inviertas tu tiempo en maximizar tus fortalezas que en eliminar tus debilidades. Si quieres mejorar alguna debilidad, asegúrate que es una de las que más afecta a tus principales responsabilidades.

9) Sistema frente a ad hoc.

Tener un sistema que cubra lo básico hace que dispongas de un marco de referencia que permite liberar tu mente y que ésta se dedique a cosas más importantes. Pensar en todo esto cada vez que tienes que lograr algo es un sinsentido.

10) Crear valor frente a tachar tareas.

Más que pensar en ir tachando tareas de una lista, piensa en el valor que aporta lo que haces. Puede ser valor creado para ti o para otros. Pensar en términos de valor creado ayuda a responder a: ¿cuál es la próxima tarea que debería hacer?

Desde mi punto de vista hay muchas cosas interesantes sobre las que reflexionar.

Personalmente no creo que Agile Results sea incompatible con GTD, es más, creo que es la enésima simplificación de GTD, muchas de las cuales hemos analizado ya en este blog.

Lo que sí creo es que en el mundo de la productividad, y en cualquier otro, conocer los principios (valores en esta entrada) que subyacen nos permitirá construir un sistema apropiado para nuestras necesidades y, además, que este sistema sea cambiante y adaptable a las necesidades en cuestión.

No se trata de inventar la rueda se trata de saber de ruedas y calzar el neumático adecuado en función de la climatología.

  • Getting Results the Agile Way es un libro que se me ha quedado corto. Hay un montón de conceptos interesantes, como los 10 valores que mencionas en tu artículo, que simplemente se menciona sin elaborar en su origen ni en cómo trasladarlos a la vida real.
    Cada vez que leo el libro tengo la sensación de que aún no está acabado. Aun así, cuente con conceptos y estrategias muy interesantes.

    • Si, a mi también me está dejando una sensación similar aunque todavía no lo he acabado. No sé, creo que va en la buena línea al plantear un método simplificado pero, por otro lado, no veo que aporte demasiada novedad a lo que ya conocemos los que estamos "en el ajo".

  • franciscojsaez

    Interesante artículo, Rubén, como siempre.

    Sin embargo, estoy bastante en desacuerdo con la idea de contraponer conceptualmente GTD y las metodologías ágiles (disculpa, no sé si es un comentario tuyo o de Meier). Creo que GTD cumple todas las condiciones que hacen "ágil" una metodología ágil (según el manifiesto original por el desarrollo ágil de software). Es más, incluso cumple con cada uno de los 10 puntos con los que Meier identifica los sistemas de productividad ágiles ;)

    • No estoy de acuerdo pero, naturalmente, es mi opinión. A mi GTD me recuerda tremendamente a las metodologías en cascada de desarrollo de software y lo que pretenden Results, ZTD y otras simplificaciones es convertirse en el SCRUM de la productividad personal. El problema es que, primero, en mi opinión no lo consiguen y, segundo, al igual que en el desarrollo del software hay proyectos que requieren desarrollo en cascada y proyectos que requieren SCRUIM, es decir, el uso de una u otra metodología es coyuntural y no solo se adapta al individuo sino también a sus circunstancias del momento.

      No sé, rollos de informáticos que seguramente no interesan a casi nadie.

      • franciscojsaez

        Un día de estos subiré por ahí para invitarte a una cerveza y que me expliques eso de que GTD te recuerda a la metodología waterfall, porque no veo la similitud por más que lo intento :P

        • No estoy hablando de la metodología en sí, hablo del dogmatismo de quienes la enseñan y la usan. Eso de que o usas GTD Fullpack o estás perdiendo mucho de su potencia me suena mucho a la burocracia que tenemos montada en mi empresa alrededor de una metodología como METRICA donde se ha convertido la metodología y su "cumplimiento" en algo más importante que el resultado en sí. Ahora que nos estamos planteando hace algúnos proyectos con metodologías ágiles, creo que lo estamos planteando mal y corremos el riesgo de irnos al otro extremo: la ley del péndulo. No sé, me estaba leyendo la edición revisada del libro de Allen y me aburría tremendamente. Quizás porque lo tenga muy trillado quizás porque esté un poco cansado de GTD como panacea. Necesito interiorizar y. madurar estas sensaciones e iré escribiendo al respecto.

          • franciscojsaez

            Yo tampoco creo que GTD sea la panacea ni sirva para todo el mundo. Y también estoy contigo en que algunos "evangelistas" de GTD pueden ser demasiado vehementes y eso, de partida, genera rechazo. Pero hay que distinguir el grano de la paja.

            Si entrenas a un equipo de fútbol les dirás que para ganar partidos hay que hacerlo todo bien (tanto atacar como defender). Si solo haces una cosa bien, ganarás algún partido pero no ganarás a menudo.

            Cuando la gente dice que usar GTD parcialmente no funciona va en ese sentido, porque todos sus aspectos están de alguna forma relacionados. Si no capturas todo lo que te llega, no liberas tu mente. Si no lo aclaras todo, estás tratando con un montón de cosas abstractas. Y si no revisas todo lo anterior de vez en cuando, la información se queda obsoleta. Fallar en una de las cosas básicas te hace fallar en general, organizativa y productivamente.

          • Muy de acuerdo en todo lo que dices, sobre todo en lo de que si haces algo, por ejemplo recopilar, has de hacerlo siempre.

            Dos matices: puede ser diferente el planteamiento para ganar la liga, que para salvarse,que para pasar una eliminatoria a un partido que a doble vuelta o para la final del mundial. Todo es fútbol pero la estrategia y la táctica se construyen a partir de los recursos disponibles y teniendo en cuenta al rival y las circunstancias.

            El segundo: cuando hablo de GTD un fallo letal que he visto en repetidas ocasiones es esperar a implementar todo el sistema para usarlo realmente en tu vida. Eso es muy anti-agil, lo que te diría un agilista es que vayas implementando pasos y pruebes y construyas el sistema en base a tu propio feedback. Cuando la estructura se convierte en algo más pesado de lo que soporta, algo va mal…