Geek Philosophy

(This post is a continuation. Please read part 1 and part 2 first.)

A year or so had passed since I first started implementing the tracking system I’ve been discussing. However, in August I started work on a larger project that had to go through the company’s formal project tracking system. The project was took about 3 months (we’re just finishing it off), and we have done no releases since – that’s an eternity for a team like mine that’s used to shipping production code very two weeks. With the project coming to a close, I was looking forward to moving back to a process that encouraged more continuous flow.

I had first thought about Kanban after hearing a talk at the Agile Vancouver mini-conference, Lean Development for Lean Times. I’d also recently finished reading David Anderson’s excellent book Agile Management for Software Engineering, which emphasized the importance of short cycle times and delivering value to the customer quickly. After corresponding with David about this book, I mentioned Kanban to him and was delighted to find that he was working on book on the subject. I was able to obtain a draft of this book to review, and the ideas presented within further cemented my ambition to try Kanban with the team.

Another thing worth noting is that my team had grown, from 5 engineers under me to 8. We’d also taken on maintenance duties for yet another product, bringing the total up to 4. This increase in responsibility caused me to spend more time thinking about our development process, since more was at stake.

Limiting Work In Progress

I’ve mentioned before that the only real difference between what I was doing before and Kanban is the presence of formal Work In Progress (WIP limits). What makes WIP limits so important? As it turns out, this minor change can have major effect on the effectiveness and responsiveness of the team.

Little’s Law, a finding of queuing theory, shows that the cycle time of an item in a system is directly proportional to the number of items in the system. Thus, to reduce cycle time, it is necessary to reduce WIP. This is intuitively obvious – I can finish reading a book faster if I read it all the way through than if I read some, then read the paper, then read another book, then come back to the first book – but by limiting WIP both stakeholders and developers are made explicitly aware of the implications of trying to do too much at once.

The benefits of limiting the size of the backlog have already been discussed in part, but by having a hard cap on the size of the backlog, stakeholders can clearly see that by choosing a certain work item other work items are not being addressed. This leads to increased collaboration between different business units, and forces everyone to “see the whole” (to use lean terminology) – individuals no longer argue for local optimizations (i.e. pushing their agenda through to the detriment of others), but instead come to an agreement about what would be best for the business as a whole.

Limiting the size of the backlog also helps stabilize lead time. Expediting items (“drop what you’re doing and work on this!”) is not conducive to flow, since it almost always involves context switching. Being able to provide stakeholders with the average cycle time of items is of great benefit – it can help make scheduling decisions, decide on relative priorities, and give visibility to other departments.

Limiting WIP in the “active” states (analysis, design, testing, customer acceptance) can help identify and deal with bottlenecks. For instance, if test is a bottleneck, which will be visible when test starts to run up against its WIP limit, we can use techniques from the Five Focusing Steps to alleviate the problem, such as ensuring that test is never idle by having a buffer of work always ready for them. Since the rate of flow through your system is limited by the bottleneck, improving the performance of the bottleneck will directly lead to increased throughput and reduced average cycle time.

I don’t yet have any numbers or metrics for my team showing improvement – I only implemented Kanban a week ago. As soon as I have a large enough set of data draw some conclusions from, I will post my findings.

Any questions so far? I’m understanding all of this, but I haven’t had a chance to explain it to anyone, and I always find that explaining / teaching really helps me solidify my knowledge.