Categories
Agile Agile Methods & Frameworks

Kanban Deep Dive

kan = “visual”

ban = “card”

What is Kanban?

Kanban has become known as an agile methodology, however, its origins stem from a time when the term ‘Agile’ hadn’t even been coined. It was first inspired in Japan in the 1940s. Taiichi Ohno, who is deemed the father of Kanban and Lean Manufacturing, saw that a ‘just in time’ production line process could be a way to help ensure that the Toyota Production System was as efficient as possible. (Ford and other companies had already established really great manufacturing processes and that meant competing in the automotive space was fierce.)

Most people recognise ‘Kanban’ as a board with vertical black lines and post-it notes on it but really it is a process that extends wider than just the board. It is a continuous flow model (or pull-based system). So for instance, in a coffee shop when a barista is picking up a cup that is queued, fulfilling the order and then puts it down on the counter and shouts the name of the customer, to then move onto the next cup in the queue; that could be described as Kanban.

The two fundamental principles of Kanban are:

  1. Visualise the work
  2. Limit work in progress (WIP)

In the example of the coffee shop, cups sitting in a queue would be a way to visualise the work. However more commonly (well certainly in my world), a Kanban board is generally used. The board can be a physical one (hanging on a wall), or digital. Generally, they’re split into sections (most commonly known as swimlanes or columns) that represent the stages of a process (such as to do, doing, done).

Once work is on the board you can begin to see dependencies and priorities and look to position and order the items accordingly. The general idea of a kanban board is to pull items from the left-hand column, across into the various stages until it is done.

If you imagine you don’t take a work item all the way through the process, but rather move it into a doing state then pick something else up from the queue and so on, bottlenecks will start to form and nothing much will get to the complete stage.

Similarly, if there are capacity limitations such as (in software development) testing, this too can cause bottlenecks. This is where the principle of Limiting WIP becomes helpful. If we look to add a limit to the queue length of each stage, we start to shrink queues and eliminate bottlenecks.

Why use Kanban?

  1. Improves quality of work
  2. Improves flow
  3. Identifies and eliminates bottlenecks
  4. Reduces time work spends in queues
  5. Improves teamwork
  6. Reduces wasted effort

Tips/ Steps in getting started:

  1. Identify the flow of work
  2. Make your backlog explicit
  3. Establish a WIP Limit (3 and 5)
  4. Begin pulling tasks from the backlog – move what you can to done, focus only on the doing and then when it has less than the limit make smart decisions on what to pull over into the doing column
  5. Reflect. Use empirical data such as value stream maps and cumulative flow diagrams.
  6. Identify areas for improvement i.e. if there are periods of time awaiting responses on the requirements of a task, look to introduce refinement meetings with stakeholders. If you identify bottlenecks or delays in testing look to introduce test-driven development principles and for improve efficiencies in deployment look to automation and sign off processes

Removing impediments and resolving blockages are key:

  • Move blocked tasks into a blocked column
  • This provides a visual cue and allows for impediments to clearly identified on the board
  • These can then be discussed in the stand-ups (or escalated if required)
  • You should review blocked items each time you are ready to pull more work from the backlog. (Blocked is higher in priority than new work)
  • We should look to limit blocked items to 3.