“Of course, we use Kanban in our company. We have that board on the wall, see?”
Well, Kanban most definitely is not a board on a wall! The literal translation of the word “Kanban” from Japanese would be “sign.” Therefore, one couldn’t have one single Kanban board. Instead, we would have a board full of kanbans.
However, this is not the point of our post. Let us explore what the Kanban Method really is.
How does the Kanban Method work?
A man called David Anderson created a system for work and knowledge management. He took inspiration from Taiichi Ohno‘s Toyota Production System Kanban Method and a walk in the Tokyo Imperial Palace garden. But what is the difference between managing an industrial setting and the knowledge industry?
Once we look at a production line in an industrial setting, it becomes easy to understand how to be lean. If you look at the warehouse, you see how much stock there is.
High on consumables? There is too much slack. Low on them? The procurement team has to purchase more material. Unfinished intermediate products? There is obviously a problem somewhere.
But what happens when you cannot see a product or service? There isn’t a warehouse where you can see shelves and pallets. So, how can one gouge how much stock is available, if there are unfinished items, and what is currently in the pipeline?
Allow me to introduce the Kanban Method through a rather simplified sequence. Adopt it at once!
It is nevertheless essential to highlight that this method applies to knowledge work. Barriers may exist, as there is no silver bullet.
When we talk about using the Kanban Method to manage knowledge work, we mean it broadly: I have used it both for managing workflows of big players in the banking industry and… my daughter’s learning process!
The first Kanban step is to “remove” the knowledge work from one’s mind and make it explicit.
Example: You are part of a Marketing Team, and the team must create a new campaign. Each person in the team has an idea about what to do, but everyone’s individual concepts may vary.
This is why putting all “To-Do” items on a board is a clever idea. For this board, go ahead and use anything you can, from post-its to management software acquired by companies (check out the different names for the value items that each tool uses). To put it shortly, transfer everything that is in the team’s mind to the “kanbans,” the “signs” on the board.
Post-its are a great way to disclose and communicate knowledge work items.
Ps.: The team may use the User Story format to describe the work, but it is not mandatory.
Visualize your workflow
Visualizing your workflow could be your first step. What is your value chain flow? It all starts with an idea. Having the idea as your starting point, what are the SHARED steps that the items MUST go through in order to become a product/service?
Let’s go back to our Marketing Team example. Assume that, for this team, the steps will be the following:
How to find out the ideal workflow for your team? Learn more about Statik, the main approach for those willing to adopt Kanban!
Note that the step’s name is related to the build-up of the work items. It is NOT linked to the expertise of those integrating the team. Doing this avoids backflush in your system (we’ll further discuss backflush below, keep on reading).
Designing the “perfect” flow
ATTENTION: Design the flow that the team CURRENTLY has, and not the one that the team WOULD LIKE to have! Kanban is an evolutionary method.
We always start with what we have at the moment. Of course, we will identify points to improve, leverage such improvements, gather results, and enhance work models — however, one step at a time.
One of the most common errors that companies make when they start using the Kanban Method is to design flows that do not match the current teams’ realities.
Such an approach generates a lack of engagement among stakeholders, and the method becomes inefficient. It’s like having a Ferrari up on the wall, while the team is actually an old car. It could be a perfectly kept old car, but it is NOT a Ferrari, right?
Everyone will just look at the “Ferrari” board and say, “Well, it looks amazing, pity we can’t be that fast.”
The “perfect” board won’t be a mirror to the team, and engagement will never happen. The board will just become a useless thing up on the wall.
It is essential to highlight the occasions in which a step of your flow will be an external dependency.
Well, what is an external dependency? It’s when your team does not have the knowledge, capacity, or authority to carry out one or more steps of the value chain.
Measuring the impact of external dependencies is very important. Whenever there are external dependencies, things get slower. If such dependencies’ priorities are not in line with your team’s priorities, the process slows down even further.
Also, let us say that your team has many dependencies, each one prioritized differently. Quantity, here, makes the problem even more prominent.
Make it clear for the team and the stakeholders what the team’s commitment point is. Another thing that must be clear is the step of the flow that belongs to the team. The team must commit to building an item of the flow. Before the commitment point comes, any items may be prioritized, sliced, or discarded. As of the commitment point, the team must start working.
This point is critical for creating a network of protection for the team, as it avoids the following complaint, “Oh, the priority keeps changing!” In this way, stakeholders will not create fake expectations just because they already stated what they needed. If we are before the commitment point, there is no expectation regarding delivery.
Going back to the Marketing Team example that we have been using, the “ideas” step will have a brainstorming symbol (a downpour of ideas, as Tadeu likes to name it) precisely because there is no team commitment at that point.
When the item moves to the Prioritization step (the Start sign), the commitment begins, and, therefore, the team can’t make any changes to the item. The client will then be expecting to receive the item within the Customer Lead Time.
Delivery Point to the Customer
Misinterpretations often happen regarding the Delivery Point, especially in big companies. When operations are large, teams do not cover processes end-to-end. For them, the work is “done” once they handle the item to the next team.
This mentality causes significant problems, as we lose focus on the actual result and end up with teams that only care about solving their share of things.
When depicting an industrial warehouse, we mentioned a stock of unfinished products, remember? Teams that are not end-to-end usually generate loads of “unfinished products” stock. This may occur at a micro-level setting (one team) or a macro-level context (the whole organization). It is important to be at least aware of the size of the problem.
Going back to our Marketing Team Example, the Delivery Point corresponds to the “Delivered” step. A checkered flag represents it. Delivery means putting the item in the hand of the client for them to use.
Place the items where they, in fact, are
Once you create the flow, place the items (the kanbans) where they actually belong. Avoid thinking, “It is nearly ready. Let me place it somewhere along the middle.” There is no point in doing so, and the reason is quite simple:
“There is no such thing.”
Either the item is at one step or at another step. There is no such thing as “half-ready” or “90% ready”. We will soon discuss transition agreements.
What is being done, and what is at a halt?
How long does it take to carry out an activity? When people try to answer this question, they often overlook a crucial element: How long will the task stands still, waiting to be started?
Let us say that it takes one hour to execute that task. However, considering the priorities list we have today, it won’t be started before five days. So, its deadline should be five days and one hour.
If you calculate the time during which items will remain in the waiting line before being started, it is easy to notice that waiting takes much longer than the execution. Thus, consider “waiting time” and “execution time” separately.
Waiting Columns / Action Columns. Let us go back to our marketing team example and look at the wording of columns here.
Ideas (a noun), Prioritization (“prioritization in progress” and “prioritized”), Definition (“definition in progress” and “defined”), Building (“building in progress” and “built”), Approval (“approval in progress” and “approved”), Disclosing (“Disclosing in progress” and “disclosed”) Follow-up (“Follow-up in progress”), and Delivered.
Who is doing what?
Pick the items that are currently in progress among those in the waiting line. While doing so, it is vital to highlight who is doing what. Using avatars is rather interesting for such depictions.
Ideally, people should choose or create their own avatars. We want everyone to feel comfortable with their depiction in the “virtual” realm.
Common questions regarding the use of avatars
How many avatars can I own?
You can own one avatar and one only. Unless you can simultaneously be in two places, there is no point in having more than one avatar.
If I happen to be working in two teams, can I then have two avatars?
No, you can’t. You are still one single person. Take your avatar and move it to the team for which you are currently working at the time. Your other team will then clearly know that you are not available for them right now.
Besides me, can anyone change my avatar?
Can I use an avatar in steps awaiting action?
No, you can’t. Why not? Such usage usually indicates that we want to keep track of who did what and hold individuals responsible for poor work. Looking at things from this perspective is unproductive since any corrections/improvements will be just local instead of systemic.
Besides, team members start feeling like “heroes” and “villains” — the heroes trying to defend their work items against the villains. Ideally, a team should foster a feeling of collective property for the sake of reaching for good results.
Set a limit to work in progress
Every work must be limited. A lot has changed lately, but days are still limited to 24 hours, which we must split between work, study, rest, family time, entertainment, etc. It is useless to push more work into the pipeline than what a team can indeed handle.
That is why setting limits is critical. Once that column reaches its limit of “to do” items, no one can pull new items into that step.
Why should I set a limit to work in progress?
Because it leverages many benefits for the team. Here is a list of the most relevant among such benefits:
Avoid the increase of unfinished work
Having too much work in progress means that your team has too much stock of unfinished products. What is the point of building 1,000 units of a product if you can only deliver 100 units per year? Nine hundred items will go to waste. Now, multiply that by the total of hours invested in each step before “Building.”
Let’s agree that no one will be happy with that result, right? Honestly, when Kanban first appeared back in Taiichi Ohno‘s reality (1978), its goal was to avoid precisely that from happening.
Limit the entry of items in the flow
Having too many initiatives and little closing is really bad for a team. Once you set a limit to “work in progress,” the team declares that the flow input is of “X” items at a time.
Creating a sustainable pace for the team is vital. Once you set a limit for all the columns in the flow, you define the team’s capacity. It is pointless to shove in more work than we are capable of absorbing.
If an emergency arises and the team must tackle it, we will create a new item, prioritize it accordingly, and handle it. However, given the limits set forth, the team will have to pause the progress of a lower-priority item.
Let us say that a team member is an expert in prioritization, and a particular step has already reached its limit. The prioritization expert cannot pull a new item because the later steps are blocking the flow. What is the solution?
- Ignoring the limit and pulling the new item.
- Going through the “done” items and polishing them.
- Going to the beach, since your job is done, anyway.
- Taking two steps back, considering the entire workflow from right to left, and assisting the team who is “jamming” the flow.
If you chose option number 4, congratulations! After all, “Stop starting and start to finish”! The prioritization expert may:
- undertake part of the approval work, which, in our mock “Marketing Team” case, is the step in which lies the bottleneck.
- Working together with evaluators to understand their processes and improving on the next items will allow the stakeholders to arrive at this step feeling and acting more efficiently.
- Seek the necessary clearances to perform the evaluator’s work
- Look into how it would be possible to automatize evaluation even further.
- If unable to do so, protect the bottleneck from external interference. The involved stakeholders will be able to work better and restore movement to the flow.
When reaching a step’s limit, Kanban invites us to take two steps back and assess where we could work more strategically in order to restore movement within the flow.
How to set the “work in progress” limit to each step of the flow?
There is no formula for that. The limit for each step and the entire team capacity will depend on practical experience. If possible, limit all steps to one item.
Such behavior would ensure that an item that enters the flow will become a priority for all team members. However, this is nearly impossible. A team always has different specialties, availabilities, and seniority levels across its members.
The limit has to be set at a low level so that we can always reach it and benefit from the advantages listed above. However, it can’t be so low that we keep reaching it over and over. The workflow’s bottleneck sets the limit for the upcoming steps.
Make policies explicit
We’ve come a long way! We already visualized the workflow and limited the work in progress. However, how do we know if an item is ready to move to the next step? Keep in mind that what I call “ready” may be incomplete for you.
How to avoid that? By making all policies clear. That means that a team will always have to follow the explicit rules if it moves an item from step X to step Y. Team members are the ones who define all rules and policies. The team should take into account its external dependencies while doing so.
If policies and rules are explicit and something goes wrong, can the item go back to the previous step (backflush)?
Within the Kanban methodology, we should avoid backflush at all costs. Earlier, we talked about designing the value chain by naming the steps according to the sequence needed to generate a product or service. This is extremely important.
But, instead of doing so, people tend to name the steps according to the team’s specialties. For example, it would be something like, “Product Owner’s Backlog, Marketing, Digital Media, Management, Rollout, Business Intelligence, and Delivered.”
Take a look at this board, whose steps correspond to the team’s specialties.
Note that such a board encourages the creation of knowledge silos. In real life, this means that I pass the baton to the next group of professionals once I’m done with my work.
Now, Digital Media is working with an item, and a problem comes up. It is something that only the Advertisement Committee can handle. Well, one has to take this item and place it with the Advertisement Committee, right? Right then and there, backflush happened within the Kanban System.
What problems are caused by backflush?
- Should backflush respect “work-in-progress” limits?
- Should the backflushed item go through the Marketing expert again?
- Can I move the Digital Media expert to the Advertisement Committee?
- What is the actual state of the item within my flow? Is it with the Advertisement Committee or with Digital Media? How can it be with Advertisement Committee after having been through Marketing?
If possible, avoid backflush at all costs. Picture a car factory. Once a car gets to the end of the assembly line, someone notices that the door’s rubber sealing is damaged. The car doesn’t get backflushed and disassembled. A professional will go to the car and fix the rubber seal.
Now, apply that idea to knowledge work’s items. In case a problem arises, people (represented by their avatars) should walk to the item instead of moving the item back to someone.
That is why naming the steps according to expertise or specialties exposes us to the temptation of backflushing items. And that is no less than a sin.
The Kanban Method is pragmatic. Thus, it is vital to measure its efficiency. And there is a wide array of relevant metrics. Find below a concise list highlighting some of the most relevant metrics. But, bear in mind that this list is by no means complete, as there are many other useful metrics.
Customer Lead Time
At Kanban, it means the time each item takes from the team’s point of commitment to building it until it reaches the client’s hands. It does not matter whether there are external dependencies or not.
Kanban System Time
It is also known as Local Lead Time or Cycle Time — its most famous name. This metric calculates the time for each of the flow steps. Cycle Time is key to understanding our system’s bottlenecks and measuring our external dependencies’ impact. Usually, improving the Cycle Time externally to the bottleneck will only provide the team with a minor gain. Improving Cycle Time within the bottleneck ensures systemic gains.
Work In Progress (WIP)
Measuring Work In Progress will help the team reach a good, sustainable pace. Picking up on that example of the Marketing Team, it has an ongoing “work quantity” of 14. The math goes like this: 3 to prioritization, 1 to Definition, 3 in Building, 2 to Approval, 2 to Disclosing, and 3 to Follow-up. However, do not mistake “WIP” for “WIP Limitation” in each step.
If we limit the first steps of the flow, we reduce input. But the throughput will be the metric that dictates how items leave our flow. It is expressed by how many items are delivered in a given period (day, week, fortnight, month, etc.)
In summary, there are many important metrics for flow management.
Kaizen and Continued Improvement
We visualized, limited, combined, and measured. Now comes the most critical part: Kaizen. It means the evolutionary, continued improvement of the workflow. Think about the following question:
“What is the most important action to undertake so that our flow obtains real gain?”
We are not supposed to change the entire flow. We are looking for a leverage point that will provide significant improvement. Perform your identified action and keep on measuring to assess whether it was efficient or not.
Put short; Kanban is a pragmatic method for managing flows of knowledge work. Its main characteristics are:
- Workflow mapping and management
- Continued flow
- Limiting work in progress
- Highly based on metrics
- Kaizen as the ground for flow evolution and improvement.
Kanban allows your team to improve on its ways of working continuously. This method increases efficiency and efficacy, allows forecasting, and lowers risks in building products and services.
Learning more about Kanban: next steps
Would you like to know more about Kanban?
- Read David Anderson’s Blue Book – Kanban: Successful Evolutionary Change for Your Technology Business
- Read the article in our K21 blog: The world´s biggest Kanban conference trends – who to follow, what to read?