WIP can be Imposed

Please don't feel bad if you find you've lost control of your WIP.The two rules of Personal Kanban:1. Visualize Your Work2. Limit WIPWith a little practice, #1 becomes easy...second nature, even.Number 2 is, well, pretty much a bitch to master.It is better stated as a goal.  On a good workday, when things are flowing, we can limit our WIP and feel quite good about that.What gets in the way of being able to totally master our WIP is the expectations of others. When people expect things from us, even if we've conveniently de-prioritized them, they let us know: "Where's that report?" "I thought you were coming over to visit today." "When are you going to mail that book to me?"The telephone, instant messaging, SMS, Twitter, Facebook, e-mail, fax, and just plain old screaming give people ample ways to contribute to the existential overhead that you would just as soon get to later.Often these demands for your attention are highly emotional. People you want to spend more time with but can't. People whom you care about but drive you crazy. People who need legitimate but time-consuming things from you. People who need to work with you but have massively different working styles that will slow you down.This creates a lot of stress.There is little in life we can do about the actions or expectations of others. We talk about expectation management, and can do a fair job of it by being clear about what we can do and when, but people are going make demands of us whether we like it or not.Personal Kanban reacts to this stress by allowing easy re-prioritization of tasks.  You don't think cleaning the garage is all that important.  You wife has a very different opinion.  Her priorities matter, too.This sometimes means that we will need to reprioritize tasks and from time to time these will be tasks already in WIP.Is that good? No.Is it tolerable? Not really.But it is necessary. We simply won't always have the luxury of completion.Again, Personal Kanban is aimed at getting you to visual and understand work's flow - total control is an illusion. Do not be afraid to let reality guide your Personal Kanban.

InfoPak 3 - Personal Kanban Design Patterns: Inspiration to Discover Your Flow

Info Pak3 Personal Kanban Design Patterns

View more

documents

from

Jim Benson

.

Modus Cooperandi is pleased to announce the release of its third Personal Kanban InfoPak. InPersonal Kanban Design Patterns: Inspiration to Discover Your Flowwe present a series of patterns for individuals as well as for small "teams." Among the topics discussed: approaches tailored to specific users (i.e. children and authors) and situations (i.e. non-linear work); ways in which productivity tools such as GTD and Pomodoro extend the value of your Personal Kanban; how "coping mechanisms" such as retrospectives shed light on work patterns that have helped or hindered productivity in the past.For best results and access to links, please download the presentation. As always, please feel free to embed, distribute, and/or comment on this or any of our other InfoPaks.

Undertow and Churn: Workflow isn’t Always Linear

Undertown and Churn

In Personal Kanban, our primary step is to define our workflow. Workflows tend to be linear, and often look like this:

Waiting -->Doing-->Done

or

Outline --> Pre-writing --> Draft --> Edit --> Final Draft

or

Backlog --> Coding --> Testing --> Integration --> Release

Unfortunately, life isn’t always that straightforward.  A few weeks ago on Twitter, I was asked if it is ever acceptable to move a card backwards along a value stream in a Personal Kanban.

My answer?  Absolutely!

If you write some code and turn it over to your testers and the testers hate it, of course it should come back to you for re-coding.

There are a few ways of dealing with work that splashes back, but first let’s define two ways this can happen, further exploring the water metaphor of value stream and workflow.

Undertow: The scenario above (where the code failed testing) generally suggests that something was pulled prematurely and needs to go back to an earlier stage in the value stream for additional work. Undertow is a hidden, submerged current of water flowing contrary to the flow of the stream. It is present in most rivers and in the ocean, and quite often in our work.

Just like undertow in nature, if we ignore it in our workflow it will pull us under and we will drown.  But if we recognize it as a natural part of the environment, we can compensate for it.

Churn: Water sometimes finds a point where it no longer flows linearly, but instead thrashes about.  Even in these violent moments, water can be beautiful, exciting, and self-purifying. In the end of a moment of churn, water resumes its flow.

Innovation often results from moments of such thrashing about – through collaborative processes that may happen while the creators are all together and focused (synchronously) or separately, when the individuals happen have time to touch that piece of work (asynchronously).  To further complicate things, asynchronous work can happen linearly (Bob edits, then Mary, then Yuri...) or at-will (Bob, Mary and Yuri each edit whenever they get time to do the work).

How to Deal With Undertow and Churn

Undertow

Backlog --> Conceptual Design --> Business Analysis --> Production -->

Stakeholder Feedback --> Final Production --> Done

Here we have a generic, linear workflow. It could be for new software, a clothing line, or a consulting offering. Work is pulled from one stage to the next, as it reaches completion in one phase and a worker is available in the next.  Each stage has its own Work in Progress (WIP) limits and work generally flows well with each stage at their limit.

When undertow occurs, work can move backwards through the system.  This can be moving back one step (Production doesn’t feel there is clear enough direction from Business Analysis) or multiple steps (Stakeholder Feedback is that this is the single most stupid idea in the history of ideas, and may send it back to Conceptual Design).

When work moves backwards, it can simply move into the active working column for the unlucky section.

Or, if the Personal Kanban is using “ready” columns, it can move to the ready column of that part of the stream.  If this happens with any frequency, the ready column is far superior to handling this type of event.

If the team rarely encounters undertow, then simply moving  task back and having the affected column momentarily bust its WIP limit is fine.  The discomfort, in fact, will make it patently clear that something has happened that may need to be scrutinized.

Churn Baby Churn

In Personal Kanban, we’re expect to deal with a lot of churn. Knowledge work is often highly iterative.  Making a linear kanban might be just plain crazy and may end up looking something like this:

