Kanban as a process for agile development


In this blog I want to explain about the “kind of” agile development methodology called KANBAN in a three steps. Let’s get started.

What is Kanban?

The word Kanban came from Japanese for “visual signal” or “card.” It became a scheduling system for lean and just-in-time (JIT) production. Kanban was developed by Taiichi Ohno in 1940’s, an industrial engineer at Toyota, as a system to improve and maintain a high level of production. Toyota line-workers used a Kanban to signal steps in their manufacturing process. The system’s highly visual nature allowed teams to communicate more easily on what work needed to be done and when.

In 2003, David J. Anderson formulated the Kanban Method as an approach to incremental, evolutionary process and systems change for organizations.

Kanban is another framework used to implement agile. Kanban does the same for software teams. By matching the amount of work in progress to the team’s capacity, Kanban gives teams more flexible planning options, faster output, clear focus, and transparency throughout the development cycle.


One of the great things about Kanban is that you can apply it to your existing process. You are simply identifying ways to improve what you are already doing, so you don’t have to start from scratch. A Kanban team is only focused on the work that’s actively in progress.

What are the principles?

  • Visualizing the Work – we have to split the work into pieces, write each item on a card and put on the wall. It is necessary to use named columns to illustrate where each item is in the workflow. Making the work visible—along with blockers, bottlenecks and queues—instantly leads to increased communication and collaboration.
  • Limiting Work in Process – assign explicit limits to how many items may be in progress at each workflow state. By limiting how much unfinished work is in process, we can reduce the time it takes an item to travel through the Kanban system. Get more done by do­ing less!
  • Measure and Improve Flow – average time to complete one task, sometimes called “cycle time”, we have to optimize the process to make lead time as small and predictable as possible. Teams measure their effectiveness by tracking flow, quality, throughput, lead times and more. Experiments and analysis can change the system to improve the team’s effectiveness.


How to get started?

  • Mapping Current Workflow – the first thing to do is to identify the major processes in our department or organization, and then identify the steps in the individual processes. Where do tasks come from? How are they prioritized, defined, and assigned? What are the steps that it takes for an idea or a task to be complete and done right?
  • Putting Work on the Board – tasks represent something that has to be done and something that is worth doing, plus they should have a name that everyone recognizes and understands. In addition, depending on the task and the process it is part of, you may want the Kanban board to show or track other information such as: creation date, deadline, created by, priority, type, description, etc.
  • Round the Board – when all the tasks are in the board it is time to start moving them step by step. Make sure that when someone finishes some task and starting another, your board is updated. At this point it possible to observe where the tasks getting stuck. In a daily meetings you can discuss the work flow and progress.
  • Limiting Work in Process – in the beginning, it is hard to know the ideal amount of work in process for various tasks or processes. You have to start somewhere, however, so we can begin with the best guess or with a current view of the board. Limiting our work in process can help us finish more work, more quickly. The more we dive into multiple tasks at once, the less effective we became.
  • Measure and Learn – the best tool to measure Kanban performance is Cumulative Flow Chart. Each day, for each column, mark how many tasks are in it or somewhere further down the workflow. This will produce a mountain-like looking chart, which gives insight into the process, shows past performance and allows to predict future results. One of the many things you can read from it is the mean time for task to get through the workflow.

The team should make time to regularly review the metrics, reflect on what they’ve accomplished and how it felt, and consider what changes to the process might yield further improvements.


Upcoming soon: How to audit agile development processes?