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.
Personal Kanban for Meaningful & Measurable Performance Evaluations
GTD & Kanban: Series Overview
For a long time I have been a Getting Things Done (GTD) advocate in both my personal and professional life, starting from the basics and working my way up to a full blown implementation in various paper and electronic forms over the years. GTD has been a huge help, yet I have always felt there is something missing in my implementation that helps me better manage prioritisation and focus around work, which led me to explore the use of Kanban as a form of GTD list. Over a series of posts I intend to explore a number of aspects of GTD and how I have applied Kanban to limit my work in progress, adopt a pull based system, and overall, increase the flow of completed actions in my key areas of focus in life and work:
GTD & Kanban: Similarities, Differences & Synergies Between The Two
GTD & Kanban: Managing The Relationship Between Someday/Maybe & Active Projects
GTD & Kanban: Work In Progress Limiting GTD Next Actions Within A Context
GTD & Kanban: Inboxes, Lists, Calendars, Kanbans & Mind Maps Working Together In Harmony
GTD & Kanban: An Example Of It All Coming Together
I am getting value from the changes I have made to how I work, yet still experimenting to improve. Any suggestions or questions, please do comment or email in the interest of moving all of our understanding forward.
Making Waste Explicit
Noticing waste serves no purpose. Understanding it does. Whether we seek to manage waste or attempt to eliminate it entirely, we need to know how much of it exists and what form it takes - what's its volume, its shape, its weight. So we monitor it. We watch it. We learn from how it grows, how it spreads, and what its impacts are.On an idyllic spring day on Bainbridge Island near Seattle, in the crisp fresh air I stood rapt as people heated rice over an open fire. With huge mallets they furiously pounded the grains in a mortar, turning the hot steaming mass into a glutinous paste that is life’s most perfect confection - what the Japanese call "mochi." With apparently heat-resistant hands, they grabbed and worked the steaming paste, transforming it into the fluffiest mochi balls imaginable.This scenario took place at the 2008 Mochi Festival at IslandWood. IslandWood is an educational facility situated in the heart of a forest in the middle of an island in Puget Sound. In their carbon-neutral environment, IslandWood's stunning 255 acre campus embodies an ideal. In this setting, students of all ages can spend a few days or even an entire university term studying sustainability and culture.Me? I was there simply for the mochi.While waiting in line, however, I passed IslandWood's own low-tech waste monitoring system.It's name is "Wade."Wade measures IslandWood's food waste. Diners place their meal remains into one of three buckets for weighing: Non-compostable food (like meat), compostable vegetable, and liquid waste. Wade's goal is simple: leave diners cognizant of the amount of food waste they create, even if it is going to be composted.The added benefit of Wade is the visual control of waste. At all times, the amount of waste from previous meals is visible. This keeps diners mindful of the goal and conscious that their actions impact it.This message translates well for setting up a personal kanban. Whether it is for one person, a family, or an entire group at work, keep in mind that once a type of waste is identified, over time it will continue to need managing and we will continue to need reminding.
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.