Kanban Part 2 – How to Get Started With Kanban

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.

Option 1: The Quick Way to Get Started with Kanban

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.

Option 2: A More Deliberate Approach to Get Started with Kanban

Below is a more industrial-strength approach to get started with Kanban:

1. Decide On Your Goal
2. Identify Your Workflow
3. Create Your Kanban Board
4. Formalize Your Work Entry Process
5. Set Work In Process Limits
6. Determine Roles
7. Determine Your Cadence for Meetings
8. Establish Meaningful Metric
9. Make the Rules You will Follow Explicit
10. Get (Back) to Work

Step 1 – Decide On Your Goal

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:

1. Reduce Cost
2. Improve Quality
3. Deliver Faster
4. Deliver on Predictable Timelines
5. Improve Security
6. Improve Customer Service

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.

Step 2 – Identify Your 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.

Consider Your Workflow as Part of a Larger Value Stream

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.

Step 3 – Create Your Kanban Board (Visualize the Workflow)

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:

1. Have one style of “card” for work item and another for task. You may find it helpful to create separate tasks for the work items. The work items have a parent-child relationship with the tasks. This is easy to do on a physical board. Some electronic tools support tasks and work items better than others.
2. Show items that are blocked. Blocked items are those that cannot move forward because of an external dependency. This could be waiting for a decision or waiting for another team to complete an action.
3. Show defects from customer acceptance testing. If one of the columns on your board represents customer-testing activities, it may be helpful to show defects in that column. Rather than moving the original item back to the “development” queue, the defect would show up in user testing.
4. Create Avatars. Avatars make it fun and easy to see who is working on what. South Park characters have long been the favorite avatar for Kanban boards but you can pick whatever you like or let your team members pick what they like. I recall a single Kanban board at a client with a Yoda avatar, a Scooby Do and a Ron Swanson.
5. Identify priority on the cards. If it is important, you might want to have the cards reflect the priority of the work item right on the request. The kick-start example below from Crisp includes one or two red stars for priority
6. Write Dates on Work Items. If you are using a physical task board, you may find it helpful to record dates on the cards when card enters or leaves the work in progress. This is not necessary if you are using an online tool.

Step 4 – Formalize the Work Entry Process

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:

1. Difference in goals – Goal conflict is the single reason that explains most work entry problems. The conflict is between the team doing the work, between customers requesting the work.
2. Need outstrips supply – This is a common problem with a few different versions but the bottom line is that there is an imbalance between the asks and the ability to deliver.
3. Pay practices – If the pay of the requestor (not the delivery team) is tied to hitting specific stretch goals, this will result in a short-term focus and the likelihood of interrupting the agreed-upon flow of work.
4. Product vs Project Mindset – Holding a project versus a product perspective can give stakeholders the impression that they have to get everything done at once. Project stakeholders are taught that they only get one bite at the apple. Therefore, everything has to be the top priority, even if unplanned.
5. Urgency/importance dichotomy – Urgency is often defined as the person who yells the loudest while importance is defined as the impact on or the amount of business value delivered. Those you who yell the loudest generally trump those touting value right up until they go out of business.
6. Class of services – Sorting work by priority and then immediately reacting when a higher priority piece appears causes interruption problems. For example, when expedited work interrupts planned work, it causes ripples of stoppage or slowdowns for planned and committed work.
7. Control – Leaders and stakeholders that force teams to take work when it is apparent that they cannot absorb it should be vanquished to one of Dante’s nastier levels of hell. This type of behavior makes work late, reduces quality and causes turnover, or, worse, creates demoralized developers that stay and poison the well.
8. Saying Yes – The single word yes is at the root of most work entry problems. If you find that your work entry process is flooded, you may have to find ways to say no.

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

The option pool includes all the ideas, requests, tasks, and business needs that have been requested of the team.

The Ready Queue

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.

Step 5 – Set Work In Process Limits

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.

Step 6 – Determine Roles

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.

• Queue-Master Function – Recall the political difficulties that work entry can cause. A necessary function in the Kanban world is for someone to make prioritization decisions. Even if the team has a highly-evolved set of prioritization rules, there will nearly always be one person who breaks ties and decides what gets worked on next. I have heard this someone is referred to as the Queue-Master and I like that title because it is very descriptive. Most organizations name this person after the Scrum role of Product Owner and that is OK as well. I’ve also heard of Scrum Masters do it. I would just recommend that you document this person’s role as part of “make policies explicit”. And I would try to avoid using Scrum roles in your Kanban application. The Scrum roles can be confusing enough to new Scrum teams let alone to Kanban where they don’t really apply.
• Coach Function – The second role that is nearly always required is the coach. It can be helpful early on to have someone who understands agile, lean, and especially Kanban. They can help the team get started with training and coaching and support them at the beginning. They can also facilitate the retrospective. This is the rough equivalent of a Scrum Master in Scrum…and in most organizations, this is what they call the role. And that might be OK but just to be clear that Kanban doesn’t have a Scrum Master role. I’ve sometimes heard this referred to as a Kanban Master.

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.

