Kanban in Software Development 2: Queues & Limits

In this, second, part of Derick's journey of Kanban introduction to his software development team, he brings us closer to the splitting up of a process to make it represent the actual work better.

Kanban starter's board

Initially, they have agreed on dividing the development pipeline into three process stages: analysis, development and testing. Now they've recognized the need to add room for preparation work, technical writing and last-stage testing, all to ensure that the process aligns with what they need to do in order to get the work done properly, before it reaches the end customer.

Introduction of multiple pipelines

Derick team's board now has the following stages: backlog – analysis – development – documentation – testing – customer acceptance – delivery.
If you now imagine, that this team was only meant to be working on one feature at a time, this would clearly mean that over half of the team has nothing to do, until the work reaches their designated work stage. This would be wasteful, wouldn't it?

Therefore, what is necessary to introduce, is multiple pipelines, order points and WIP limits. Assuming you have 6 developers, you should be perfectly able to get the team to work on 3 features at a time – 2 developers on each. This means you're running 3 separate pipelines through the previously designed system, and the developer's WIP limit
is 2.

All that's left to do now is managing the other team members in such a way, that their schedules align with when the developed features are ready to be tested, described and moved forward. Thanks to the skill of Derick's team, they were able to assign everyone into the right starting point.

Order points

If you're going to have a couple of features on the go at all times, you also need a steady supply of new work for the team to pick up. This is where order points serve their purpose. By setting them to a minimum of 3 and limit of 5, you're ensuring that each development group always has something new to start working on, but also, that the analysis team will not get too far ahead of the development (as this is not recommended, in a highly changeable environment).

Queues

Since the analysis column just changed from a set of 3 to a queue of 3-5 items, it no longer needs to be represented on the board as a 3-pipeline stage, the items can just form a queue, and the rule is – top item goes first.
Respectively, since the analysis is a queue now, the backlog can be one as well, and follow the same FIFO rule. So, the first pipeline step on the board is now development.

WIP limits

Seeing as all work past the analysis stage has an equal priority and an even number of people to work on it, there is no reason why the limit for each column shouldn't be just 3.
It also makes sense to join the proper working columns into one set (development + documentation + testing), to form an In Progress stage.

Completing the pipeline

The way you want to go about getting the client's acceptance may depend on their approach. If they're present in your workplace, you could actually incorporate this process stage into the In Progress column, therefore speeding up and perfecting how things are being done (instant feedback is very valuable).
However, if the Product Owner wants to do the acceptance in timed intervals, you will have to deal with a bottleneck in this spot. Finding ways to manage this has to be matched to the customer's demands and wishes, unfortunately.

Is this it then?

Now that Derick's board is all done, the limits, order points and pipelines are set, did he sit and think: done, this is what we're going to do from now on? Of course not. Kanban is all about finding ways to improve and streamline.
An inseparable duty of Kanban users is following what's happening to see if the assumptions you work on are working, or do they need adjusting or rethinking?

Read the next part of Derick’s Kanban journey »