Dion Hinchliffe twittered a little observation today:
The link above leads to the Google Enterprise Social Graph project. Assumably the theory here is that by overlaying a flexible social graph on collaboration-needy applications like to-do lists, many of the issues of to-dos will be solved.
Maybe.
But I'd like to just examine a to-do list as a management tool for a moment.
Through the years I've used a million types of to-do lists. I've done pieces of paper, Microsoft Outlook, Remember the Milk, white boards, mind maps, Bugzilla, Zoho CRM and they all failed to meet my needs.
Why? Because there is a fundamental time-management flaw in the "list" as a management tool. This first struck me a few years ago when Ed Vielmetti told me that he never had more than a dozen things on his to-do list.
Since becoming more proficient in lean principles, it's clear that Ed was trying to reduce his work-in-progress or WIP. Reduction of WIP key to the following elements of a coherent workload:
- Understanding of lead time (how long do you wait to start?)
- Understanding of cycle time (how long do you take to complete?)
- Understanding of bottlenecks (what stalls you out?)
- Understanding of the context of work (what do you do, exactly?)
Corey Ladas and others have written extensively about these things in one way or another, so I'll leave it as just a list.
The issue here is that no to-do "list" has ever rewarded the reduction of WIP or the discovery of these four elements. They allow usually weak tagging and prioritization - but assume that this is the end of the equation.
Packages are just beginning to emerge which allow people or groups to manage their tasks in a way other than in one giant undifferentiated bucket.
Thoughtworks' Mingle (pictured left) begins to do this. Here you see something approximating a virtual kanban. A kanban tracks work in progress in buckets not equal to all the work available, but equal to capacity.
"Don't bite off more than you can chew, son." as my father says.
It gets a lot deeper than this, but it's based on the simple principle that you can only handle so many things at a time and overload quickly has diminishing returns.
You'll also notice that there are divisions of work in progress and color codes for the Mingle items. In the image they relate to a typical coding value stream with priorities. You, however, are unique, and have your own value stream and your own ways of defining work.
We use a white board with post its. We alter its configuration often. Right now it looks like this:
What is happening here?
Column 1 - Unprioritized backlog - no more than 12 items. These are things that need to be done soon, but haven't made it into the immediate cue.
Column 2 - Immediate backlog - 3 items. This should always have 3 items. It's the front burner to-dos.
Work in Process area:
Column 3 - Item - The green tags are large items that need to be done, like "Write Book About Egyptian Reggae Music." These are items can be broken down into two or more tasks.
Column 4 - subitem - These are the tasks that relate to the item. Like, "Fly to Egypt."
Column 5 - WIP - where a task goes if it is actually being done right now. (in our office you are only allowed two active things at a time).
Column 6 - Done - Where tasks (subitems) go when they are done.
Column 7 - Done! - Where the items and their tasks go when the whole item is complete.
Each item in the WIP has a colored paperclip that denotes whether I, David, or Corey is working on that task.
If something is blocked it is covered with a red post-it which details the source of the delay.
Each work item is tagged with its date of generation and its date of completion.
Note: Where the task list enumerated what I needed to do, the kanban elucidates.
Everything on that board before Done would just be in a pile in a to-do list. In ours, we know our backlog, what's coming, what is blocks (and why) and who is doing the work. The two Done columns show us what we've done (a visual atta-boy) and gives us an idea of effort already expended on a given task.
Analyzing the completed work is simply a task of comparing the start and end dates for items and their volume. This tells us our lead time, our capacity and allows us to begin to optimize.
If you look at a kanban for a group (like in the Mingle picture) you see the hand offs through an organization as a task moves from design to development to testing and so forth. Again, Corey and others have written about this at length.
The crux here is that our personal to-dos are often so filled with gunk that focus becomes impossible. Limiting work in process is perhaps the easiest way to deal with this in theory. In practice, it's hard to prioritize and really stick to those priorities. A kanban-like tool that places physical limits on the number of things you can consider for current work enforces prioritization, allows you to focus, and streamlines your personal workflow.
Jim -
I have struggled for a long time with lists of people to call, in part because there's always one more person you might talk to, and in part because every phone I've ever owned has had a built in address book assuming that people stay in categories for a long time and not temporarily.
The hack of the moment is a couple of pieces of masking tape on the back, capable of holding the names of the next dozen people to talk to - easy to refer to, easy to write on with ink, easy to cross off, and not infinite.
Not quite a kanban, but close enough in some way, and having to decide what goes into the short list (and into short term memory) focuses the mind in a way that a huge unprioritized list never will.
Posted by: Edward Vielmetti | 12 April 2008 at 13:27