kanban - how we implemented it

Kanban (看板) for Software Development

The word "Kan" means "visual" in Japanese and the word "ban" means "card". So Kanban refers to "visual card", "signboard" or "billboard".

There's excellent articles describing kanban boards and methods for software development . For example InfoQ has two free e-books that are quite useful for bootstrapping kanban board.

• "Kanban and Scrum - making the most of both" by Henrik Kniberg and Mattias Skarin
• "Priming Kanban" by Jespre Boeg

But if you want go beyond and learn more than just sticky notes on board, you definitely need to study The Kanban Method as formulated by David J. Anderson in his book "Kanban: Successful Evolutionary Change for Your Technology Business". The Kanban Method is "an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improving the system." Definitely more than just the kanban board (which you should always start with lower-case to distinct it to upper case the Kanban method btw).

But how we implemented kanban board?

I am not going to go general details covered by mentioned source. I just present some of our policies.

The Board

The Board

This board was actually used by one of our teams... Today it looks quite different but basic elements are there. Basic set of columns; Baclog; Selected; Develop; Testing; Done. And some WIP limits and avatars.

We are just installing automatic testing and staging environments and creating the separate end-user testing team. While doing, we separate developer testing and user testing to their own columns. Going away from multi-functional team, but the testing team also writes and updates the end user help documents and manuals on multiple languages while testing. And testing team will also do semi-automatic (at least minor) updates to selected production environments and pulling the tasks to final done column.

Visual Card template

Nothing very unusual here I think. Bug id is written if it exists on bug database. Harsh classification to Bug/Feature/Maintenance items. For Fixed Delivery Date (see below) items the obligatory delivery date and estimates are written to top-right corner.

Started On and Dev Done dates on bottom are for statistics and they are written on normal ballpoint pen instead of ink pen which is used for other items.

But one note; use the best sticky notes you can get. Otherwise you might end up having automatic expiration of items not handled in certain time when glue just expires. We have found that nothing compares to Super-Sticky notes from Post-It.

Class Of Service

We use quite directly the Class of Service concept from Anderson's book. Class of Service defines how items are pulled through the system. It determines priorities within the system. Currently we use 4 different levels which are visualized by color of the note. Later we are going to allocate capacity separately for different classes, but before that we can collect some statistics with just implementing the classes. 

Expedite

• Red cards
• Can break WIP limits
• Only one allowed at any given time per board or swim lane
• Anyone qualified have to pull the task immediately
• No estimation unless someone specifically request it

Fixed Delivery Date

• Purple Cards
• Obligatory delivery date is displayed on top-right corner of the card
• Estimated by T-Shirt sizes
• Started in "Good Time" so that delivery time can be respected 

Standard Class

• Yellow cards
• FIFO handling
• Usually no estimation unless "seems to be bigger than usual" 

Intangible Class

• Green cards
• common-sense / ad hoc handling

Swim lanes

We are working on multiple products of our own with multiple projects on each product. Problem domain for products are quite different. Even that basic code base for server development is same, the context where it is used needs special knowledge for development. So we have 2-3 more or less overlapping teams. And one separate mobile development team doing parts for all products since the actual coding is completely different than server based development. So currently we have 3 different server development boards and one mobile development board. No swim lanes. And it feels quite complicated.

But at the end of the year we are moving to new office and we are already thinking whether we move to one or two boards. And maybe swim lanes to different products. Suggestions are welcomed :)

Done Policies

Current Done-policies for columns are presented in quite general terms. No point to repeat them here since there is lots of room for improvements. But we have procrastinated fine-tuning them until the next set of column changes are done. But we have noticed these policies should be visible even if all think they are well-known. It's much easier to explain the board for stakeholders and newcomers.

Things that matter most must never be at the mercy of things which matter least. -Goethe

Friday Special, Automatic backlog expiration.

In addition of 2.5D Backlog, we also kind of implemented Kanban backlog where tasks will automatically expire when they have been on board too long without anybody touching them. You only need no-name sticky notes with bad glue… And large garboard box under board to collect dropped task notes for second review before housekeeping get to handle them. This actually works since we are using magnetic avatars over task notes when work is on progress… Anderson suggest using models for improvement opportunities and making small continuous, incremental and evolutionary changes that stick. This is kind-of anti-stick non-model, so I cannot suggest it? 

But seriously; we are in process to create simple tools to improve our measurement part of Kanban. “Stay tuned”… 

“Kanban is so simple! No plans, no estimations, no iterations, no overhead” - Unknown Besserwisser

2.5D Backlog

Since we already are visualizing the flow, defined WIP’s, established some measurements and agreed what “done” means, it’s time to use models to suggest improvement opportunities.

So my first suggestion is to use Cost-Benefit / Effort-Value models as improvement opportunity to visualize backlog. First little background; we changed one A3 sized whiteboard to larger model in one room. I started to think what to do it or should I consider it as waste. After hard thinking and 2 cups of coffee I had the Illumination. Let’s put there some axis and have at least 2D visualization of something. After yet another thinking session it finally came to me; The Backlog. So we got this.

2.5D Backlog

X-axis shows business value of the task. Y-axis is combination of known effort/cost and technical risks involved to task. There is no defined scale or values to axis. Task notes are just put to board relatively to each other. Now we can see Easy-Wins from lower right portion of backlog to be priority candidates for selection. Not forgetting that Technical-Risks with great business value on top-right of chart should start as early as possible. But actual selection criteria can vary from project to project or even during the project.

Everybody is allowed to change position of notes. Fortunately our customer proxies do not touch on cost dimension. Currently project manager does check and pull the tasks he wants to the “selected”-column on Kanban board, but on long run I think we can get a rid of the “selected”-column all together and let the team to do decisions themselves. Project Manager just checks and realigns notes taking special care of tasks with hard deadline or where value has dependency to time.

The colors represent different types of tasks. That's the "point five" dimension. We use red-defect, yellow-improvement of current feature, blue-complete new feature.

There have been some discussions lately if estimation is even needed in Agile/Lean development? (we do estimations - at least for some tasks…) Our 2.5D backlog is more team visualization tool rather than formal estimation, but I think it can replace formal estimation at least for some domains.

We are also in process to create simple tools to improve our measurement part of Kanban. “Stay tuned”…

Introduction

Several years I have been consuming open source projects and reading published text from other people. For some time I have been thinking how to do my own contribution. So I finally decided to start my own blog and try to give something back to community.

I am CTO at FastROI which is small software company based on Joensuu, Finland. We are making our own products which we are mostly selling by SaaS model. We are learning and implementing Lean and Kanban practices. Same time our quality management system is being prepared for ISO 9001:2008 compatibility. We are trying to sell customizations as agile contracts to quite “old-school” customers.

Definitely there is a lot learn on these areas and I hope I can share as much I can during the process.