Merging GTD and Personal Kanban

G

Gardener

0
All right, I'm writing up those thoughts about GTD and (personal) Kanban.

I see areas of needed translation between GTD and Kanban. And when I say "Kanban" I mean "personal Kanban", as opposed to a Kanban board for a team or a single project. The interaction between GTD and team/project Kanban is another topic worth discussing, but not for me today. :)

* Kanban principles

Kanban's two most commonly stated principles are:

- Limit work in progress. (WIP)
- Visualize the workflow. (This is often done with a whiteboard with workflow columns and items of work represented by Post-Its.)

GTD wants you to get everything into the system to get it off your mind, while Kanban wants you to limit WIP. Those two things don't have to be opposed, but they don't obviously mesh, either.

* Work in Progress: Someday/Maybe and Backlog:

Possible structures that can deal with this are GTD's Someday/Maybe and Kanban's Backlog--the places where you can put the stuff you're not actively working on. The way that I use GTD, this actually works almost OK--I like a minimum, a TINY TINY MINIMUM of things in my non-someday-maybe lists. Almost everything else goes in Someday/Maybe, which I could also call Backlog.

But for most people that's just not going to work. Many people have dozens or hundred of projects, and hundreds of actions, in their active lists. When I Google for things like "what's the WIP limit for personal Kanban?" I get numbers like...three.

Yes, three. And by some views, three is a compromise with the philosophy that says that it really should be one. Sure, you can customize your system, and decide on four, or a dozen or twenty, but the point comes where you conflict with "visualize the workflow". You're supposed to be able to VISUALIZE what you're currently working on. Hundreds of items exceed what I see as the limit for visualization.

So for most people, there's no way to map the Kanban WIP limits to any count in the active GTD lists. So what do we do instead?

* Digression: Definitions

Of course, there's an implied assumption that an action in GTD maps to a WIP in Kanban. And that's a huge and often completely invalid assumption. For example, let's say that you're planning a birthday party, and that that party has three subprojects, with a total of seven current Actions. Is that one WIP, or three, or seven?

But even if it's just one, that doesn't really help, because most people are going to have more than three, or five, or seven, or fourteen, projects--most people are going to have more projects than any Kanban board would tolerate without that board shrieking and running away, scattering Post-Its to the winds.

I'm also ignoring the fact that Kanban is structured as a workflow with each phase in the workflow represented by a column on the Kanban board. But the simplest workflow is often phrased as On Deck, Doing, and Done, so I don't see the workflow as a way to deal with the huge disparity in the number of active items that are encouraged in GTD versus Kanban.

However, for the discussion below, I’m going to use the word “Item”. I’m regarding an “item” as a unit of work that has reasonably defined boundaries, that could be completed in a small number of days if you focused on it. This is another issue with merging GTD and Kanban—for me to do that, my GTD projects would need to be sized and structured to be what I see as Kanban WIP “Items”

OK. So we concluded that your lists of active projects likely reflect far more work than you could have on your Kanban board. What else have we got?

* Today List

There's the "Today" list, a concept that isn't prescribed in GTD, but also doesn't seem to be discouraged. You could fill your Kanban board, today, with a number of items that complies with your chosen WIP limit, and then your Kanban backlog is a set of lists organized according to GTD principles.

GTD Today list == Kanban board
GTD lists, including Someday/Maybe == Kanban backlog

That kind of works. Big GTD lists are a compromise on the Kanban side, because I think that Kanban mildly disapproves of too many projects being planned out even in backlog. But you could either tell Kanban to shut up, or reduce the conflict by leaving many projects as one-line thoughts.

So: You have a limited WIP for the day, composed of a small number of “items” visualized on a Kanban board. But what happens at the end of the day? You probably have items that are left in an unfinished state. And if you’re working GTD-style, you’re not necessarily going to work on those same items tomorrow—you’re likely to do some re-selecting to produce tomorrow’s Today list, removing some items and adding other items.

