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 – 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-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!