Cards are Conversations

The whole point of having a visual control is to extract information from it quickly.  In this respect, the personal kanban is much like a geographic map.Geographic maps convey more than merely the physical environment, they show us things like political, historic, organizational characteristics - both real and imagined spatial constraints - which give locations their context. Similarly, the personal kanban is a map of  your work. It captures not just the tasks - but the logic, the flow that gives it an actionable framework

This is known as a pattern language.

11:26 AM

A language that helps us describe complex concepts simplisticly, by understanding their contexts.

11:27 AM

As we use the kanban to learn the pattern language of work, we have more kaizen events, more epiphanies, because we are finally understanding its true context.  We learn what value really is, what our capabilities really are.

11:28 AM

threats disappear

This is known as a "pattern language,"  a language that helps us describe complex concepts simplistically, by understanding their contexts. As we use the personal kanban to discern the pattern language of  our work, we encounter more kaizen events - more epiphanies - because we are finally understanding its true context.  We learn what value really is, and what our capabilities really are. Soon, threats disappear.

Modus Cooperandi Personal Kanban

I have intentionally made this personal kanban screenshot illegible because the text does not matter. What matters are the visual cues - the colors, the assignments, and the states.In this kanban, we have three staging columns: a working column, "The Pen" (to hold tasks in a state of workus interruptus), and "Complete."Immediately we see that today our WIP is filled with teal tasks.  Those happen to be for the creation of Gov 2.0 University, one of our projects.  We’re getting ready to launch the web site and conduct some media events, so this particular day was spent focusing on those tasks.We also see that yellow tasks (biz dev with a specific channel partner) make up most of the work in a waiting state.  So now we understand that on our plates for this day, we have a lot of focus on G2U, but that biz dev might rear its head as an activity from The Pen becomes active.So while those yellow tasks might interrupt us, the kanban has mentally prepared us for them.Those yellow tags likewise tell us a story over time. We know their history. Did they appear yesterday or did the come up over time? Are those tasks ones that recur and just never go away?Do we have a deluge of project tasks (e.g. teal) that need to be batched and processed as a day with a single focus? Perhaps we have a deluge of different projects, but all similar task types (e.g. phone calls) that can be batched.What personal kanban reminds us is to look beyond the tasks to the patterns that arise on the board. Work now has a shape. You can begin to think of it in other ways.You can situate it in its context. Work has a geography.With personal kanban you can now see the entire river – where it emanates from, where it reaches, and how it flows – rather than dismiss it simply as a body of water.In an upcoming post, the pattern language of work will be explored.

The Cumulative Flow Diagram - Metrics in Personal Kanban

This post discusses the most powerful - but perhaps most intimidating - technique. In upcoming posts we’ll look as some less intense methods,  so don’t let this post scare you.In kanban for software design, a "cumulative flow diagram" is used to track performance. A big part of the cumulative flow diagram is its ability to visualize how close you are to completion of a large project, and where bottlenecks or waste appears in the process. It’s a very powerful and descriptive tool.Above is the cumulative flow diagram  for the Modus Cooperandi Personal Kanban.  The diagram illustrates how many tasks we have in a given part of our workflow. This is our workflow, so you don’t need to emulate it. The components are as follows:Backlog: Items that have yet to make it into the workflow.Priority 3: Items that are coming up in importance.Priority 2: Items that are important.Priority 1: Items that need to be done soon.Working: Items in the process of being done.The Pen: Items that are waiting for external input.Complete: Items we’ve done today.Archive: Items we’ve completed in the past.On this particular day, we completed 96 things in the past, accomplished  2 that day, sequestered 3 in the pen, and so forth.  Of course, as time goes on, your archive is going to become bigger and bigger.  In a directed project with a finite number of tasks, this is a very important part of the diagram. For personal kanban however, where tasks will build up forever, it shows us how much we’ve done or are capable of doing.Simply from a flow perspective though, we might want to eliminate that part of the diagram.So here, with no archive, we can discern some interesting patterns.First, we see where we complete some serious work. We also notice where we gain a lot more work.  So on days where there is a tremendous dip in the number of tasks, in the above chart (but no dip in the first), we know that we moved a tremendous amount to the archive.We can also see where we build up backlog again.  So, essentially what we have here are two graphs that show us (1) we are completing work and the number of tasks completed is continuing a fairly uniform rise, and (2) we see the actual variations in our work and when we take work on.Since the chart is a time slice taken daily at midnight, the parts of the kanban with a WIP limit should be uniform, and represented by fairly flat bands, with the only variation coming from “The Pen,” “working,” and “done.”  If we have work in the backlog, we should be maintaining a fairly even amount of work in the queue.  The diagram illustrates that we've been working to achieve this, and as we’ve worked more closely, the uniformity is starting to manifest itself.What we want to avoid is having the backlog band grow at an alarming rate. We want work there to feed the queue, but if it gets too overwhelming, we then know we have to start saying no to tasks.The time it takes to move a task from backlog to completion is called “lead time.”  The time it takes to complete a task when you start working on it is  called “cycle time.” “Work time" is how long tasks were on your board, and active.  “Wait time” is how long a task sits idle in a queue, while waiting to be moved.  In a personal kanban, you might move one or even dozens of tasks across your board in a single day, so for you these are the numbers to watch for variation.If at some point you notice your lead time jumps to 20 days, it’s obvious that you have too much backlog. If your cycle time jumps, something is stopping you from starting work.  If your work time jumps, something is stopping you from completing work. If your wait time jumps, something might be stopping you from working at all.So...how do you measure this?  At the end of each day, you can track the information in the cumulative flow diagram by counting the cards in each part of the work flow, and entering them into a spreadsheet.  For the “times” you can write start and end dates on the cards, and calculate from there.Or you can use Agile Zen - which is where these images came from - and leave the tracking up to Nate.