And that’s an issue for Kanban. This--what to do at the end of the day--is one of the places where my understanding of Kanban crashes headlong into my understanding of GTD.

Because GTD is just fine with switching focus tomorrow, and maybe not getting back to today's items for weeks. By contrast, Kanban wants you to finish items before you start new items. The items that you worked on today but didn't entirely finish are still WIP, by Kanban definitions.

(Why? Well, one reason is science that says that unfinished items are handled in a special way by your brain, and that this is a reason to minimize the number of unfinished items that are sloshing around in there. No, I don’t have cites. I’m just quoting some of what I’ve read.)

Kanban wants you to only start items that you’re going to finish soon (although, again, that depends on the definition of an “item”). It doesn’t want you to have a bunch of unfinished tasks in the back of your mind. GTD, on the other hand, wants you to focus on one and only one task in this moment, but it doesn’t care how many unfinished items in your lists.

These two things may be equally valuable ways to accomplish exactly the same goal. One may be better for some people, one for other people. But they still don’t mesh well, if you want to use both GTD and Kanban.

* My compromise:

I can get GTD and Kanban chugging along more or less in sync if I:

- Design my projects to be what I defined above as an “item”. They should be finishable in a few days.
- Create a Today list in the form of a Kanban board and limit the number of items I can have on it.
- Strive to finish, rather than table, whatever is on the Today list before I add anything new to it.

For many people, this would absolutely not work. They like having that buffet of many, many possible tasks to choose from. For me, I think it will work.

* What about contexts?

Now, this model completely ignores the Context question. There is the concept of "swimlanes", where you have effectively a different board (though usually a horizontal slice across the board) for different aspects of your life--a Work swimlane, a Home swimlane, a Volunteering swimlane, for example. And some people set a WIP limit per swimlane, so that you can have three work items and two home items and one volunteering item, let's say.

But those swimlanes sound more like Areas of Focus than they sound like contexts. I see no clear way to implement contexts in Kanban. GTD supports looking at the context you're in and finding work to do. My interpretation of Kanban--and it's my interpretation; I haven't seen anyone say this--is that it wants you to finish items, and if necessary put yourself into the necessary context for finishing. That’s not always possible, so I would say that "contexts" --or, availability of resources--are the reason why Kanban allows you have a WIP limit above one.

* Visualizing the workflow

The above was almost entirely about limiting WIP, except that I touched on the fact that one of the reasons to limit the WIP is that you can visualize only so many items.

But this is another area that could be seen as a GTD-Kanban conflict: GTD wants you to get everything but what you're working on off your mind. Kanban wants you to visualize all of the small set of things that you're working on.

I really don't see this as a big conflict, because I see that they both address a very similar goal: Both of them are ways to get your mind off of the hundreds and hundreds of OTHER things that you could be working on.

* Throughput

One of the advantages of Kanban that the time from starting a task to finishing a task is likely to be shorter if you limit WIP. This seems obvious—if you timeslice more tasks, each one will take longer-but it’s something that I have to keep reminding myself of.

A closely related fact is that the payoff, to the business or yourself, of a task, generally doesn’t start until the task is complete.

Let’s say that you’re a programmer. Let’s simplify the universe and say that every feature that you write will cost a week of time and and a thousand dollars to create. Let’s pretend that switching tasks costs nothing. So you could (Scenario 1) start one feature and deliver it in a week, and repeat that for a new feature every week, for fifty-two weeks. Or you could (Scenario 2) start fifty-two features, timeslice your attention between them for the year, and deliver them all at once at the end of the year. At first glance, it sounds like the two are equivalent.

But that ignores the value, as opposed to the cost, of the feature. If that first feature, once delivered, saves the company a hundred dollars a month in reduced data entry cost, then in Scenario One, that first feature has paid for itself and earned back a hundred dollars by the end of the year. In Scenario Two that feature is still a thousand dollar cost by the end of the year; it hasn’t yet started to pay back.

