Kanban eliminates the sprints or iterations of Scrum and Scrumban processes. Move to Kanban if:

• You want to release more frequently
• Customers demand changes that don't fall into a fixed release schedule
• You want to organize distributed teams without meetings
• Iterations are taking longer and longer to test and stabilize. This is a sign that you need to test and release smaller batches and move toward continuous delivery
• You are using continuous delivery to test and release code

Kanban is the simplest type of task management, but it requires the most sophisticated code management.

"Kanban" means "cardwall" in Japanese. Team members "pull" tasks to work on and put "cards" representing the tasks on a physical or online "cardwall," where everyone can see their status and progress. Team members work until the tasks are done, and only then pull new ones. This is a continuous flow process without any stopping points for big releases.

When you design a Kanban process, you set up a cardwall with status columns. Each column represents a step in your task lifecycle or workflow. For example, a cardwall might have columns for "New," "Design," "Program," "Test," "Deploy" and "Done."

WIP (Work in Progress)

There are always tasks on the cardwall, which are called "Work In Progress" or WIP. You want to make sure that, if a task is on the cardwall, someone is working on it. Therefore WIP is always limited, typically to one or two tasks per team member.

Limiting WIP is THE KEY TOOL that Kanban and Lean use to bring order out of chaos.

Kaizen, retrospective or happiness survey

You will journey with Kaizen - continuous improvement. Do retrospectives and other analysis to find ways to improve. There is no specific time after a release to hold a retrospective and discuss process improvements. Or, you can cover all of your team´s improvement ideas in one place with a "Happiness Survey." Every one, two or four weeks ask your team "what feels best," "what feels worst," and "what would increase your happiness?" The responses will yield a lot of actionable advice.

Keep the process flowing by looking for:

• Bottlenecks. These are cardwall status columns where tasks are piling up. For example, you may see a lot of tasks that are piled up in the testing column. In Kanban terms, this is exceeding the Work In Progress limit for that column. When you see this, move your effort from the step before the pileup downstream to the step where the pileup occurred. For example, If you have too many tasks in the test column, you ask programmers to stop adding more and move downstream to finish the tests. I call this "unblocking from the end."
• Stuck tasks (or "stuck tickets" in Assembla terms) - These are tasks that have not moved forward recently. If a task has not moved to the next step in several days it is dying inventory, and it shows that you have a problem to fix.

Kanban for any business process

Kanban is a general-purpose technique for organizing work. You can take almost any business process and show it on a Kanban board. The basic formula is to find "sources of demand" (the people that give you tasks). They put cards on the board in a backlog area. Then you map the process to show the stages that each task goes through.

This has a number of benefits. Your work is visible, so you spend less time explaining what you are working on. Each "source of demand" can see where their task fits in the queue. You can work with less stress by limiting "work in progress." You can deliver high priority tasks faster. You can improve the work by measuring cycle time and seeing bottlenecks.

You can make individual Kanban boards to show the workload of individuals. This is useful for "shared resources," such as designers working on multiple projects where it is important to know if they are overloaded or if they have available capacity.

You can use Kanban for almost any time scale. A system operations team could use it to track things that need to be done today. A marketer could use it for campaigns that take a month to execute. A strategic planning group could use it for a 3-month planning and budgeting process.

In contrast, Scrum is only appropriate for specialized situations. It's a team methodology that works if you have teams of 5 to 10 people. It is a batch process that only works if you can wait one to eight weeks for a deliverable, and if you finish deliverables in one to eight weeks. Scrum fits programming teams, but not operations, marketing, planning or other non-development functions. Only use Scrum if your team is 5-10 people and your delivery time is between one and eight weeks. Otherwise, use Kanban.

Lean Theory

You can improve your results by using lean manufacturing ideas pioneered in the automobile industry. These methods have proven successful in eliminating waste and costs, improving manufacturing quality, and allowing companies to bring to market complex new products (such as new automobile models) in half the time or less compared to older techniques.

Principle of pull

A lean process is organized by "the Principle of Pull." A worker or team pulls a task when there is capacity to finish it. This saves management time, since there is no complex process to assign tasks. However, it is often necessary to remind eager team members that they should only pull one or two tasks at a time.

The Principle of Pull also applies to building releases. Changes are pulled into releases when they are ready. This reduces stress and improves quality, because there is less pressure to rush features into production to meet a fixed release schedule. It also makes it easier to enforce coding standards and test coverage, since you can refuse to pull code that doesn´t meet those standards.

