6 Ways Agile Results is Better than GTD

Here’s a short, fun article about why I prefer JD Meier’s Agile Results as a foundational productivity system more than Getting Things Done (GTD).

Not that GTD isn’t awesome, it just misses a lot of things given the complexity of our lives nowadays. If you’ve been on the edge about switching to Agile Results, here are 6 great reasons why.

1. Agile Results incorporates goals and outcomes

The one thing GTD really lacks is that 30,000ft cruising-altitude view of your life. With list-upon-list of tasks and more contexts that you can count, there is no real way to zoom out and get a good look at everything going in your life.

When you use GTD, it’s all about the tasks – and all tasks are pretty much equal. You just pick a context and go, regardless of your mood, energy level or deep priorities. This can be great in some situations… and disastrous in others. Simply putting things into a system and then processing things out may be efficient, but you have to put the right things in, otherwise you get garbage-in-garbage-out:

Agile Results lets you create tasks lists based on what is important to you – today, this week, this month and this year. It also has the flexibility to recognize that you may not want to do a particular type of tasks today, and to neatly move those tasks to a better time and place.

2. Agile Results incorporates GTD… sorta

About 95% of Agile Results is about structure, setup and psychology. 5% is processing tasks – that 5% is where you take what you know about GTD and plug it in to crunch action items.

3. Agile Results also teaches the psychology of productivity

GTD is a very mechanical system – which is why it works brilliantly for some, but explodes spectacularly for others.

Agile Results tries to teach you the mindsets, habits and principles behind real productivity as well as the mechanical structures you need to help you work productively. For example, concepts like “death by a thousand papercuts” or “have a compelling why” are important parts of making any productivity system work.

4. GTD was designed for pen and paper

That’s right – GTD was written in the early 2000s for pen and paper applications. True, there are applications like OmniFocus which have made GTD digital, but the system itself is really a classic no-computer-on-desk one.

A great example of this is contexts – when was the last time you thought about contexts as tools or distinct environments? Most knowledge workers today have one tool (a computer) and the environment really doesn’t matter that much – office, coffee shop, study, park – you can work productively from any and all of them.

Agile Results comes with the recommendation to implement it in one of the greatest tools of the modern day – Evernote.

5. Speed, cycles and iterations

Once established though, Agile Results incorporates ideas about iterations and cycles very, very well. If you mess up today, you can easily do a reset and have a better tomorrow. It recognizes that life is not linear and that it has its ups and downs. It follows the natural cycle of planting, reaping, resting and renewing, and recognizes that we can get better with every cycle.

6. GTD is crisis management. Agile Results is systems creation.

GTD is really about the day-to-day grind and crunching of tasks and inbox items. Agile Results is about setting clear outcomes that you want and then systematically working towards them.

If you are a systems thinker (or just enjoy systems that work), Agile Results is fantastic – you can set up your ideal system or vision, then break it into smaller outcomes at different discrete timeframes, and then into tasks beneath that. This helps you to really focus in on what is important, rather than handling the crisis-of-the-day.

Using OmniFocus? We’ve included a new post on implementing Agile Results in OmniFocus in our OmniFocus guide – OmniFocus Premium Posts.

For more on the psychology and habits of productivity, check out the Asian Efficiency Primer. It contains all our best content in one place.

Do you want to see more examples of our personal systems and workflows? We reveal them all on our Personal Systems seminar. It’s completely free and you’ll get to see the exact step-by-step systems and workflows that we personally use to be insanely productive. Register for the next available seminar here.

14 Comments