Of course, that assumes that your work is defined in terms of finishing and delivering things. I see that as the Maker/Manager schedule thing, which I seem to recall caused some offense here or elsewhere, because the implication was taken as Maker being better? But I don’t think it’s about being better or worse. A programmer, say, isn’t more important or better than a therapist. But they’re DIFFERENT. The programmer’s job is heavily defined by deliverables. The core of the therapist’s job isn’t about deliverables. (I think.) The programmer is a Maker. We probably need a better term for the non-Maker side of the equation.

I think that Kanban’s value is substantially increased for jobs that are fairly heavily focused on deliverables.

* Random brain stuff

In one discussion of unfinished items and how your brain reacts to them, there was an interesting observation. The writer pointed out the tendency of overloaded people to nevertheless keep taking on little tasks, favors for other people, little volunteered activities. The proposed explanation was that those people’s brains are craving the experience of FINISHING something, and that their main workload doesn’t provide that experience very often. So they take on little things that they can actually finish, even though those things push their distant ECDs a little further away.

That makes perfect sense to me.

* Next?

There may be other nuances, but I'm typed out.
 
Gardener said:
* Today List

There's the "Today" list, a concept that isn't prescribed in GTD, but also doesn't seem to be discouraged. You could fill your Kanban board, today, with a number of items that complies with your chosen WIP limit, and then your Kanban backlog is a set of lists organized according to GTD principles.

GTD Today list == Kanban board
GTD lists, including Someday/Maybe == Kanban backlog

That kind of works. Big GTD lists are a compromise on the Kanban side, because I think that Kanban mildly disapproves of too many projects being planned out even in backlog. But you could either tell Kanban to shut up, or reduce the conflict by leaving many projects as one-line thoughts.
Click to expand...

I limit my weekly WIP (Work In Progress).

GTD Project & Next Action lists == Weekly WIP
GTD Someday/Maybe == Kanban backlog
 
Gardener, I think you showed a great initiative trying to compare and map the concepts of the two approaches against each other.

Your analysis shows that plenty of parallels exist, which is not surprising, and that differences in emphasis also exist, which is not surprising either.

At the end of the day we all have to live with situations that contain certain opposites, contradictions and differences. For example, we all tend to have very many things all in all that we want to do (sooner or later), but only so much time in the short perspective. Some things are critical, others not so critical. Things tend to belong to different "compartments" of our life. Etc. Etc. This means that any methodology that attempts to deal with this complex life situation needs to contain ways to address and balance these different aspects in a way that makes it easy for us to manage what we need to do.

All methodologies, not only GTD, and also including undocumented, intuitive methods, tend to contain some form of counterpart to the GTD concepts. For example, all use a calendar at least for appointments. All have lists for things that are not meaningful to put a date on, sometimes on different lists depending on priority (next, someday etc). Many have some form of compartmentalization such as roles, areas of focus, projects, contexts and the like. Many make a difference between short-term and long-term planning (horizons). All try to use common sense. All embrace flexibility and the need to adapt practices to your own needs. But since no methodology that I know of can satisfy every wish of every user, they all tend to describe and emphasize some aspects more than others, and that is where the biggest difference lies. Some like David Allen's description best. Some prefer Stephen Covey's or Mark Forster. And there are certain differences among all the similarities. Some pick the cherries from everywhere. Etc.

It is a bit like when you compare diet philosophies (GI, Paleo, LCHF etc). Their rhetoric may sound vastly different, but when you go through their recommended menus you usually find that most of them are quite equivalent in terms of nutritional components (protein, different kinds of fatty acids and vitamins, slow and fast carbohydrates etc).
 
My perspective is that they can help with different aspects of the work.

GTD as a whole helps me keep tabs on everything I have to do, want to do and aspire to be. From the runway to I-can't-remember-how-many-thousand-feet.

