Aug31
In my opinion, the section on the definition of workflow in the Kanban Guide is probably the most important section. If you don’t understand your definition of workflow, many other things don’t work that well in the Kanban Guide as a result. If you don’t get that part, it’ll be difficult to really make progress.
In the Kanban Guide, we talk about having a definition of workflow.
For a start, you need to define the kind of work items that might flow through that system. Some people use stories, for example, features, experiments, etc. → what kind of items might be going through?
You don’t need to have work item types per se. In the Kanban Guide, they’re optional. In non-software, they are more useful in reducing antibodies from people.
People tend to say, well, some things take longer than others, and it’s often a debate not worth having in the early stages because there is actually some merit in non-software where some different work item types do take different lengths of time.
But putting it very simply → you need to define what kind of work goes through the system.
One thing is clear: we do not have fake work items going through the system. In other words, you don’t have items that don’t deliver value. Each item should deliver value, or at least we hope it’ll deliver value; the idea is that it will deliver value.
So as soon as we deliver it, we can confirm whether it did deliver value or not, but we have the potential to release value, whether that’s customer value, end-user value, market value, organizational value, societal value, maybe a reduction of risk or it could be learning.
On the definition of workflow, you need to have at least:
There’s no limit really to how many “STARTED” points and how many “FINISHED” points you can have. Some “STARTED” points can overlap, and some “FINISHED” points can overlap.
You can even have a “STARTED” point at the start of a column and a “FINISHED” point at the end of a column. That is acceptable.
BUT whatever you have as your “STARTED” point and your “FINISHED” point, you will have four measures to go along with that as well.
So there’ll be:
For each “STARTED” point to “FINISHED” point that you have, the four metrics will apply for EACH of those ranges.
So if you’ve got a “STARTED” point here, a “FINISHED” point there, another “STARTED” point here, “FINISHED” point there = The four measures will apply to each.
On the definition of workflow, you also need to show the steps through which the work needs to go through for value to be delivered. So from the “STARTED” point to the “FINISHED” point, are there steps that the work needs to go through? The simplest definition of workflow might have a “STARTED” point with one column and then a “FINISHED” point, and the work just takes as long as it takes to get through that column.
There might be a column as well for where the work goes past where it is actually delivered, and we call that throughput.
Throughput = would be the measure of how many items get past the “FINISHED” point in a particular period of time, be it a day, a week, sprint or etc.
On the definition of workflow, you also need to have explicit policies to demonstrate how work gets through the system.
The Kanban Guide isn’t explicit about this, but you might have, for example:
Sometimes, Kanban system members ask me:
— “Is it okay for this item to move from that column to that column?”
— I say, “What does your policy say?”
— “It actually says we need to do X, Y, and Z”.
— I reply, “Well, have you done X, Y, and Z?”
— They say “no”.
— I say, “It has to stay in the column unless your policy is wrong, of course, you can update your policies periodically. You can do it at any time, in fact.”
BUT we tend to reserve changes of explicit policies for retrospectives. These are informal sessions where we consider how we can work better as Kanban system members.
We can either use:
My preference is to do it based on historical data so that we are using data to inform our decision-making.
When Kanban system members think about taking an item in, they probably will look at rightsizing the item.
Kanban guide doesn’t mandate that, but it would probably be recommended to look at the item and say, “does this feel like it fits within SLE?” If it doesn’t fit within our SLE, then maybe we need to break it down.
One other point that I would want to make clear about the Kanban Guide is that you can have more than one definition of workflow on your Kanban board.
In some cases, that’s really recommended. You might have different types of work going through the system. You might have different customers, etc. There might be some reason why swim lanes wouldn’t be enough to segregate the work, where you actually might need different, almost like different Kanban designs → so you can actually have more than one definition of workflow on a Kanban board.
You might have operational work, you might have investment work going through the board, and it might make sense that there are different columns, for example, for those different definitions of workflow. It might feel a bit too artificial having all that work going through the same definition workflow because, actually the work doesn’t quite fit that workflow.
There are other ways, of course. For example, if you had a whiteboard, you’d put crosses through the columns or the boxes, the cells where they don’t apply for this particular type of work. But on electronic boards, we tend not to have that flexibility, we tend to have an extra definition of workflow for different situations on the same Kanban board.
Another example of that would be flight levels → you might have a:
There are lots of reasons why you might have more than one definition of workflow on the Kanban board, and it’s completely legal to do that. I would say that sometimes it is expected.
Thank you.
By John Coleman
Keywords: Agile, Business Strategy, Change Management