What is Kanban and How To Use It in Software Development?

Hello everyone,

Today my goal is to introduce you the very basics of Kanban approach and how to use it in our software development projects. The starting point of this method is their following famous motto:

“You don’t have to work harder or longer. You simply need to change the way you look at your goals.”

And it might really be true. Nowadays, the scientific research on human brain shows us visualizing the tasks you are working on will increase your chances of achieving them. That is why visualization is such a key component of Kanban method. To be honest, it is still not a magic and you will have to do the work, but it is all about how you look at it.

Before diving into the details of Kanban in software development world, let's take a look at a little bit about its history and how it evolved from something else to a project management approach.

Kanban originated in Japan as a manufacturing system that has a goal to reduce the costs in production lines. In the late 1940s, the Toyota Production System implemented Kanban to control inventory levels, reduce time to market and improve quality.

So how did they do all that? In simplest terms, by better communication through visual management.

Kanban is actually a Japanese word used for a “signboard” or “card.” Toyota engineers used a kanban (i.e., an actual card) to identify and differentiate the steps in their manufacturing process. The system was highly visible to everyone which gave them the chance to communicate more easily on what work needed to be done and when. It also standardized cues and refined processes, which helped to reduce waste and maximize value. Basically this approach aligned inventory levels with the actual consumption. A signal told a supplier to produce and deliver a new shipment only when material was consumed.

If that makes sense so far, better to focus on our area to see how Kanban might flow simple yet effective in software development projects. 

In our domain, Kanban is a card containing details to complete a request within a clearly defined process represented on a board. It is a common practice to represent a basic Kanban board with the following 3 columns: To Do, In Progress, Done. But for sure in real world examples, it would more look like the one below:

Don't worry about the terms like WIP limits and definition of done for now as I will try to explain them later in this article.

One way or another, the cards flow through this board (pull based process) to visualize the status of each card in the overall picture. Each column has explicit agreements (definition of done) to ensure the card has completed each step with the expected quality. Once the card reaches the last column, the content of the card is 100% ready for delivery, or flows to another board to continue the process until completion.

Now we more or less know what Kanban is and how the steps of software development can be mapped into the board but here is the hardest part, how should we start implementing the process?

The best answer to this question in the whole Kanban literature I've seen is the quick start guide created by Eric Brechner who is leading the Microsoft Xbox software development teams. In his book Agile Project Management with Kanban (Best Practices) which was published by Microsoft Press, he explains how he started to use Kanban in his teams with the following steps:

• Capture your team's high-level working routine: Today majority of the software development teams already use the high-level routine below for product development:

Although it is pretty obvious, it is good to mention that teams which might use very formal or rigid methods (perhaps for compliance or bad old habits) or that do in-depth up front design may use multiple steps to specify a work item. Also, teams that have complex procedures or standards may use multiple steps to implement or validate a work item but this flow represents the general practice.

Another comment is for the ones who does not have a clear idea about the second step Specify which often includes breaking down backlog items into similarly sized short tasks, each with its own new note card. 

So even if you have doubts about your team's current routine, you can just stick to the steps that are fairly common in Kanban approach: Backlog, Specify, Implement, Validate, and Deliver.

• Re-decorate your wall: As you captured your team's working procedure, now it is time to visualize your board to track the progress and attach cards to it for following up the team's work. It is always suggested to have a physical board and sitting all the team members within a close proximity but that might not be realistic for large organizations that's why online tools can also be used for this purpose.

At the end of the day, you will have a Kanban board sample to the one we posted above. Note that your backlog should always stay prioritized at any given time and the top card should be pulled off by a team member when the team is ready to work on the next item. Each and every step should have a done criteria to be fulfilled and unless it is not accomplished, this card can not be pulled to the next column. I will give more information about the done rules later.

• Set work-in-progress (WIP) limits: As we already know, the large part of project management is limiting the chaos by nature in projects. This step is so important and Kanban directly limits the amount of work in progress (WIP)—literally, the number of note cards allowed at each step.

The WIP limits in Kanban serve two essential roles in controlling chaos:

First, they limit the amount of work affected by changing priorities, requirements, or designs. This frees your team to respond quickly and abandon little.

Second, WIP limits restrict the flow of work to match the pace of the slowest step. Because you can’t possibly complete work faster than your slowest step, pacing the other steps to match it will give the highest productivity and stop blame games between different departments in the organizations.

Although there is a great mathematical explanation in Erich Brechner's book how to calculate WIP limits for each and every column you create in Kanban boards, I will not go into that details within this article and you can find lots of online resources for this purpose.

• Definition of Done: Kanban regulates quality through a simple mechanism:

Before a card is pulled from one column to another, the work on that item must pass certain rules—your definition of “done” for that step (also known as the pull criteria).

Just to make it simpler sample done rules for the columns we created above might be like:

Specify done rule: All items broken down into tasks that can be finished in less than a week each.

Implement done rule: Code is reviewed and unit tested, acceptance tests passed, and the customer-facing documentation is complete.

Validate done rule: The work is deployed to production and all issues found are resolved.

• Run Your Daily Standup: Now that you’ve defined what being done means, your team is ready to use Kanban. With a loaded backlog, no up front planning meetings are necessary.

By the way, although there are no milestones, no sprints or no retrospectives needed by the book definition of Kanban process and Kanban flows as long as there is work to do, it is always better to have some of the ceremonies at least in the initial stage of your adoption to follow up the team’s progress and awareness.

One final comment might be about Kanban is spending some time for celebrating the success of the team before moving on to your next projects. It provides a way to say, "well done" to your team and helps with the motivation. Even putting some rewards (this can be as simple as buying a cake or going out for a drink) into your board as a motivator (please check the sample board we put above) would be a great idea.

And that is it for today again! Certainly there are lots of more areas like several different troubleshooting methods and how to track the performance metrics in Kanban but this article's goal is just to give you the basics and I will plan another part specifically more about advanced topics in Kanban.