Dirk Louwers bio photo

Dirk Louwers

Dirk works as a full stack consultant for Xebia and has been coding in Scala since 2007. He loves developing non-blocking highly scalable software solutions.

Twitter LinkedIn Github

This article is meant for knowledge workers that want to be more on top of things and feel secure that they haven’t forgotten about something, freeing their mind for the actual tasks at hand. It especially applies to those that are using or want to use SCRUM, a popular and formalized Agile methodology, in their day to day work.

I got hooked on Agile back in 2005, while working for Db4o, and never looked back since. Improving the process per iteration and having a manageable amount of work per sprint gave me peace of mind and focus, enabling me to deliver the right software solutions to the stakeholders. When I got asked to join a tech startup in 2011 as its CTO I suddenly had a lot more to deal with: hiring and managing staff, managing costs, reporting to the board, applying for subsidies and making sure the books were kept in order. On top of this I still operated as SCRUM Master and technical lead within a SCRUM team.

During this period one of my co-founders introduced me to Getting things done by David Allen. It took him only about 15 minutes to explain the basics and I got started with it straight away.

You can optionally watch this presentation to go along with the article:

Diverse responsibilities

As knowledge workers, and more specifically consultants, we have a diversity of responsibilities. You have personal responsibilities, like planning a doctor’s appointment or picking up your kids from daycare, and you have responsibilities from your employer like ordering a backup disk, co-creating a course or preparing a presentation. Lastly you also have responsibilities from your client, like sprint tasks, meetings and organizing innovation days. Truly staying on top of all these responsibilities is tough, real tough!

Agile

For those of you that are not familiar with Agile methodologies. Agile is an iterative process. In each iteration a team commits to a finite amount of work. A typical iteration has a length of two weeks, which is its deadline. All stories, the units of work in an iteration, can be made actionable by the Agile team.

GTD

Getting Things Done takes a slightly different approach. There is a single inbox, comparable to the part of a backlog in SCRUM, that hasn’t been groomed yet. By regularly reviewing the inbox, it can be emptied by turning items into actionable tasks, high-level projects, calendar items, reference material or just trash. Actionable tasks can be extracted from a project, that will move it forward. Actionable tasks should be kept together to be able to prioritize them upon review.

GTD Chart
GTD Chart

Please refer to the book Getting Things Done by David Allen in order to get the full explanation but below follows a quick overview.

Quick overview of GTD

Inbox

The purpose of the GTD inbox is to collect anything new that might or might not require your attention. Whenever something pops up into your mind that you think requires your attention, either now or in the future, you collect it here. It doesn’t need to be organised. It doesn’t even need to be an attainable goal. As long as you get it off your mind and file it away for review, the inbox has done its job. Reviewing the inbox will empty it into one of the following categories.

Trash

You may find that a lot of the things you collect in your GTD inbox don’t really require you to take any action at all, so you can throw them away with impunity! Good riddance!

File

Many a time you get a piece of information that you don’t need immediately but would like to be able to reference in the future. These items go from your inbox into a file. This file can be physical, a folder structure on your computer system or something completely different.

Calendar

Though people have a tendency to put too many things in their calendar that really don’t need to be done at that exact time, inbox items that do have a specific time window move from there to your calendar.

Waiting for

If you delegate something you expect it to be done after a certain period of time. Though these dependencies are kept out of SCRUM for a good reason they are a part of everyday life. Move these from your inbox to your waiting for list so you can check in with whoever you delegated it to in order to be aware of their status.

Someday maybe

Colleague sent you an adorable youtube frolicking puppy compilation? Maybe you didn’t have time to watch it when it was brought to your attention but why not put it away to watch later? Items that you don’t need to do but would like to get around to eventually should be moved over here.

Projects

There are many things that people have on their to do list that they keep on staring at and get intimidated by for some reason. Often this pertains to items that are of a too high level to pick up straight away. This can range from Bring about world peace to Organise daughter’s birthday party. Both of these tasks really consist of multiple clearly actionable tasks even though one gets the impression the latter is easier to attain in one’s lifetime. Things that should be more clearly defined belong here. Review them and extract actionable tasks from them that move the projects closer to their goal.

Next actions

This is the work horse of the GTD system and is where you actually pick up tasks to do. You place well defined tasks here. If you need to call someone about a case, be sure to save this tasks along with the name of the person, their phone number and case reference to remove any impediments, like having to look up their number or the case reference. This way you make the barrier to get something done as low as possible.

Obstacles

Of course there are a few obstacles to overcome using these two methods side by side as a consultant.

Since GTD encourages you to work on the most important thing at that time, you could be required to make private phone calls during consultancy hours or respond to a mail from a co-worker while getting ready for work. This causes work-time and private time to overlap. The obvious solution would be to track work intervals for each task. However, this takes a little bit of time and discipline so should ideally be automated.

GTD requires you to review at least daily what should be done with stuff in your inbox and what the next most important actions are. This takes time. Is this personal time? Should it be billable? In my opinion working with GTD reduces stress and increases productivity and effectiveness. Thus working with GTD will make you a more valuable employee which is something your employer should invest in.

While both GTD as well as Agile work with definitions of work, the priority of stories in SCRUM is determined by the Product Owner. How can this be incorporated into GTD? Well, even though the Product Owner is in charge of the priorities inside the sprint, he does not have a full overview of everything that needs doing in your life. Therefore you are the one that determines the order in which your tasks need to be performed. Within these tasks only the ones coming from your sprint have a relative order pre-determined by the PO.

Improvements

In my day to day usage of GTD I found that there are a few identifiable improvements.

Due to work requirements I need to maintain multiple calendars. Since some GTD inbox items end up in your calendar this sometimes means having to create multiple items in your calendar, which causes needless overhead. It would be beneficial if this would be supported by software, so that a GTD inbox item can automatically be delegated to one or more calendars.

When tasks are coming from external applications like Jira they have to be kept in sync. It would save time if this could be managed automatically.

Lastly the question of ownership. Who owns a task? The assignee, the author or the company on who’s behalf it needs to be performed? I strongly believe that tasks belong to the author or organisation that the author wrote them for. If tasks have been delegated or synced from external systems they should be revocable by their owner. At the same hand an organisation should not have or control access to tasks a person authored without the author’s permission.

Conclusion

Unfortunately there is currently no software tool that would serve all my needs as outlined here. However the most essential properties of such a tool should be: multi-platform to ensure availability, tagging support to be able to categorise without having to split up the list and owned by you.