This post is the second in a series on Kanban, a lightweight agile approach for organizing work. In our previous post we answered the question, what is Kanban and why do people use it. In this post, we are going to explore how to get started with Kanban.
We have two options to getting started. Option 1 is a quick and easy way to get started with Kanban. Option 2 is a more involved and deliberate approach.
The fastest and simplest way to get started with Kanban is to make sticky notes or cards for all the work that you and your team are doing and put it on a whiteboard. You could also do the same exercise using one of the many online Kanban tools like Jira, Trello, or Leankit.
Organize all that current work on the whiteboard in columns representing the activities that you perform, from initial request all the way through done. You could even keep it super simple and create 3 columns for the work: To Do, In Progress, and Done as shown in the example below.
Boom! You have Kanban!
This very simple visual display of the work of your team by itself might prove very useful to you. Just identifying all the work and putting where everyone can see it can often be enlightening.
But it’s not really Kanban. Why? Well, we haven’t modeled the workflow. And without your workflow, you won’t be able to see bottlenecks and make meaningful improvements.
So at this point, you can alter your board to include columns based on the work being done. Those are the specific steps that you perform to get work done. For an HR team that is using Kanban to track their recruiting efforts, those columns might look something like this:
In the example above, each column on the board reflects an activity that is part of the recruiting process. Candidates are represented by cards and their progress across the board from left to right shows their progress through the recruiting process.
Make your columns show the activities that you are doing as a team to add value to your customers. And this applies whether you serve internal or external customers.
If your team is small and your work is well-understood and straightforward, this simple approach described above may work well for you. For others, you will need something a little more industrial strength to get started with Kanban.
Below is a more industrial-strength approach to get started with Kanban:
Before you start putting your sticky notes on a whiteboard, it may be helpful to come to an agreement on the overall goal for implementing Kanban. What does your team or department want to achieve? Each team or department will usually have one overarching goal. What is it that you hope to achieve by implementing Kanban?
This is sometimes called an optimizing goal for the Kanban area. Every organization has an overriding optimizing goal and while you may aspire to achieve many things with Kanban, there will be one overriding optimizing goal.
Some examples of optimizing goals include:
Here is the thing – the optimizing goal is that which is most important and valuable to the customer, not necessarily to the team. It might be that predictable delivery is important to meet customer needs. Or, improving the quality may be the most important goal.
How do you determine what is most important to your customer? That is beyond the scope of this blog. But you can start by asking your customers, talking to customer service or product management, or discussing it with the senior leaders in your organization.
Let’s assume you understand your optimizing goal. Perhaps it is to deliver faster, which is a common goal among Kanban adoptees. The next step is to identify the workflow.
The workflow is the steps that you take to add value; it represents the activities that you perform.
How exactly do you “identify” the workflow?
In some organizations, the workflow is pretty clear. Consider for example a technical support team that field calls from customers. They get a call, log it as a ticket, assign it, work it to closure, and then close it. It’s that simple.
Not to muddy the water too much, but sometimes it is helpful to think of the work of your team or department in the context of the larger organization process. Value stream mapping may be a useful tool for this analysis.
The value stream is a way of looking at the activities of the organization and how they contribute to customer value.
The value stream is depicted as an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user.
— Wikipedia, Value Stream
At its simplest, the value stream is comprised of all those activities that take place from customer request or need, to delivery or satisfaction of that need.
The value stream in a manufacturing plan is frequently drawn as a “map”. This same approach can be applied to knowledge work as well. The steps in the process for a typical business project might look something like this.
When designing a Kanban system, it is tempting to just limit the thinking to the workflow of one department or one team or even a particular individual.
For example, from the example above for business projects, we could apply Kanban for the team involved in “Design and Develop” or in “Test”. These may be separate groups that get requests for their work from different parts of their organization.
Either of these groups might feel that it would be helpful to use Kanban to organize their work. And it likely will, though without looking more broadly at the entire value stream, it is likely that their efforts to optimize the work of their own department will be a local optimization that doesn’t make much impact.
Local optimization means that even if your team, department or individual activity goes faster, the entire chain of events doesn’t go any faster. Local optimization will only improve the entire system if that local optimization is at the bottleneck.
The biggest inefficiencies in a value stream are the bottlenecks. These are areas where work queues up, sitting idle until someone else can work on it. Every system has a bottleneck or a slowest activity that governs the speed of the entire system.
A value stream map produced as part of value stream analysis will include wait times, queues, process efficiencies, and note touch time. It will make the bottlenecks clear.
Consider the following simple value stream map for a fictional company called Speedy Oil Change. Can you spot the bottleneck?
Yep, that’s right, it’s the wait time for the customer to pick up the vehicle and pay. On average, that step takes 180 minutes or 3 hours out of the total of 6 hours. That long delay of 3 hours is the bottleneck.
Without taking the end-to-end view of the generation of customer value, it is easy to implement a feel-good local optimization that doesn’t improve your workflow or delivery of value.
Coming back to the value stream thinking, it is worth putting the draft of your overall value stream up on a whiteboard or wall of a conference room and really examining it. Consider the role your team or department plays and whether you should consider having a Kanban board that includes the entire value stream.
Posting the value stream up on a whiteboard or wall has an additional benefit of getting input from all the team members who contribute to the process. In fact, if you have a complex workflow, it may be the best way to map out all the individual steps. Even if you are the most knowledgeable person, involving others will help to gain buy-in for the initiative.
Another benefit of mapping out the flow of activities that you perform is that you can look for areas of delay, duplication, unnecessary steps, and other wastes. (Balance this against starting with whatever you do now).
Note that it is not critical that the workflow you define to be “perfect” at the start. Expect it to change and evolve. Don’t worry about troublesome edge cases. For example, if 5% of the time you need to have another department contribute to or review your work, you can probably not include that in your workflow. But if 80% of the time you need a legal review and approval, well that is probably a good step to include in your workflow.
Tips on Identifying Your Workflow:
#1 – Use the actual workflow. This should go without saying but you should identify the workflow that is actually in use, not the out-of-date one that is included in the department standard or training guide. If there are standards that are not being followed, don’t sweat it. Just capture what is happening on the ground today. This will be easier if you involve the broader team or department in the exercise.
#2 – Don’t try to re-engineer (initially). It may be tempting that as you document the existing workflow to jump ahead and eliminate redundancies or non-value-add activities. Resist. The time will come for that. Remember the principle to “start with what you are doing now”. Trust that all the great ideas that you are having now will still be great and obvious once you begin using Kanban.
#3 – Skip Value Stream Mapping? Though we recommend the value stream mapping exercise to aid in viewing the workflow, not all Kanban experts agree on this. Clarke Ching, the self-proclaimed “bottleneck guy”, is an expert on agile methodologies, the theory of constraints, and lean. In a recent podcast on Mastering Business Analysis, Ching said don’t bother taking the time to perform value stream mapping. He said just map out the workflow as best you can. Then focus on the queues and the rework.
#4 – You May Have Multiple Flows If you are serving different types of customers or different kinds of work, you may actually need to have different flows for different types of items. This can and should be modeled on the same board by creating horizontal swim lanes for different work item types.
In the example below from Tony’s Pizza, there is one flow for pizzas and a very different one for salads. Pizzas need to be built to order and then baked, while salads are premade each morning and then simply pulled and tweaked if needed based on the customer request.
Using the workflow that you documented, create your Kanban board. Kanban boards are most frequently written to be read from left to right. Stick with that approach to keep things simple and easy for others to understand.
The columns on the board represent the activities that you and your team or department do to add value. These should derive directly from the activities that you actually perform.
In the Speedy Oil Change example from able, the columns for their Kanban board should represent the specific activities to be performed. This begins with “vehicle drop off” and ends with “customer pick up and pay”. For convenience in Kanban, we also add a column for Done so we know when the transaction is complete.
Tip: Don’t Name Columns for People or Departments. Instead, name it after the activity that is taking place.
Once you have those columns, add sticky notes for all your work items. What are work items? You may want to discuss what constitutes a work item with your team members. That will depend on the work you are doing. Generally speaking, it is something requested by a customer.
In the case of the speedy oil change, the requests are the individual vehicles that need an oil change. In the case of the HR recruiting board, the work item would be the candidate being recruited.
Defining work items could lead to a lot of debate within your team which might be healthy or it may just be a waste of time. If you are struggling with what are your work items, you might find it simpler to just agree to put EVERYTHING up on the wall initially. Remember the first Kanban Principle, start with what you are doing now.
Putting all the work items on your Kanban board will often result in some eye-popping piles of work. There will be hidden work that is revealed, and you will hear a lot of, “I didn’t know you were working on that”, or worse, “I am also working on that!”
You may also find that even though you ask for it, some people will resist being entirely forthcoming about what they are working on. The move to transparency can be threatening and some people like to play things close to the vest. They hoard their Work in Progress and cling to it like a teddy bear. That is probably OK to start though that lack of trust and safety is something to note and address later. When you see it, I would simply encourage everyone to document all the work and put it up on the wall.
Tip: Embellish and personalize your board to your team! Note that I don’t mean that you as “leader” should do this on your own, you and your team should collectively tailor the board to fit your team personality.
Henrik Kniberg in his video, Kanban and Scrum, Making the Best of Both, provides a number of tips for personalizing the board and making it an effective team communication tool. They come at about minute 29 of the video though you can also see them in the visual below from the Crisp Blog:
Source: Kniberg, Henrik Crisp.SE Blog
Work entry may be one of the more political and therefore difficult topics to deal with. Work entry is the way that organizations receive work requests from internal or external customers.
In some organizations, work requests come from anywhere and everywhere. A recent client had a long-standing practice that they called “shoulder tapping” where any employee could approach a coworker with a request. The person receiving the “shoulder tap” was expected to drop whatever they were working on to respond to the requestor. As you can imagine, this was chaotic and unproductive!
The other extreme would be those support groups that require you to log a request in their ticketing system before they will work on anything or even talk to you. By the way, that ticketing system is a Kanban system.
Other teams have responsibility for both existing products in production and for developing new products. For them, work entry needs to address both types of work requests.
My colleague Tom Cagley has written about the 8 causes of work entry problems characterized below:
Work entry is at the heart of many organizational problems. To succeed with Kanban, you will need to establish a clear process for new requests and document rules for handling different types or requests or different classes of service.
Most teams also find it helpful to have a buffer of sorts in their work entry process. This allows them to have a separation between all the things that are requested and the things that are either prioritized, gotten ready or selected for teams to work on. One might be thought of as the “option pool” and the other as in the “ready” queue.
The option pool includes all the ideas, requests, tasks, and business needs that have been requested of the team.
The ready queue represents work that has been prioritized or selected for the team to work on. For some teams, items need to meet a certain standard or “Definition of Ready” in order to make it into the ready queue. For others, it is sufficient that the item is prioritized. Generally speaking, the ready queue is large enough to hold a week or two of work so that the team doesn’t get delayed waiting for decisions on the next item to pull.
This diagram below shows the work in these two different piles.
We will look more at the option pool and ready queue when we discuss the replenishment meeting and calculating metrics.
Many teams perform steps 1-3 and then stop short of setting Work in Progress limits.
Work in Progress limits means that we limit the number of things that are started but not finished. Limiting Work in Progress is the key to managing the flow and getting more work done.
Henrik Kniberg is an agile coach and prolific author on Kanban, Scrum, and Agility. In the 2010 presentation, Kanban and Scrum, Making the Most of Both which we mention above, Kniberg said that without WIP Limits, you just have cards on the wall. Not Kanban.
There are no hard and fast rules about setting WIP limits. Most people find it best to start with an experiment and then adjust from there. Usually limiting the WIP in a column to 1 or 2 items per person working on that column would be a good starting point.
If you see that people are mostly idle but tasks are not, you may have to increase the WIP limits. Conversely, if you find that tasks are mostly idle and people are busy, you may have to decrease the WIP limits and monitor the results.
In the example below, we show WIP limits for the activity steps A through D. WIP limits are not applied to Ready and Done.
Technically, Kanban doesn’t have any roles. But that’s not very helpful, is it? Remember that first Kanban principle, start with whatever you do now.
However, there are two functions that are usually required to support Kanban. The first is a permanent one while the other is more temporary.
Any other roles that are relevant to your process can and should be documented. Remember the third Kanban Principle: Initially, respect current roles, responsibilities, and job titles. If relevant, add Architect, Manager, Project Manager, QA Manager and any other role that is part of the current workflow.
Unlike more prescriptive approaches like Scrum, Kanban doesn’t dictate that you use any meetings. Awesome, no meetings!
That said, most people find it helpful to establish a regular cadence of a few meetings. They often borrow liberally from the Scrum Framework as a starting point. I encourage you to add meetings slowly and deliberately.
Why add meetings slowly? First of all, most organizations already have meetings. Plenty of them. And those meetings aren’t going away anytime soon just because you decided to implement Kanban. If you plow forward and add a bunch of meetings with Scrum labels on top of your existing meetings, you will be sure to pretty much destroy team productivity.
Second, the first Kanban principle is to “Start with what you are doing now” and improve incrementally. Wholesale adoption of Scrum meetings at the start is the opposite of incremental and evolutionary improvement. It is likely to trigger resistance.
Instead, I would recommend that you gradually add meetings as you find them necessary. As a starting point, here are three meetings that you might consider adding early on in your Kanban adoption:
The replenishment meeting should be held often enough so that the team doesn’t run out of work. So, if on average your team is completing 5-6 items per week, a weekly replenishment meeting would need to make 5-6 items ready. A meeting every 2 weeks would need to make 10-12 items ready.
For best results, the daily meeting should be facilitated. This can be from the coach type function I mentioned earlier or the department manager. The facilitation could also rotate amongst the Kanban team so that each person has an opportunity to moderate the discussion.
Retrospectives are critical to success with Kanban. Improving the work of the team should be an ongoing activity and not a once and done. Remember, Kanban is about evolutionary improvement. You will never arrive as a team.
The book Agile Retrospectives by Esther Derby and Diana Larsen is a great starting point for planning retrospectives. The facilitator for the retrospective should be familiar with the five stages of the retrospective and be well-versed in different techniques and exercises that can be used to help teams identify the problems they are facing and develop experiments for improvement.
In Kanban Part 6, we will look at using ScrumBan which is the love child of Scrum and Kanban. In ScrumBan, most people adopt some or all of the remaining Scrum meetings such as:
One of the cool things about Kanban is the potential to crunch numbers. I know it sounds nerdy but hey, we are all scientists running experiments, right? We need that experimentation mindset. We want to collect information and use that to make decisions. You can’t manage what you can’t measure. If you don’t like data or use it to make decisions, you probably won’t find Kanban very interesting.
So, what do you need to measure? Let’s start with progress toward your overarching optimization goal. Are you trying to deliver items faster? Measure it. Are you trying to improve quality or customer satisfaction? Measure that instead.
In addition to your overarching optimization goal, most Kanban teams play close attention to flow. Flow or throughput can be measured in story points over time or simply a count of work items being completed.
Throughput from Klaus Leopold:
To measure the throughput, we count the number of tickets that leave the “Implementing” area (which we understand to be the entire WIP limited activities – see Figure 4.2) within a specific time frame. The measurement is very easy: Using a weekly cycle for instance, at the end of the week you count the number of work items that were completed within that calendar week. The result is then recorded in a chart where the y-axis represents the number of work items and the x-axis is a timeline. If a project backlog is being worked through, you can also record this on the chart and follow if, and to what extent, the backlog is reduced over time (Burn-up Chart).
— Leopold, Klaus. Practical Kanban: From Team Focus to Creating Value (p. 211).
Throughput can be used to forecast completion dates. We can use the number of items in the backlog and the rate of completion to develop a burnup chart. We can augment the burnup with Monte Carlo simulation to get a probability distribution and confidence level.
Answering the question, “When will it be finished?” is not a one-time, set in stone prediction, but rather a continuous approximation.
— Leopold, Klaus. Practical Kanban: From Team Focus to Creating Value (p. 215). LEANability PRESS. Kindle Edition.
Flow, or throughput, is the inverse of cycle time, another key measurement. Cycle time is the average time that a single item takes to go through your board. As cycle time goes down (as we hope), the throughput should go up.
System Stability – See Klaus Leopold in Kanban part 4. The simplest explanation for a stable system is that the inflow of work items matches the outflow. It would be simple to see this in a physical environment because all the cards would pile up and you would run out of room. It is harder to see in an online tool.
There may be other metrics and measures that you find helpful. Some that other Kanban teams have found helpful include:
Tips on Introducing Metrics:
In Kanban Part 4, we feature an interview with Tom Cagley about metrics and measurements for Kanban system.
This follows the 3rd General Kanban Practice, Make Policies Explicit. This simply means, publish the rules of the road.
Some rules that you may need to publish include:
You may find that at the start is it difficult to recall the exact rules you are using. That is OK – write down the ones you remember and then update the list with rules as you discover or recall them.
With the tools in place, begin or continue to work. Hey, this isn’t rocket science so no need to spend too much time preparing. Better to start with Kanban and expect to make adjustments along the way. Use the sticky notes or online tool to move work items to the correct state. Capture metrics. Have fun!
That is it for Kanban Part 2. In Kanban Part 3 we will look deeper at a few topics we only introduced briefly here, including:
If you would like to learn more about Kanban and Scrum, please check out our self-paced online course, Kanban Application and Mastery.