Distributed “Kanban”

The distributed team I am working with currently has been trying out a little bit of Kanban.  We have assigned a WIP limit to the In Development / For Review column(s). That is, if the total number of stories in the In Development + For Review columns adds up to (or more than!) the WIP Limit, you should not pick up a new story, until at least one story has been reviewed and closed off and we are again below the WIP limit. (Ideally, going forward we should obviously add WIP limits to other parts of the process to, but we had to start somewhere.)

While there are lots of interesting things to say about this – such as that it has made us more disciplined and probably reduced lead time (working on the stats) and might make the team more predictable –  I will focus on the distributed side of things in this post.

Communication is a challenge on every distributed project I would say, and hence getting buy-in and understanding of the WIP limits at one location, does not necessarily mean that every location understands or starts respecting the WIP limits immediately. As every other change effort, one needs to use the full range of consulting skills / influence strategies.

What is a concrete challenge though is the time-zone differences. If one team finishes development and puts a story into For Review, then their typical next step would often be to pick up a new story. What so if the WIP limit will be breached? Should they wait until the resources that will do the technical and business reviews of the stories gets in (given they work in a different time-zone)? Or should they break the WIP limit?

The previous might force you to add a bit of a buffer to your WIP limit. And that might make sense. However, initially this is what happened to us: Location B puts story 1 into For Review and picks up story 2. Location A reviews story 1, but it needs more development or bug-fixing. Location B gets in the next day, does some fixes on story 1, and finish development on story 2. They even pick up story 3. Location A reviews story 1 and story 2, but they are both still not accepted. Hence Location B now has 3 stories in play.. This could go on for some time.

Let’s say the capacity of Location B is to work on one story at a time. Does it make sense to add in a buffer of 2++ extra then? I tend to disagree. So what we ended up communicating to Location B was to focus on quality before quantity. Do not rush to pick up new stories, but try to finish stories with significant quality.

What happened was two things:

1. Location A started reviewing stories much quicker. Focus was first on cleaning out the For Review queue – then do some development. (In order to give Location B quicker feedback, and prevent them from picking up too much new work before stories had been successfully reviewed).

2. Location B decided the brilliant thing of doing some local technical review first, before marking the story as For Review. This raised the quality, and took some of the work load off location A. It also meant that Location B are no longer rushing to picking up new work, but focusing on completing stories properly.

These two things allowed us to keep our WIP limit relatively tight. We do have a buffer for the stuff in For Review, but we try to keep it as small as possible.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: