Kanban in Software Development 1: Introduction

Whether you're a Scrum, XP, Waterfall or any other Agile method's fan – you'll be sure to agree, that the one goal of using a visual board is radiating the information onto the team. Meaning – making sure that each team member knows where exactly in the process a task is. How much work is still left to be done, what's in progress and what has been completed.

What kind of a board is a Kanban board?

At first glance there may not be a clear difference between Kanban and any other task board. You'll see sticky notes – Kanban cards pasted onto a board in seemingly random order. Keeping this in mind, there is no real visual, important difference between Kanban and other boards.

The core difference is in the approach to using these boards. Kanban is all about learning to pull value through the system. This way of thinking goes back to the original Kanban industrial application – where little Kanban cards (signal cards) were used to indicate how many parts are in stock, therefore letting the re-stocking team know when to order more.

Kanban pipeline

The set of stages that a task needs to go through from request to delivery is sometimes called a pipeline. The movement of the cards – flow – is run by the pulling action that happens at the right end of the pipeline. Let's look at an example from software development: 3 basic stages – analysis, development, testing. Assuming, that the people in testing have all work done, they pick their next task from development, and these in turn look to analysis for new work to pull.

As soon as an item is done and released, there is room to add new features into the pipeline.

This is how a very simple pipeline would work. However, since hardly any process is quite this simple, Derick has kindly prepared some more advanced Kanban pipeline examples in his other articles of the short series.

Read the next article in the series: Kanban Queues & Limits »