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: