Kanban workflow design – commonly recurring mistake

Kanban workflow design – commonly recurring mistake

Coffee making and kanban workflow. What do they have in common? And what can the coffee preparation process teach us about proper kanban workflow and kanban card design? Read more to learn!

When at the café…

Imagine you are at your favorite café and, the same as always, you ask for your morning cappuccino. You have a chance to observe the whole process. First, they take your order. Then the bartender starts with coffee preparation:

  • He puts the beans into the coffee grinder and starts grinding them
  • In the meantime, he takes off the hot cup from the coffee machine and puts it on the tray
  • He moves ground beans to the portafilter and places them in the coffee machine
  • The process of brewing starts
  • The bartender pours the milk into the special cup
  • He starts warming it and making fluffy, milky foam
  • Then he pours the milk into already prepared coffee, with the finishing touch of a lovely flower shape on the top

The cappuccino is ready, you pay and go enjoying your morning coffee.

Sounds easy, doesn’t it?

Coffee Kanban workflow

You could have observed the flow of work of one (work) item through the system. If you decide to model it as a Kanban system:

  • The cappuccino representing the work item will become a Kanban card
  • The activities which the café staff takes will become the steps in the Kanban process (they will be represented by the columns on your board)
  • You can visualize each person working on your order as an avatar
  • What is more, the Kanban card will go through the whole end-to-end workflow from the moment the customer places an order to the moment an order is fulfilled and successfully delivered

And what if you decided to experience a croissant and cappuccino altogether?

The “croissant” is a new work item type, for which we create a new Kanban card, and we take it through the whole Kanban workflow. Although the process of preparing croissants will differ from the “cappuccino” workflow, we are still able to intuitively name all activities, map them on the board, and visualize the work needed to deliver the customer order.

When at work…

Coming into different organizations, either for coaching or training, I had a chance to see many Kanban workflow designs, and I started observing a repeating pattern. Let me show you that on a very specific, real example:

As you can see, the process consists of several activities and buffers:

  • To Do: next thing to pick up
  • Testing Failed: column, where items that didn’t go through the testing process were moved back
  • In Progress: means literally “Development in Progress”
  • Review: peer code review
  • Done: work completed (actually only development work)

Initial Kanban workflow design

However, what we don’t see in this picture are work item types and the way the teams treated them. So, let’s look at these work item types:

  • Story: the effect of a Feature granulation; Features are the elements of the final products requested by the customers
  • Defect: problem with products already released to the customer
  • Analysis Task: reviewing requirements by developers before development started
  • Testing Task: testing development stories
  • Improvements: ideas from the team members for making the process better
  • Maintenance: resolving tech debt

Initial Kanban workflow with work item types

The team visualized each of these work items as a separate swimlane on the Kanban board and tracked on the separate Kanban card.

What are the problems with this Kanban workflow?

There are a couple of problems with this picture, but they all have a root cause in one specific issue: not being able to understand the end-to-end process of delivering an order that the customer requested. Unlike in the coffee preparation process, this Kanban workflow was scattered into pieces and distributed among work item types and process activities.

Let’s now look at those issues one by one:

  • This Kanban board reflects the structure of the teams in the organization (in that sense it is an aggregated team Kanban board): someone is responsible for the development and review, someone else for testing, etc.
  • The Kanban workflow is applicable to one and only work item type, development task, which is not even there!
  • (User) story goes through all steps starting from To do, through Analysis, Development, Testing, Merging, until Done.
  • In addition, Analysis Task and Testing Task are not work item types! They are activities in the process.
  • Separating the processes of analysis and testing as independent work item types resulted in the Kanban workflow artificially starting and ending as the Development process.
  • The frustration of Developers and Testers and the lack of communication were growing – there was no clear visual signal that the development work was ready for testers to pull.
  • Work tends to be stuck and waiting, while no one is aware it is waiting.
  • Users responsible for doing analysis or testing work didn’t understand how to take it through the workflow that did not apply to this type of work.
  • On top of that, Improvement and Maintenance work items had a completely different workflow than the one for the development tasks.

If we used our café analogy, there would be no work item type “coffee” or “croissant”. Instead, we would have work items like grinding coffee or pouring milk. The work would be completely de-fragmented, and the ultimate goal of satisfying the end customer needs lost from people’s sight.

How can we solve it?

Let’s try to fix this design altogether.

  • First, we need to understand which previously identified work item types are actually part of the Kanban workflow. These are the Analysis Task and the Testing Task. We will elevate them as the activities in the process and no longer Kanban cards.
  • Then, we will visualize buffers (queues) to make sure that we have a clear visual signal that the work is ready to pull.
  • Next, we will separate Improvement and Maintenance. They will require a separate Kanban workflow design.
  • Finally, we will add a Waiting Items swimlane to indicate work waiting for action in each state of the Kanban workflow.

Final Kanban workflow design

Although this process is far from being perfect (most of the Upstream part is missing), it takes us closer to better understanding our customers’ purpose and working in unison to achieve it.

Would you like to learn Kanban? Kanban+ is coming soon! 

Learn more about the Kanban Method and the Kanban System.

To start designing you Kanban System and Kanban workflow, check the STATIK materials at KMM Plus!

Start exploring Kanban on KMM+. Create your free account and we will transfer it to Kanban+ after the launch. Stay tuned for the latest news about the Kanban+ launch by subscribing to the KMM+ newsletter.

Back to blog

Leave a comment

Please note, comments need to be approved before they are published.