Step 7 – Determine Your Cadence for Meetings

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:

• Replenishment Meeting – In most Kanban boards, there is a deliberate separation from all the new work entry requests to those that are ready to be pulled by the team. The work entry requests should include all the possible new ideas to be worked on. The items that are ready to be pulled by the team is a smaller bucket containing the prioritized items. The replenishment meeting in similar in that way to the sprint planning meeting in Scrum though we don’t use sprints in Kanban so the cadence of this meeting may vary. Generally, team members participate in this meeting along with the Queue-Master person. Customers or requestors may attend to answer questions or to provide input on priorities. The main goals of the replenishment meetings are to:
  • Bring clarity to work items
  • Make decisions on what the team should work on next
  • Clarify work item risks or dependencies
  • Defer work on items

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.

• Daily Meeting – In Scrum, teams have a short daily meeting to synch their efforts and create a plan for the day. Most Kanban teams find this a helpful practice, though I have noticed that some Kanban teams will meet only twice a week instead of daily. The focus of the meeting is on flow and there is no requirement to stick to the 3 questions that have traditionally been used by Scrum teams. Instead, the team will focus on the Kanban board, observe any bottlenecks, slow-moving work items or problem areas, and discuss improvements. This is not the time for a technical drill-down; those should be scheduled separately.

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.

• Retrospective – Kanban is all about continuous improvement. Even though improvements can be introduced at any time, some teams find it helpful to have a regular cadence of retrospectives. This allows the team to step back and take a fresh look at their processes. Some tips for scheduling retrospectives include:
  • Schedule frequently, but not too frequently. Usually, one and two retrospectives a month will be about right.
  • Vary the focus and facilitation techniques to avoid brainless retrospectives that suck the energy from the team and waste their time.
  • Start the retrospective with a review of the current experiments.
  • Use both data and root cause analysis. If you are seeing a lot of variation in your processes, use the 5 Why’s or the Ishikawa diagram approaches to understand and fix root causes.
  • The outcome of the retrospective should include one or more experiments or changes to make with the goal of improvement.
  • Include your stakeholders in the retrospective process. They will often provide feedback on their interactions with the Kanban team, delivery speed and quality, and insights on how to improve. These ideas can spark improvements that the team alone would not have identified.

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:

• Sprint Planning Meeting
• Sprint Review Meeting
• Backlog Refinement

Step 8 – Establish Meaningful Measures

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:

1. Cumulative Flow Diagrams
2. Predictability
3. Timeliness
4. Quality Measures (Rework or Defects)
5. Customer Satisfaction

Tips on Introducing Metrics:

• Collecting Data Has a Cost. The more information you collect, the more time someone will have to spend entering that data. I recommend that you start slow and add incrementally. Don’t collect data that you don’t plan to use.
• Don’t Beat ’em up! Don’t use data to beat up a team. Help teams collect data that is useful to improve their performance but don’t berate them for being honest. Too much attention to data can prove distracting to teams. You just might find that if you harp on throughput going up, that reported throughput does indeed go up. Or if you reward people for finding and fixing defects, then there are a lot of defects reported and fixed.
• Establish Baselines. Where possible, you will want to gather baseline metrics to document the starting point for introducing Kanban. Then you can use each improvement exercise as an experiment to see how you are impacting your measures.

In Kanban Part 4, we feature an interview with Tom Cagley about metrics and measurements for Kanban system.

Step 9 – Make the Rules You Will Follow Explicit

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:

• Definition of Done for each step
• Role restrictions (e.g. only the DBA can move code into production)
• Prioritization rules (work on production defects before new code, or spend 25% of the time on Maintenance and 75% on innovation)
• Drop everything if the Executive Director requests something
• Teams should spend 20% of their availability on technical debt (or on learning)
• WIP Limits

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.

Step 10 – Get to Work (or Get Back to Work)

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:

• Limiting Work in Progress
• Using Special Columns – Blocked, Waiting for Others
• Establishing Lanes of Service

This article was originally published here.

Business & Finance Articles on Business 2 Community

(101)