Kanban means lean manufacturing, continuous development, customer orientation, etc.

Imagine Toyota workshops installs Toyota Corolla doors and there is a pack of 10 doors near your workspace to be installed, one after another, onto new cars. When there are only five doors in the pack, you know that it is time to order new doors. Therefore you take a Kanban card, write an order for another 10 doors on it, and bring the card to the workshop that manufactures doors. You are sure that new doors will be manufactured by the time you have used the remaining five doors.

That’s the way it works in Toyota workshops: when you are installing the last door, another pack of 10 doors arrives. You constantly order new doors only when you need them.

Now imagine that this Kanban system works all over the plant. There are no warehouses with spares laying around for weeks or months. All the employees work upon requests and manufacture the only the necessary amount of spares. If there are more or fewer orders, the system will match the changes.

The main idea of Kanban methodology cards is to scale down the amount of work in progress. For example, due to the Kanban methodology, only 10 cards for doors may be given for a whole manufacturing line. It means that only 10 ready-made doors will be on the line at any time during the production loop. Deciding when those doors are ordered is a task for those who install them. Always limited to 10 doors, only the installers know the upcoming needs of the workshop and can place orders with the door manufacturer.

This methodology of lean manufacturing was first introduced at Toyota, but many companies all over the world have adopted it. But these examples refer to manufacturing, not to software engineering.

The difference between the Kanban methodology and SCRUM is that:

• There are no time boxes in Kanban for anything (either for tasks, or sprints)

• The tasks in the Kanban methodology are larger, and there are less of them

• The period assessments in Kanban are optional, or there are none of them at all

• There is no “speed of team” in Kanban — only average time for a full implementation is counted

For example, a common problem with the SCRUM methodology are higher costs due to discussions, meetings and big losses of time at the joints of the sprints, when at least one day is wasted to complete a sprint and one more day to start another. If a sprint is two weeks, then two days out of two weeks is 20%, which is a heck of a lot. So while using SCRUM methodology, just about 30-40% of the time is wasted on supporting the process itself including daily rallies, sprint retrospectives and so on.

The Kanban development methodology differs from SCRUM with its focus on tasks. The main objective of a team in SCRUM is the successful completion of a sprint. In the Kanban methodology, tasks take first place. There aren’t any sprints and a team works on a task from beginning to end. The deployment is made when it is ready based on the presentation of work done. A team that follows the Kanban methodology should not estimate time to fulfill a task, since there is no sense in it and these estimates are almost always incorrect.

The objective of a manager who uses the Kanban methodology is to create a prioritized task pool, and the team’s objective is to fulfill as many items from this pool as possible. That’s it. There is no need for any control measures. All the manager needs to do is add items to the pool or to change their priority. This is the way a Kanban manager runs a project.

Columns from left to right on the Kanban board:

• Goals: This is an optional, but useful, column on the Kanban board. High-level goals of a project may be placed here so everyone on the team knows about and can be regularly reminded of them. Example goals could be “To increase work speed by 20%” or “To add support for Windows 7”.

• Story Queue: This column deals with the tasks ready to be started. The highest card (which has the most priority) is taken first and its card is moved to the next column.

• Elaboration & Acceptance: This column and all the others before the “Done” column may vary, based on the workflow of individual teams. Tasks that are under discussion — an uncertain design or code approach that needs to be finalized, for example — may be placed here. When the discussion is finished, it is moved to the next column.

• Development: The task lives here until the development of the feature is completed. When the task is complete, it is moved to the next column. If the architecture is incorrect or uncertain, it may be moved back to the previous column.

• Test: The task is in this Kanban column while it is being tested. If there are any issues, it is returned to “Development.” If there are none, then it is moved to the next column.

• Deployment: Each project has its own deployment. This could mean putting a new version on the server or just committing code to the repository.

• Done: The card appears in this section of the Kanban board when the item is completely finished and doesn’t need to be worried about anymore.

Top-priority tasks may appear in any column. Planned or not, they are to be performed immediately. A special column may even be created on the Kanban board for these items. In our example picture, it is marked as “Expedite”. One top-priority task may be placed in “Expedite” for the team to start and finish as soon as possible — but only one such task can exist on the Kanban board! If another is created, it should be added to the “Story Queue” until the existing top-priority task is dealt with.

How Teams Benefit from Kanban

First, decreasing the number of the tasks performed simultaneously will reduce the time it takes to complete each one. There is no need to switch contexts between tasks and keep track of different entities since only necessary actions are taken. There is no need to do sprint planning and 5% workshops because the planning has already been done in the “Story Queue” column. In-depth development of a task starts only when the task is started.

Second, showstoppers are seen immediately. When the QA specialists, for example, can’t handle testing, then they will fill their column and the programmers who are ready with new tasks won’t be able to move them to the “Test” column. What shall be done then? In such a situation it is high time to recall that you are a team and solve the problem. The programmers may help to accomplish one of the testing tasks, and only afterward move a new item to the next column. It will help to carry out both items faster.

Third, the time to complete an average task may be calculated. We can log the dates when a card was added to “Story Queue,” when it was started, and when it was completed. We can calculate average waiting time and average time to completion through these three points. A manager or a product owner may calculate anything he orshe wants using this figures.

The Kanban methodology may be described with only three basic rules:

1. Visualize production:

   i. Divide your work into tasks. Write each of them on a card and put the cards on a wall or board.

   ii. Use the columns mentioned to show the position of the task under fulfillment.

2. Limit WIP (work in progress or work done simultaneously) at every stage of production.

3. Measure cycle time (average accomplishment time) and improve the process constantly to shorten this time.