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.