Action lists enable opportunistic completion of tasks. They make sure I don't forget things when at the store or on the computer, and help me make use of odd windows of time that appear in my day.

Kanban is a way of focussing work within a particular context. I was going to say "project" but that's not quite right because a project may require several context changes. I can imagine using Kanban while sitting at my desk or working in the garden or getting though my DIY list. For me, Kanban has a good relationship with the action list but not GTD as a whole. An advantage over deleting items form an electronic list is that Kanban let's you see your progress.

I want to add Pomodoro here because it emphasises the narrowing of scope as I go down the list. It's a method of motivating myself to accomplish individual actions. When I have a nasty daunting task then committing to one tomato makes it easier to start.
 
Thanks for all that, Gardener! Some really key insights. I’ve been thinking deeply about software kanban (I’m a developer), but have been a bit skeptical of personal kanban, one huge reason being that personal projects don’t follow a set process, for which kanban was created. As you point out, the purpose of personal kanban is to focus. I’m not sure I agree that you only start things you will finish soon. I don’t think it’s on purpose for personal kanban to increase throughput. Well, with some things, sure. But personal effectiveness must consider the importance of a project, or you could end up with great throughput doing many trivial things. So if a project is big, but important, it would occupy WIP-space for a long time, and that’s OK. You could of course break it down, but that may be a non-value-adding activity, and would be more like “sprint” type situation where you aim to complete a set of things within a time-box. The beauty of kanban is that it can accommodate variation.

If I were to limit WIP, I think I’d simply limit the length of my active projects list, possibly with swim lanes for areas of focus to promote some sort of balance. I think you’re right that mapping to contexts may not be useful, but I did reflect on the fact that areas of focus and context somewhat go together. Also, if you limit the number of projects, rather than actions, it makes more sense to group them in areas.

Now, back to throughput. If one does have specific jobs that are recurring and one would like to increase efficiency, then setting up a kanban process makes sense. Like splitting fire wood or managing bills and invoices. Especially if more than one person is involved, because then the queues and buffers become interesting to tweak for WIP-limits. After all, the queues and the buffers are the things you really want to keep small, not necessarily the time your “flow items” are spent in value-adding activities.
 