Funny, but most of what you claim as advantages is actually stuff GTD has and does. Including the fact that allen was a Palm-user when he wrote the book (bust most of his readers were still pen & paper). The 30000 ft metaphor even is from the GTD book, so how can you say it lacks this perspective? (OK ‘Making it all work is more about the levels of horizon than the original GTD-Book is… But I’ll have a closer look at AP…

I’m new to Agile Results but a die-hard GTD practitioner. The very first point in this comparison about “GTD not incorporating goals and outcomes” is a misguided comment. Its the limitation on the tools that try to implement the GTD methodology but not on the actual methodology itself. David Allen very clearly defines the six horizons of focus, right from run-way actions to 50,000 feet view. David also makes it clear -“You are more mature tomorrow than what you are today and hence your goals keeps evolving constantly and you set higher standards for yourself”….so very true. Aaron pls pick up the GTD book again and update this post please.

I think that you only read the first half of GTD (if that). You only seem to know about the “Workflow management” model. The GTD methodology is a framework of at least three models: Natural Planning Workflow management Horizons of focus

Love the article, I will add Agile Results to my “to read” stack/list. You did make it sound very nice, plus “improving my capacity” is one of my areas of focus.

Hi Great site. First time visitor. Gonna read many of your posts. I have been a long time user of GTD and OmniFocus, and while I am intrigued by Agile Results, I think you are wrong in your comparison to GTD. Yes, GTD describes how to manage your tasks, but it is far more than that. In fact, isn’t it David Allen who invented the analogy of Runway – 50.000 feet? In both GTD and even more so in Making it All Work he describes how to use the contexts of the different altitudes when deciding and reviewing the contents of the other altitudes. Your tasks should be part of a project. Your projects should be within your areas of responsibility. Your responsibilities should reflect your short term goals. Your short term goals should help achieve your long term visions. Your visions should comply with your values and life purpose. He goes pretty deep on how you must be aware of your 30-50.000 feet to be certain that what your are doing is what you should be doing.

Perhaps I will understand what you mean and agree with you once I have read up on Agile Results, but from what I have read here you are downplaying David Allens philosophy.

I really enjoyed this post, thank you. I started AR through the author’s Getting results in 30 days and have found it exciting and painless, almost organic-growing a new system of doing things. Another quote similar to B. Lee’s (love all of lee’s and franklin’s works)- “Does’t thou love life? Then do not squander time, for that is the stuff life is made of.”

I’ve been trying to simplify my GTD workflow for a few years now but I somehow always failed to manage my tasks and projects from the higher perspective. I felt like there’s something missing, some guidance and/or insight how to do that right in order to achieve results. And it seems I found AR to be a perfect fit for this!

More than that, I’m one of the main developers in our startup called Goalscape (http://www.goalscape.com) working several years on a visual tool for managing goals and tracking their progress. We aimed to adapt it to GTD at the beginning but found it quite impossible as the main concept in Goalscape tool was more outcomes-oriented than tasks-oriented.

And now I see that our concept could perfectly match with Agile Results methodology! So I’d love to hear what you guys think about Goalscape and if you see a fit for it in AR workflow!

GTD flow is basically 1. Collect, 2. Process, 3. Organize, 4. Review and 5. Do. I like Agile Results for the Review and Do. GTD allows for the “stuff” to be collected but seems limited in guidance for the high-level reviews and planning. I use Agile as the top layer on GTD. OmniFocus, Evernote and some simple text files are the tools. Read Meier’s book and then use the Asian Efficiency guides to get started on this.

I recently decided to switch to Agile from GTD for many of the same reasons, and have found once I understood the concepts, I feel more in control of the overall picture. I definitely wanted to simplify things, and thinking about 3 things for the week, 3 things for the day, etc, has definitely improved my productivity. Plus since I’m using Evernote for everything now, it makes my workflow much simpler and easier to manage.

I’d love to see more posts on Agile and specifically how to implement with EN – there’s always something to learn. thanks for the great post.

Surely, GTD is just a set of ‘tools’ to help with mind management. It doesn’t prescribe being mechanical at all – in fact David Allen keeps saying that the only way you can be truly relaxed is by being fully aware of what one isn’t doing in the moment i.e having the ability to actively choose from a complete inventory of tasks what one wants to do or not.

Having been a fan of Stephen Covey , I am only too aware of how being too cerebral about higher level things can result in obsessing about the methodology at the expense of being effective.

Yes that’s a good point. The challenge for most people is choosing the task and if you don’t know your 30k horizons and up, you can end up wasting time. That’s why outcomes and goals are crucial which makes Agile Results more fluid in what you do.

Thanks for this timely post. I’ve been an Omnifocus/GTD man for sme years now, but I’ve still found very challenging to get the *right* things done. I read your Agile guide whilst on holiday last month and I’ve no doubt it’s better suited to my mindset and the challenges I’m currently facing. I haven’t implemented it yet, partly because the complexity you mention is a little daunting, and partly because I’m so “busy” – I know I’d be less “busy” if I took some time out to set up and implement Agile, but there’s a financial imperative – I have to get certain tasks done before I can pay myself and my bills, and I’ m having difficulty justifying to myself taking a day out to set up Agile and understand it properly. Catch 22!