Reduce inventory and work in progress

"Lean" manufacturing methods focus on reducing the inventory of physical parts that are waiting to be assembled into a finished product. "Lean" software methodologies focus on reducing work in progress, which are the tasks that have been started but not completed. Reducing WIP has a number of advantages:

• Each task gets finished faster, since the team is working on fewer tasks. Tasks are more likely to be completely finished, since each task must be completely finished before starting a new task. If you find that you are waiting a long time for stories to be finished and released, you need to reduce your work in progress.
• Less time and money tied up in features that are not released and not producing value.
• Less chance of software becoming obsolete or outdated before delivery
• Greater visibility into problems in the process. Any place where active tasks are waiting becomes obvious.

Measurement

Measure so that you can improve! Kanban enthusiasts typically focus on metrics related to speed. Speed is good.

Lead time - The time that it takes to move a task from first pull to finished. You can look at averages, and also at slow tasks that stick at the 90th percentile. You can see these on your cumulative flow diagram. You want lead time to be as short as possible. If it starts to lengthen, reduce your work in progress.

You might find that delivery is quite fast after you pull tasks, but some tasks spend a lot of time waiting in the backlog or being "groomed" with appropriate information. This is because there are really two kinds of lead time. Delivery lead time is the interval between starting work on a task and completing it. End-to-end lead time is the interval between accepting a task into the backlog or queue and completing it. If your users or customers perceive your responsiveness as related to end-to-end lead time, then you need to monitor that form of lead time and address the factors causing it to lengthen.

High priority lead time - It feels great and relieves a lot of stress if you can deliver high priority items quickly.

Cycle time - You can measure the amount of time that tasks spend in a specific status column. This is the cycle time for that column. Typically, most stages are fast, and a few of them are slow. That's gives you specific opportunities for improvement. If you find that a stage is slow, you will want to set a "WIP limit" for that stage - a maximum number of tasks that can pile up there. That motivates you to fix the problem.

Throughput or Velocity- How much can you do in a month? You can take simple averages, or you can do increasingly complex Monte Carlo simulations to give you an idea for how much you can do next month.

Quality - In software development, a typical indicator of a quality problem is a ticket that goes backwards in status. For example, tickets can go backwards from "Test" to "In Progress" if they fail a test. You want to measure the frequency of these events and see if you can reduce them.

One-piece flow

In manufacturing, workers are more productive if, once they start on a piece they can finish it without waiting for additional parts to arrive or being pulled off to work on other pieces. In software terms, developers will be more productive if they can finish one story without waiting for a lot of other stories to be completed or being asked to switch between several tasks.

This simple principle turns out to have a variety of implications:

• Tasks get finished faster. This speeds up the completion of high priority changes and the delivery of value to customers.
• Processes are more predictable. Delivery times are based on the work required for each task, not on the number and priority of tasks assigned to each developer. This makes scheduling easier and reduces management work. You many even be able to eliminate status reporting on stories, because you know that once started they will come out quickly.
• Bottlenecks are visible. For example, if tasks are piling up in "test" status, you can see it on your Kanban cardwall and take action by moving developers from programming to testing. This gets stuck features released faster and rebalances your capacity at the same time. A continuous flow processes is only as fast as its slowest point, so removing bottlenecks optimizes processes and increases overall output and productivity.
• Developers are more productive because they have less "switching" time. Switching among tasks and bug fixes requires both physical setup time to prepare test environments and mental setup time to remember details and issues. Developers who focus on one task at a time are much more productive and make fewer mistakes.
• Deliverables take as long as they need, rather than being shoehorned into fixed release cycles. A high priority bug fix should go through in a few hours. A big new feature or a major refactoring might take weeks. Allowing the right amount of time for each task reduces stress on developers and leads to more realistic schedules.
• One-piece flow allows the process to be non-blocking. If one developer is stuck and can´t release, the other developers can continue to pull and release work. This is a major reason why continuous processes are much more scalable than batch iterations.

Match Kanban with Continuous Delivery

In a software Kanban process you want to test, finish and release each change. You can´t easily finish a task if you use a naïve testing process where you put your changes into a release candidate and wait for some sort of batch testing. Later in this guide we will cover techniques for Continuous Delivery that allow you to immediately test and release each change.