" "

Doing GTD Kanban Style #2

This is the second post of a three-part guest series, Doing GTD Kanban Style by Pascal Venier.  You can read the third post here.In the first post, I have described how David Allen’s Getting Things Done allowed people to gain control of their workflows and at the same time get perspective on their work. This method has proved incredibly valuable to me over the last eight years. It nevertheless remains that making it all work is not always so easy. No matter how well GTD has been working for me, I have always had at the back of my mind that there was something missing in my implementation. For a time, I went through a phase of trying to find a technological solution to this problem. This involved trying more GTD software than I care to count, in search of the proverbial magic bullet. With time, I came to realize that this was pointless and went back to the fundamentals and came to the conclusion that there were two key issues I was struggling with in my implementation of GTD.The first problem I have been confronted is the sheer number of projects and Next Actions that ended up on my lists. This made me very aware that I was confronted with an overload of half-finished projects which were languishing and of tasks which were fighting for my attention. This was at times leaving me to feel overwhelmed and at times even slightly demoralized. The more I was becoming productive, the more I seemed to be faced with  endless projects and tasks. GTD is meant to be the synonymous with “stress free productivity”, but it seemed that if I was not very careful, the stress could can creep back through the the back door. Indeed David Allen does make a distinction between "active projects" and passive ones for which the someday-maybe list provides a "parking lot", but in practice in a busy life, it is difficult to juggle all the obligations one has to face. The switch between what should be active and passive projects is in my view one of the most crucial issues to an effective GTD implementation, but also perhaps one of the hardest to nail down.The whole method is designed with one end in mind: getting things DONE. Yet, it is no little paradox that when there are two crucial frameworks which help getting control and getting perspective, there isn't anything as simple and powerful about the DOING part of GTD. The absence of a straight forward process to help you focus and actually take actions is often felt by GTD-ers.  Paul Eastabrook has very aptly identified this issue, in one of his posts on this blog. As he puts it, "GTD can lead to thrashing, when the total number of options for doing is enormous." Of course we must acknowledge that Next actions are not simply traditional tasks on a task list, but precisely this: the next action to be taken in a given project. Nevertheless, in my experience, a delicate issue remains how to choose which next action will be performed at a given moment. The only guidance provided by the GTD method in this respect is that there are three ways to choose the actions at a given moment. Firstly the context, and what can be done in a given environment. Second, the time available which greatly limits the next actions which can be executed.  Finally, the energy available at a given moment must also be taken into account: there is no point in attempting to undertake demanding tasks when one is very tired. I have often felt that the absence of better way of prioritizing and limiting what could be done at a given time was a problem. A natural tendency seems to be that the smallest and easiest Next actions were undertaken, following the line of easier passage.Such are the two crucial issues I feel I have been confronted with in trying to take my GTD implementation to the next level. Discovering serendipitously Jim Benson and Tonianne DeMaria Barry’s Personal Kanban: Mapping Work | Navigating Life has however given me an opportunity to find an elegant solution to address these issues, by simply adding to the equation this lean pattern which simply involves 2 principles : visualizing and limiting one's Work in Progress (WIP), as I will explain in my next post.

" "