With Kanban, as with the other Agile approaches, we want to add value as soon as we can, by delivering useful software as fast as possible. The reason for this is two-fold:

1. Most people don’t know what they need until they see it. It's hard to imagine how the software will look and behave until it's built. Everyone has a different version of it in their head. Once you have something working, you can start to get feedback from your customer. This is when the real work begins.
2. The domain we’re operating in is rapidly evolving. In business terms, 6 to 12 months is too long to wait for something. The way the business works and the rules that govern it could have easily changed within such a timeframe.

For work to start to flow across the board, we have to do two things:

1. The first step is to reduce the size of each work item so that it is as small as possible. Taiichi Ohno called this reducing the waste of unevenness (Muri). For us in the software industry, unevenness is reduced by managing and reducing probable variability,  which we can also manage by keeping the work item as small as possible. This doesn't mean that we're eliminating all variability, just reducing the amount.
2. The second step is to switch to small batches. This can either be done as Scrum or XP does, using Sprints or Iterations. Alternatively, the more granular way is to start to manage Work In Progress (WIP) limits so that the team can focus their effort on the items currently being worked on and avoid the loss of time caused by context switching when multitasking. Assuming the items have been prioritized by value, this allows them to focus on completing the high-value items first.

Rather than thinking and working in iterations, the focus in Kanban is on optimizing the flow of work items through the system. To optimize flow two shifts in thinking have to happen. Firstly, we need to think of the system as a whole, the end-to-end process from idea to delivery of that idea. Secondly, instead of pushing the work through the system, we have to think of the system as pulling the work through it. When the system has the capacity, it pulls the next piece of work into it to be worked on.

This requires careful control; the aim is to avoid large batches of work that move as one cohesive block as this only encourages optimization at the local level. Instead, we carefully manage WIP and prevent overcapacity by limiting the number of items being worked on at any given moment.

The following shows a Kanban board where our team has mapped out every step of the process:

Visualizing your work in this way will soon help you identify when there is too much work in progress.

For example, the team using the Kanban board in the following figure have identified that they have too much work to test and this is causing a logjam:

Blocks like this can have quite subtle effects. One observed result of allowing work to accumulate is to put all of the work items in the column into a single batch. We can then create a single software deployment and carry out testing on all the items at once. We think this will create efficiency in our testing, which it may do at a local level. However, with five work items in that column, the reality is that each work item will delay the others as we wait for testing to complete. If we find any problems with one or two them, the whole batch will be delayed and the overall flow will be significantly reduced.

To tackle this, determine if this is a one-off or whether a pattern is emerging. Either way it is important to take pressure off the people who are currently testing, by swarming on the work as a team. Once the workload is back to normal, the team can prevent this from happening again by placing a WIP limit on the test column. The following figure shows a Kanban board with WIP limits set. We'll talk about WIP in more detail in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle: