The Kanban Pocket Guide: Chapter 4 - Defining and Visualizing a Workflow

Pre-covid19 pandemic definition of Kanban: "We have Post-Its up on a whiteboard".

Post-covid19 pandemic definition of Kanban: "We have a Jira board set up".

I'd love to know where the misconception that Kanban is only about visualizing work came from. Saying that Kanban is only about visualization is like saying Scotland is only about whisky or Nadal is only a clay-court player. If you think that the first practice of Kanban "Define and Visualize a Workflow" means "have a Jira board" then you are sorely mistaken. Hopefully by the end of this chapter I will have convinced you otherwise.

The fundamental purpose of a Kanban board is not just to visualize work, it's to visualize a much broader concept known as a Definition of Workflow (DoW). A DoW is meant to encompass all aspects of how potential value flows through your system to be converted into tangible value once delivered to your customers. Specifically, at a minimum, a DoW must include:
* A definition of the individual units of value that are moving through the workflow. These units of value are referred to as work items (or items)
* A definition for when work items are started and finished within the workflow. Your workflow may have more than one started or finished points depending on the work item
* One or more defined states that the work items flow through from started to finished. Any work items between a started point and a finished point are considered work in progress (WIP)
* A definition of how WIP will be controlled from started to finished
* Explicit policies about how work items can flow through each state from started to finished
* A service level expectation (SLE), which is a forecast of how long it should take a work item to flow from started to finished

A quick note about value: in this book whenever I say "value" I most likely mean "potential value". In most but not all cases the ideal state of your Kanban implementation is that you deliver items to your customers, validate that what you have delivered is valuable, and then make any improvements to your process based on what has or has not been validated. It would be a bit unwieldy for me to replace "value" with "potential value" in every instance, so please understand that unless we are talking about a context where value has been explicitly validated, what we really mean is potential value.

Work Items

Since the whole reason of Kanban is to optimize value delivery, it is reasonable to begin our discussion with how that value is encapsulated in our system.  Most Lean-Agile implementations already have some notion of how value is captured to be worked on.  Tools such as user stories, epics, features, etc. are all meant to make explicit what the notion of an individual unit of value is in our context.  Kanban does not care what tool you use to define value in your system, all Kanban cares about is that you have some way of describing value in discrete units.  These individual units of value that flow through your system are called work items (or items for short).

There is no other requirement about work items in Kanban other than they exist somewhere in your system.  Kanban doesn't care if you use stories, or epics, or features, or fubars.  Kanban doesn't care if they have been defined by a product owner, or ordered in a backlog somewhere, or refined by a team (although you may choose to do any of these things and more if you wish).  From a Kanban perspective, all you need is a way to encapsulate what you think is value into an item that can flow through your process, be delivered to your customer, and be validated by them.

Workflow

Speaking of flow, once items have been defined, they need a set of value-add work steps that they can move through to be turned into something tangible.

Started and Finished

The first step in identifying your workflow is to draw boundaries around it. This means having at least one clearly defined point at which you consider work to have started and having at least one clearly defined point at which you consider work to have finished. So let's say you have a workflow that is Options -> Discovery -> Building -> Validating -> Done. We might define our started point to be when an item moves into the Discovery phase and we might define finished to be when an item moves into the Done stage. Or we might define started as Building and finished as Validating. The right started and finished points are totally dependent on your context and Kanban doesn't care how you set them as long as you do.

It gets a little more complicated than that because it is perfectly allowed in Kanban to have more than one started point and more than one finished point. In the above example maybe we want to measure started from both Discovery and Building and finished from both Validating and Done. Why we might want to do that will depend on what questions you want to answer based on the metrics you collect. For example, maybe we want to know both how long it takes items to get done from when we first start working on them (Discovery to Done) as well as how long our Building step takes (Building to Validating).

It is encouraged that you experiment with different started and finished points in your process to better understand your context. The only thing to remember is that Kanban requires you have one of each defined. The rest of the DoW elements as well as the basic metrics of flow that you will track will be defined in terms of your decision around started/finished (a detailed discussion of flow metrics will be covered in a later chapter).

Workflow States

Once you have your started/finished decided, the next step is to map out the discrete value-added states between those two points. The number of states you choose will be context specific, but you must have at least one between started and finished. Contrary to popular belief, To Do -> Doing -> Done, where started is the Doing state and Done is the finished state, is a perfectly valid workflow in Kanban.

Exactly how to select what states should be in your workflow is way beyond the scope of this book. However, there a few things that you may want to keep in mind.

First, there are some very basic guidelines around how to identify different workflow states (but keep in mind there are no hard and fast rules):
1. Any value-added activity, like "Discovery".
2. When you want to model an explicit hand-off between two people or groups, like separating a "Design" state into "Design" and "Design Review" (assuming the people doing the review are different than the people who did the design).
3. When you want to track metrics for an activity, like in the example above, maybe the review is not done by a separate group but you want to know how long it takes for a review to happen.
4. You generally want to bring more transparency to a particular activity.
It is a typical practice (though not a requirement) that each state you choose for your workflow will become a column on your Kanban board. More on that below.

Second, I'm a big believer in the KISS principle (Keep It Simple, Stupid). Especially when engineers are involved, it becomes very easy to design an overly complicated workflow. There is no rule of thumb around the exact number of states you should have in your workflow, but I'd like you to be skeptical whenever anyone wants to add a state or column. Not only do more states make it harder to understand what is actually going on in a workflow, but worse, more states are usually an excuse to increase Work In Progress (that's a bad thing, by the way).

Third, how you name your columns can either hurt or help collaboration. Generally it is poor form to name states or columns after specific roles in your organization--"Analysis", for example. One reason being that if a column is named after a role, then there may be a tendency for people to silo themselves into a particular part of the workflow and be reluctant to help out in other areas. When it comes to naming columns specifically, what you will quickly realize is that the name itself matters much less than the organization's shared understanding of what activity is being undertaken in that step. One of the best ways to facilitate that understanding is to make policies explicit for each workflow stage. Which brings us to our next DoW element

Explicit Policies

Policies are the rules by which you play your process game. Think about how drastically different the game of baseball would be if each batter were allowed 1 strike instead of 3 or if games finished in 3 innings instead of nine. For you cricket fans out there, think about how different a test match is from a one day international is different from a twenty20 match. What leads to these massive differences and a change in outcomes are our policies or process rules.

Some examples of policies that exist within your process (whether you realize them or not):
1. Rules around how to handle blocked items.
2. The order in which you pull items through your board.
3. What it means for an item to be completed in a particular column.
4. When or if to break an item up into smaller items.
5. Whether items can flow backward or not (by the way, there is no rule in Kanban that items cannot flow backward--but backward flow may not be ideal in many contexts).

Making these policies explicit can go a long way to clearing up confusion around how work should flow within a given system. In fact, if you get these policies right then things you thought may have been important--like column names, or number of columns, or whatever--may become irrelevant.

There is one policy that we have skipped over but that may be the most important of all. For those of you keeping score at home, you'll know that of course I am referring to the policy around how WIP is controlled.

Controlling WIP

What do you call a highway that is operating at 100% capacity? What do you call a network that is operating at 100% capacity? What do you call a Starbucks queue that is operating at over 100% capacity?

We experience problems with flow every single day of our lives and those problems are usually directly attributable to not effectively controlling WIP. Knowledge work is no different. Generally speaking a person, or team, or organization is much more efficient at working on one or two things at a time than working on 100 or 200 things at a time. In other words, if you want to enable flow, at some point you will have to consider controlling WIP.

As with each of these sections, full details around how to control WIP is way beyond the scope of this book, but we do have space for a few key points.

First, Kanban does not care how you control WIP. It only cares that you do. Don't let anyone tell you that Kanban requires every column on your board to have a WIP limit. That is simply not true. You can control WIP however you want. You can have one big limit for the whole board, you can have a limit per person, you can group limits across several columns, and/or you can have a limit on every column. And that is just to name a few examples. Your DoW requires that you have an explicit policy around how WIP is to be controlled, but the implementation of that control is completely up to you.

Second, controlling WIP is just the first step. You also need to decide how you are going to respond when you are over your WIP control or under your WIP control. You are going to need to decide things like "should blocked items count against our WIP limit?".

Third, when starting out, keep in mind that the WIP control you choose is less about a hard and fast rule and more about a trigger for a conversation. Don't get too hung up on whether you are over or under a limit but do pay attention to are those limits causing us to ask the right questions sooner? If your conversations are happening too late or too soon, those are good indications that a WIP limit may need to change.

The Service Level Expectation

You should have read all about SLEs in Chapter 2, so there is nothing more to say here other than SLEs are a first class member of your DoW. If you aren't using SLE's, then you aren't doing Kanban.

The Kanban Board

The collective visual implementation of each element of your DoW is called a Kanban Board. Same song, different verse: how you choose to visualize your DoW is completely up to you. You can use a whiteboard, you can use a virtual tool, you can use a spreadsheet--Kanban doesn't care. You are also only limited by your imagination in terms of how you choose to visualize your DoW. You can show flow from left to right, right to left, top to bottom, bottom to top. There's nothing that even says you have to use columns for states. You could use circles or spirals or whatever.

A very interesting topic for me of late is how do we make Kanban boards more inclusive and accessible for those of us who are visually challenged? I think more "traditional" visualization techniques may need to be challenged or scrapped altogether. But I also think that any solution that brings more than one of our senses to bear on solving a problem would be in keeping with the spirit of Kanban. That sense need not be limited to vision alone.

Conclusion

Once you've designed your workflow and created your board, it is time to use it. Yes, you heard me correctly, you actually need to use the board that you have just created. Review the last chapter for more information on how to do that.

But remember that pesky requirement from the definition of Kanban that we actually have to "optimize" the flow of value through our process? Optimization does not come from standing still. It comes from taking the original system that we have designed and performing experiments to find out how to make it work better. In short, to optimize our process we are going to need to continually improve it...

Remember you can always download a PDF of The Kanban Pocket Guide here: https://prokanban.org/kpg/