Outline –> Pre-writing Jim –> Pre-Writing Tonianne –> Pre-Writing Paul –> Discussion –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Draft Jim –> Draft Tonianne –> Draft Paul –> Discussion –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Final Draft Jim –> Final Draft Tonianne –> Final Draft Paul –> Draft Production –> Crowdsourcing –> Discussion –> Release Draft Jim –> Release Draft Tonianne … etc.

Phew.

Add to this that during those big repetitive blocks, work isn’t necessarily done all at once.  Jim, Tonianne, and Paul are accessing a shared document, writing it and editing it over the course of several weeks.  But during those weeks, we want to be able to see who is doing what.  We don’t want to lose work in a black hole called “Churn” and have it turn out that Tonianne really wrote the chapter because Jim and Paul were just plain lazy.

Making the task “Churn” with no clear understanding of responsibility obscures who is actually doing the work, the amount of work it entails, and what - in this context - the definition of "done" is. This sends us back to our pre-Personal Kanban state of knowing there is a task, but not understanding its true nature.

Handoffs don’t work. Genericizing the group task doesn’t work. We need clarity.

To respond to this, I’ve created a few design patterns:

The Churn Chart

The Churn Chart – We created this pattern in response to a project at the World Bank. The Churn Chart lists elements in churn, the people responsible for them, their relative state of completion, and any issues they may be facing. If the group can meet regularly (or if an automated system can be developed) Churn Charts are useful for reporting how close to done the element is in that phase.

Routing Slip Ban

Routing-Slipban – This pattern pictured here is a circle but it can, of course, assume any shape you choose. Routing-Slipban owes its admittedly inelegant name to the now-antiquated paper trail tracker that used to accompany documents as they circulated throughout an office. People would read the material, take appropriate action, pass the envelope to the next person on the list and the process would repeat.

With Routing-Slipban, the attached sticky note includes a short routing slip showing who has and has not touched the task.  When an individual is done with a task, they move it into the backlog of whomever they feel should handle it next.  I would assume this pattern would be best used by small groups where the individual members had a very clear idea of whose attention was appropriate for this task next. (This pushes work and therefore can be dangerous).

Cycleban – Like Routing-Slipban, Cycleban notes on the sticky who has and has not worked on this specific item yet.  Here we take tasks completed by an individual and place them into a shared ready queue where they can be pulled again until the task is complete.  As more people complete them, the tasks become increasingly focused inching closer to completion.

This may be a visual cue that one item may be more important to pull than another.  The more boxes that are checked off, the more a task is prioritized because it can be completed and moved entirely off the board.

To Every Season, Churn, Churn, Churn

Undertow and churn are inherent to both knowledge and individual work.  Since the goal of Personal Kanban is to visualize the true nature of work, we cannot hide from these two forces. Embrace churn! Know your undertow!

Getting "Personal" with Your Kanban

So why call it "personal" if I can use it with my family, in the classroom, or with a team at the office?In life and in business, we create value.  For Personal Kanban, "personal"  relates to  personal value.  Personal Kanban tracks and visualizes items of personal value - tasks, work, and goals.

Industrial-style kanban - as it was conceptualized by Taiichi Ohno and notably implemented at Toyota - tracks industrial objects of value (tasks) as they travel thru a production stream that is often predictable. These objects have primary value to the organization. This model, while flexible, still tracks relatively well-defined objects through a relatively well-defined value stream. Tracking a crank case over its assembly process is markedly different from tracking the workflow of your upcoming move or your daughter's wedding.

In contrast, "Personal Kanban" tracks items of personal value as they travel thru a less predictable path. These objects are often smaller and more varied.

In Personal Kanban, even when tracking the tasks of a team, the object of value - and by extension the resultant epiphany about the nature of that work - is still connected primarily to the individual.

Small teams work better when using a group Personal Kanban because such epiphanies are not only shared, but they can likewise be distributed. A realization that something can be improved does not have to be limited to your individual work.

Photo by Tonianne

WIP and Priorization: Recommended Portions

You've been hiking all morning and the mercury is nearing 100. You're parched. You need water - lots of it.  But even in your thirst, you want that water to be manageable.Which holds more water - a lake or a drinking glass?Which will satisfy your thirst - a fire hose or a drinking fountain?Whether it is water or work, limiting the portion size of something we are consuming actually makes it more useful. We do not lap from the pool or attempt to drink from the firehose's blast.In Lean, we limit work in progress (WIP) not just to slow people down and get them to focus, but to increase throughput. Standard procedure is to drink work from the proverbial firehose. All too often we try to do too much, too fast. And when we can't, and our productivity suffers, we feel we've failed.We have a throughput, our time is a finite resource. We are finite resources.When we limit our WIP, we acknowledge this.Pulling a task from our backlog into our WIP means that we are now using that very finite, very valuable resource. We want to make sure that the task we’ve chosen is of the highest importance.Of course “highest importance” is contextual. Some days it’s work for a given client, other days it’s specific tasks, and still others it’s work that fits in the small time slots you have to work.This isn’t just simple prioritizing of one thing over another. Your brain quickly picks up not only on your limited time but of the trade-offs that limited time generates.  You begin to conduct detailed risk assessments – naturally. I could do this large task for this client, or I could get these 10 little things off my plate – making me more able to focus tomorrow.  Or vice versa.Personal Kanban helps uncover what is really causing the most stress. Those little unfinished tasks, or that big glaring responsibility.  We’re all wired slightly but appreciably differently. Our flow charts similarly have their quirks.