Retrospectives and Kanban Evolution in Action

2009-09-16 personal task board small

Marc Bless has a great post about his personal scrum board evolving into a personal kanban. His personal retrospectives showed him a need to limit WIP, so he created a special section for WIP, while not losing track of his tasks awaiting the actions of others.Marc Says:

After a while I recognized the repeating problem of too many thing in progress. After a short personal retrospective I decided to improve my focus on the "in progress" lane. It seemed obvious to limit the number of things to work on in parallel. I splitted the "in progress" lane in two parts:a) an "on hold / wait" part for all the things that have been started but need external helpb) a "working on" part with focus on all the things in progress. This part now is a Kanban box with a limit of two tasks.

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.

Why Retrospectives?

In both Agile and Lean management there are points called "retrospectives," regular and ritualized moments where a team stops to reflect. Checking processes for only a few minutes lets you re-orient the course of your work. These retrospectives allow a team the opportunity not only to celebrate or bemoan accomplishments or setbacks, but likewise to serve as a constructive way to create and direct their course.  A retrospective shows us that things either went well or they didn’t, understanding that either way, there is always room for plotting the effectiveness of future work.

Over the past few months, I've spoken with many people who've begun to use personal kanban. During the course of this thread, many of them have shared how they've started to deploy Kanban as a collaborative tool, using it to plan, prioritize, and do work both at home and in their place of business. Now we have to go that last step - we have to think about what we’ve done.

Whether it’s on our own, with our families, or with a team, a retrospective is vital in being able to identify, elucidate, and enact positive change. Retrospectives can take place at whatever intervals you are comfortable with, and for whatever period of time. Again, I’m not writing a how-to manual here, these tools should help you or your group manage tasks in a way that works best for you.

We can - and will - discuss a range of options for what a retrospective might look like.  But just like a kanban can reside on a white board, a piece of paper, a computer screen, or even a kitchen appliance, a retrospective is what works at the time.  If you are just finishing a project in the garage or on day 4 of hurricane disaster relief, checking your processes for only a few minutes will let you improve what you're doing

You don’t have to fly to Pluto to gain from small course corrections. You want to always be fine-tuning your workflow and your work management. In upcoming posts, I’ll talk about a variety of retrospective styles – some that are thought exercises and others with statistical rigor. Whatever you prefer, there should be one for you and your team.

Note: When Kanban is working really well, and you have an intimate understanding of your work, then you will achieve what Lean calls a "kaizen state,"  a culture of continuous improvement. At that point, you are constantly doing retrospectives simply because you are so aware of your actions, and a such, a separate retrospective may not be necessary.

NewHorizons2015 is NASA’s Pluto Mission – which requires both course corrections and a whole lot of delayed gratification.