Gardener thanks for this post. I've been deep in GTD for years now, and I've only been recently introduced to Kanban (it's starting to be implemented at our office team).

I'm in that "honeymoon" phase with Kanban where the mind is drunk with possibilities for improving my life, but I keep having this gnawing feeling that it scraps years of GTD learning (and muscle memory). Your post perfectly captures the things I'm struggling with (yet cannot find the words to pin them down to reality), thank you for that. Now I'm having a more realistic mindset for trying to integrate the two. Something like this to start

Attached files
 
Gardener thanks for this post. I've been deep in GTD for years now, and I've only been recently introduced to Kanban (it's starting to be implemented at our office team).

I'm in that "honeymoon" phase with Kanban where the mind is drunk with possibilities for improving my life, but I keep having this gnawing feeling that it scraps years of GTD learning (and muscle memory). Your post perfectly captures the things I'm struggling with (yet cannot find the words to pin them down to reality), thank you for that. Now I'm having a more realistic mindset for trying to integrate the two. Something like this to start

Attached files
 
Thank you Gardener! Honestly, I love the playing with different models and theories myself, but I am often a bit reluctant on reading those long posts on it. But I sure am glad I sat down and read this one all the way.

cfoley said:
Kanban is a way of focussing work within a particular context..
Click to expand...

This one really resonated with me also. Even if I know that Kanban is not about grouping similar tasks (and even the contrary), I do think that the feeling when you have a list of Phone calls to make, and then get to finish them one by one and tick them off is quite "Kanban-ish"...
 
I found this by searching for KanBan and GTD ... I have long felt the call of both systems and have been figuring out how to combine them for awhile. I am deeply visual in my processing (kanBan) but need the "reduction to the next step" aspect of GTD. I have been working with KanBan Flow for awhile and I seem to have a decent system set up.

One of the things I like about Kanban Flow is that it has a subtasks feature for every card and that those subtasks can be reordered by drag and drop. I have it set up that each card shows the subtasks and so I use the card as the project and the subtasks as the work units. I always put my "next action" at the top of the list and then move the card on the board according to that next action.

Another aspect of the program is that you have unlimited boards and dashboards. So I have a board for each horizon (columns for each area of focus) and a dashboard for each area of focus which shows me the relevant horizons.

On my main working board, I have an "inbox" column and a column for delegated and deferred as well as waiting for (I do graphic design, so delegated and W/F from clients or vendors are two separate items for me) I then have a column for each major context and one mixed bag column. While I do have a "Today" column, I tend to actually work off of the context columns. I then also have a done column. When I have completed a next action, I check the subtask off and then bring the next item up to the top of the list and move the card to the right column.

I am only putting WIP limits on my high intensity work like the design context to keep from biting off more than I can chew. If I have design work that needs to be worked in, but I have too much on my plate right now, there is another column that I use as a holding pen. I can then tell people where they are on the waiting list

Kanban flow lets you label and color cards to indicated priority or areas of sub-focus (like client work, admin work, marketing, etc) as you wish. You can have multiple dates assigned to move the card into a specific column and attach files.

As an added bonus, it also has a Pomadoro timer feature.

So far, it has worked to keep my To Do list broken down into manageable chunks (each subtask) and yet keep my visual side engaged. Hope that helps someone out there about a way to combine the two.
 
One of my Big time waster was moving between different software because each software fits different methodology. Ofter spending time on GTD , KanBan and Other methodologies for using Task list I concluded as follows:
  • GTD is not the only methodology for managing Tasks and Projects. However , for me GTD is the base as I feel this is the best methodology for Personal Tasks Management.
  • Kanban is more suitable for Office environment where work follows through particular stages and tracking stage is important e.g. Sales Cycle, Product development etc.
  • Each Methodology has its own advantage and disadvantage. My current approach is to use a Custom Methodology with suits my needs and my current environment.
    • WIP limits from Kanban is very important to make sure I don't have too many things going at a time and land up like Jack of all master of none. Instead of starting too many projects (I used to do before I understood this Kanban concept) all go at small pace and it is demoralizing as it seems nothing gets done. Hence Focus on few things , get them done one foe all and start next project.
    • Though Limit of 3 is very nice concept, I could not fit it in personal life as in personal life projects are small and more in number. However when I starting applying some limit, I could work with more focus.
    • I start my day with top 3 things for the day. If I can complete these 3 things , then take up actions from my main Task list.
    • In my current Office environment, the project list is given (by boss, other users etc.). If I have too many projects in WIP I try and park them, but for many projects which I can't park, I start and show some actions / movement , then I change the priority / keep the project on hold, as per new inputs received. Because of office politics / priorities set by others, Project priorities keep changing. However in principle I try to follow the concept of Finishing off project I have start with next.
    • I also prioritize my project by 4 Quadrants. If I have too Many projects in Q2 I will move it to Q3 or Q4 just to keep focus.
In short there is no true one best process. Pick and choose what suites. But if you are a bigger, better stick to one methodology to that your energy is focused on doing and no on developing the Task list system.

Regards
Vinayak
 
I don't see my GTD lists as WIP, but in "raw materials inventory". It is only WIP if one is actually working on it, and GTD helps limit WIP by breaking everything down to single next actions. that way you are really working with a batch size of one. Each context is a different "work center" with it's own "production schedule". Projects are WIP, but there I look at my different roles as different work centers, and try to limit the WIP only at each work center. That is done in my weekly review, where I can determine what I want to focus on, and move things to someday/maybe (raw material, not WIP) as needed. Overall raw inventory levels are pruned quarterly or as needed if my lists start scaring me. Does that make sense?
 
Hi Guys,
Any new views on this combination (GTD+Kanban) to share here...?

background for my question:
I am picking up in 2020 on this thread. It's been a while since 2016 and thought maybe someone would like to share his/her experience.
Been using GTD for years now.
In my office, Agility as a term is getting traction lately and Kanban gets introduced massively.
Which causes that I'm personally having issues integrating both (GTD+Kanban) and getting the best out of both worlds...


Thanks in advance,
Milan
 
I love basic Kanban. On days where I really must get three of four critical tasks done, I create a simple Kanban page in Excel and enter those tasks in the “To Do” column.

I highlight the "Doing" column in yellow, and when I move a task into that column, I switch the text to Bold. The Doing column then acts as a sort of lighthouse, guiding me to where my attention, and thus my day, should be going.

I keep this sheet visible all through the day, often printing it out each time I move a task to Done and a fresh task into Doing.

GTD allows us to make intuitive choices as to what our next action should be. But then the “Whirlwind” of daily distraction fights with us with us to abandon our choice and instead deal immediately with incoming. So, I use Kanban as a focusing tool to help me stick with my intuitive decisions.

I have tried to expand Kanban to include some GTD terminology, such as a “next action” column, but this just diluted its power as focusing tool.
 
@Dave John thanks for the comment. I am doing exactly the same: GTD as a fundamental time management tool and since recently I added just a simple basic Kanban board for 3-4 most important daily tasks, but not in Excel like you. I use MS Planner instead (screenshot below).
Just to make sure that I do record there the main outcomes from reviewing GTD action items and next steps list...
I am bad with looking at many items, get overwhelmed with it and this simple Kanban helps...

1587740887615.png
 
This is an old thread but is the best one I have found on the topic. I recently made the following changes to my GTD system to adapt it to PK and it is working well so far:

Setup: I use text lists (in Evernote) for Projects, Areas, Goals, Agendas, Someday/maybe. These are reminder lists, for review only.
I use a Kanban board for actions. The text lists feed the actions Kanban board during review. Nothing earth shattering here.

The key points:

I define projects at a higher level of abstraction than the strict GTD definition. Mine are a little closer to initiatives, but they still have start and end points. For example, I am a college teacher so a project might be a semester-long course. Most importantly, I have taken projects out of the Kanban workflow. Defining projects more broadly means that they may have a start and end but they don't flow in the Kanban sense.

As with projects I now define actions at a higher level of abstraction than the strict GTD definition. Most non-trivial work takes place as a bundle of related actions that flow from one action to the next, even if those actions are discrete or change context. Changing context shouldn't require updating or even consulting the system. Atomic actions advocated by GTD too often means that the system becomes an interruption in itself. Bundling actions as higher-level tasks means that they flow meaningfully through the Kanban stream with clarity. They also provide more value when doing a Kanban retrospective since fine-grained actions can too easily lose all meaning after the fact.

Most of this was based on the observation that even the smallest Agile task (i.e. "story") corresponded to a GTD project, not action. The Kanban task fell somewhere in between action and project.

As I said, so far so good.
 
Last edited:
I’ve been following a similar path. I’ve always found a tension btw “widget” tasks (ie respond to email; pay bills; do expenses) and “focus” tasks (ie edit draft; research topic; brainstorm x) that may take more than one “session” of work to complete (are they ongoing tasks or projects”?)
I use OmniFocus, and I’ve decided to have contexts for widget tasks that get cleared on a regular basis (email, calls, errands, filing, quick) and a “Kanban” context where more intensive tasks follow the personal kanban principles (limited WIP; visualize all outstanding “intensive” tasks). some say the Kanban should be the “project” but, like you, I’m using a more subjective classification in the moment to decide whether it is a gtd task or a Kanban task.
 
You must log in or register to reply here.
Top