Committing to the continuous improvement of kaizen

This article was originally published on stickyminds.com 

Kanban, a highly effective framework for “going agile,” is based on the Japanese business philosophy of kaizen, which believes that everything can be improved. One of the principles of kanban that makes it well-suited for agile delivery is that it only works if you commit to continuous improvement. Here, I’ll detail what kanban is, how to use it, and how your QA team can implement it right away.

What is Kanban? 

In order to simplify the manufacturing process and increase efficiency, in the 1940s Toyota implemented just-in-time manufacturing—effectively, making only what is needed, only when it is needed, and only in the amount that is needed.

The inspiration for how to actually make this idea work came from supermarkets. Supermarkets keep inventory levels based off the pull of the consumer rather than the push of the supplier. For example, employees restock supermarket shelves after customers buy the product, and they only put out enough of it to make the shelf full again. Managers only order more inventory when they predict that they will run out of something in a couple of days. With this method of stocking, supermarkets minimize the amount of inventory that perishes and goes unsold.

So, how does this translate to a car manufacturing line? Toyota introduced kanbans—which, in Japanese, literally means “cards”—to signal the steps of the manufacturing process. The cards helped regulate the workflow along the line and eased communication between various parts of the chain by making it clear what needed to be produced, when, and how much at a time.

Fortunately, kanban is not just useful for Japanese car makers. Restaurant kitchens, your weekly to-do list, side projects, and, yes, software development cycles all can be managed using this simple method.

How Does Kanban Work? 

The only essential materials for kanban are a marker, sticky notes, and a board. Create “cards” from the sticky notes representing work items that have to go through several phases, from start to finish. Then draw columns on the board for each phase the cards need to go through, with a number at the top of each column that indicates the maximum number of cards (i.e., work in progress) that can be in that phase at a time. This number probably will and should change as your team improves its ability to gauge and reduce bottlenecks. The columns could simply be labeled “to do,” “doing,” “waiting,” and “done,” or they can be more process-specific, such as in the examples below.

In these examples, you start pulling cards from the Backlog column, which are features that need to be created or tested. Once the card is ready and there is room for it in the next column, it is transferred to the next phase, and so on until it has moved through all the columns. The name of the columns will depend on the nature of the work and the teams; your kanban board can be completely tailored to suit your needs.

Another helpful thing many teams do is dividing the columns in two, with one lane for “doing” and one for “done,” as you can see in the software development kanban example above. This way, it is clear to whoever is in charge of the following column to know when they can pull another card and begin working on it.

The beauty of this system is that it helps you detect where bottlenecks are. The work-in-progress limit stimulates conversations about process problems. In the examples above, you can see some columns are at capacity and some are not, but none has more cards than prescribed.

Why Kanban Works

The human brain is more fluent in pictures than words. Studies have shown that the brain processes image elements simultaneously, while language is decoded linearly, taking more time. In fact, the brain processes visual stimuli sixty thousand times faster than text. Kanban boards are a great way to visualize pipelines.

Kanban also gets you into the mindset of finishing projects rather than focusing only on starting them, like traditional task lists do. It feels rewarding to move a card off the board once it has been completed. A popular motto for those who use kanban is “Stop starting. Start finishing!”

In order to successfully implement kanban, it’s important to understand its underlying fundamentals. The following principles were developed by David Anderson in his book Kanban: Successful Evolutionary Change for Your Technology Business.

The human brain is more fluent in pictures than words. Studies have shown that the brain processes image elements simultaneously, while language is decoded linearly, taking more time. In fact, the brain processes visual stimuli sixty thousand times faster than text. Kanban boards are a great way to visualize pipelines.

Kanban also gets you into the mindset of finishing projects rather than focusing only on starting them, like traditional task lists do. It feels rewarding to move a card off the board once it has been completed. A popular motto for those who use kanban is “Stop starting. Start finishing!”

In order to successfully implement kanban, it’s important to understand its underlying fundamentals. The following principles were developed by David Anderson in his book Kanban: Successful Evolutionary Change for Your Technology Business.

1. Start with what you do now: Don’t reinvent your whole process. Kanban can work within your current processes, whether they are agile, waterfall, or a hybrid.
2. Agree to implement incremental, evolutionary change: Revolutionary changes are less likely to be effective in the long run. Plan to be flexible and continue to make improvements.
3. Respect the current roles, responsibilities, and titles: People often fear change, which hinders forward momentum. Don’t go changing everyone’s roles in the beginning.

As with the principles, implementing kanban without having an understanding of its properties will be futile. Here’s a brief overview of Anderson’s workflow steps.

1. Visualize the workflow: What are the different states the work passes through? Make a map of them.
2. Limit work in progress: Work in progress at each state in the workflow is limited, with new work being pulled in only when there is available capacity within the local task limit.
3. Manage the flow: Measure and report how long a card stays in each state and how smoothly it transitions. Is the flow consistent, or have there been major roadblocks?
4. Make process policies explicit: Without a clear understanding of how things work, any discussion of problems tends to be subjective. With explicit definitions, it is possible to objectively discuss issues and come to a consensus on ways to improve.
5. Improve collaboratively using models and the scientific method: There are several workflow models you can use to start off with, then employ the scientific method to make observations and adjustments to the system.

Making Kanban Work for You

I want to leave you with a few more tips and resources to make kanban really work for you.

At my company, we have used kanban not only on paper, but also on one of our favorite free project management tools, Trello. With Trello you can create several boards, each with “lists” that we can think of as columns. Each list can hold several cards, and when you click on their titles, they can contain comments, task lists, and due dates. Each card can also be assigned to one or more team members. The only thing it lacks is a way to tack on a number to the top of each list to show how many cards it contains, but luckily, there is a Chrome extension for that.

An example Trello board:

Other software companies also have sprouted to create digital kanban boards, such as Kanbanize, LeanKit, and an open source tool, Kanboard. I haven’t used them, but I have found their blog posts very informative for their explanations of how to apply kanban.

Kanban is not just for development teams and managing system testing. The QA team also can use this solution to organize tasks, identify bottlenecks, and make their processes clearer and more consistent.

Do you use Kanban? What do you think?!

Recommended for You 

The Software Testing Wheel
Can There Be Testers in Scrum?