Caveat emptor for this post: I know very little of Kanban, I have not spent any amount of time reading up on it and my understanding is limited to “It’s Agile with limits on Work In Progress”.

However, these very characteristics of Kanban struck a chord with me, as I’ve started to apply GTD (“Getting Things Done”) for personal productivity and organization, and as I read David Allen’s seminal “Getting Things Done” book.

One thing that has always bothered me about Scrum is it’s heavy focus on iteration planning, stories and tasks, rather than Outcomes and “Next Actions”. Personally, I have always tried to ask myself in most situations, professional and private, “What do I want to achieve by doing this? What is my desired outcome?”, followed by “What is my next logical Action given that outcome?”. I’ve found that in Scrum these things can sometimes get lost: user stories are accepted without to much question about their desired outcome, which may or may not cause a re-prioritization or even de-scoping, and as a knock-on effect, during the sprint, there is a marked risk that hours burned down and tasks completed take precedence over the question of whether a task is actually meaningful or not.
To make my point: ever been in a daily scrum where you are met with skepticism when you declare 20 hours worth of tasks are no longer relevant, even though you just freed up 20 hours worth of work for more relevant things to do? I bet most people who have been using Scrum in a project with more than three people have come across that situation.

This is where my very limited understanding of Kanban strikes a chord with me: it seems to me that Kanban is, or at least should be more focused on Outcomes and “Next Action” than other Agile methodologies, which in my mind carries a few major benefits:

  • No unnecessary work: focusing on outcomes and “Next Action” means more critical thinking, and as a consequence less work used up on things that do not drive the project forward.
  • People are not treaded like children: Another of my pet peeves with Scrum is that it tends to treat people like children, critical thinking often stops after the planning session and anything thereafter is expected to be done as if you where a mindless drone. Scrum fanatics would probably blame the implementation, and I’m inclined to agree, but isn’t it funny that most implementations end up with the same mistakes?
  • Limited Work In Progress means higher focus: keeping track of 5 stories, 30ish tasks etc, even on a board is a big drain on attention. Limiting “Work in Progress” to “One” is one of David Allen’s primary “GTD” points. I have not seen any compelling evidence against this point.

Maybe my understanding of Kanban is flawed or lacking, but to me it seems as if there should be a natural overlap between Agile and GTD – Scrum is certainly better than traditional heavy-weight waterfall methodologies, but I still find it lacking in many areas, applying more GTD-like concepts would seem to me like an ideal way to go. It has certainly done wonders to my personal productivity, why shouldn’t it to others, or to a whole organization?