Visualizing the Flow: Polar-State Based Personal Kanban with Habit Trackers

James Mallison shared a bit of insight and I'm passing it along.In a recent post he discussed issues very close to what I call visualization and flow. He begins with a little story about Jerry Seinfeld:

A couple of years ago there was a little story doing the rounds about a bit of productivity advice from none other than Seinfeld.  He said the way to be a better comic was to create better jokes and the way to create better jokes was to write every day, even when you didn’t feel like it. To help achieve this he had a big calendar on his wall and for each day that he did some writing he put a big red cross over that day. After a few days a chain would be created. As the chain gets bigger you’ll not want to break it, so you’ll do what it takes to keep it going.

Personal Kanban and Habit Tracker

What Seinfeld did was build the world’s simplest and most effective kanban. It had two polar states.  Done / Not Done. It had one metric, completeness. Once writing was achieved, task is complete.  Any interruption in flow was immediately visible on his calendar based kanban.Seinfeld didn’t want to “break the chain.”  He didn’t want to interrupt the flow of work.James has taken this concept and built flow worksheets … or state based kanban that he calls a habit tracker.James’ Habit tracker looks like this:In James’ system you create a repetitive task or a “habit” and you simply do it every day. Once it’s done, you can mark it off. For introspection there’s a note field.This would be an excellent variation on my Sequestering Approach to personal kanban. I can very much see habit trackers on the wall next to the kanban.James is looking for comments on the Habit Tracker, so please visit his post and leave feedback.

The Task Based Personal Kanban Approach in Detail

Task Based Personal Kanban Approach

Imagine you have a number of tasks that need completing, and you need to visualize the state of each task. Let’s say that each of these tasks is going to involve several days of information exchange with others. Now let’s suppose that each of these tasks needs to be completed by a certain date, and if you did them in serially with a WIP limit you would spend most of your time waiting for responses. You simply don't have time to fully "complete" each goal and tracking individual subtasks like "bug Bob to send paperwork AGAIN" is a waste of your time.In a traditional kanban, you’d have a problem. Tasks started but not completed would be “blocked,” and you’d need to solve that blockage before you could move the card. Until you moved that task, it was considered WIP.But here we have tasks whose very nature require us to wait for others to acheive completion. These tasks are messy.The task-based personal kanban approach changes the tasks into swim lanes, and allows for a large number of simultaneous tasks.  Your actions should still fall into a WIP limit, but the tasks themselves are unbounded.I’ll retell the story from the original post:In the beginning of June, I was suddenly faced with a large number of items that had to be done in a very short period of time. All of them involved interactions with others. So I built I task-based kanban where each swim lane was a specific task and the adjudication of the tasks was “Assembling,” “Assembled,” “Processing,” “Completed,” and “Notes.”  I knew that my WIP was toast; there was simply no way I could limit WIP when the tasks were so dependent on others.  I need to be able to launch things quickly and then let them resolve naturally.Context required me to rethink the nature of WIP.  WIP needed to be my personal action state, not the completion of the whole task.Each project had objects that needed to be assembled. I allowed myself to have a WIP of three for assembling.  So at any given point in time, I’d have three tasks with stars next to them. I would then gather all the background materials I needed for those things.  When I had all the background information, they would be “assembled”.  As items were assembled, I would start the process to complete the task (calling people, emailing them, etc.) – that put a check in the “processing” column.  I would take notes and place text reminders in the “notes” column until the matter was settled.  Then it would get a “Completed” and I could ceremoniously draw a big line through the whole task.This helped me visualize the full project on a task basis without feeling guilty that I had more than a certain number of tasks active at any given point.  The task based approach helped me track and complete about 35 simultaneous responsibilities during a very stressful time.