Kanban, a highly effective agile framework, is based on the philosophy that everything can be improved. And it's not just for development teams. The QA team also can use kanban to organize tasks, identify bottlenecks, and make their processes clearer and more consistent.
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.
- 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.
- 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.
- 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.
- Visualize the workflow: What are the different states the work passes through? Make a map of them.
- 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.
- 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?
- 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.
- 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. The QA team also can use this solution to organize tasks, identify bottlenecks, and make their processes clearer and more consistent.
Well, I think Agile attitudes are worth considering when it goes to software issues. What did convince me personally? Case studies, real examples. When I read about this BBC case http://kanbantool.com/kanban-library/case-studies-devops/lean-software-m... and the other ones found in the web, I was both surprised and fascinated at once ;)
Interesting, but when the cards/feature get Done and you need to do a Regression, you have to move cards from Done to Regression, it seems not good to me, another thing is how do you do Test Suites, eg. I want to execute test only of a specific feature that is Priority equal High, how do this on a Kanban board?
Allan, there are a number of different approaches you can try to cover Test Suites and Regression, depending on what bests suits your team.
One of the biggest advantages in these type of Agile processes is that there are a lot of different ways to "skin the cat", where the approach that best fits your team and culture is the way to go. Hopefully this helps.
Thank you for the article, Sofia.
I am one month shy of my first year in software testing, and have learned a lot in this time. I discovered the Kanban while reading to get up to speed in testing, and purchased the book Personal Kanban Mapping Work|Navigating Life by Jim Benson. I started a Kanban at my desk to organize and track my testing, and couldn't say enough about the method. For the first time in my career, I had found a way to limit my work to a reasonable amount. I am able to prioritize the tests in a meaningful and proactive way. I am able to update my supervisor for the required weekly reports about accomplishments, roadblocks, and projected work for the upcoming week. Through the regression process of examining what was accomplished and not completed, I have found ways to reduce turnaround time and create better outcomes.
I have a plan to teach my small testing department (seven of us) about Kanban, not only for their personal use, but as a whole to develop a more meaningful way to update the business of our work. This article precisely describes how to implement this tool, and I would encourage anyone to start with themselves, then grow Kanban for their department; the effort will not go unrewarded.
I used myself http://kanbantool.com/ was very helpful because of simple interface and realtime tasks. Helped me organizate my work and hause resposibilities. If you have a lot to do and you find it difficult to organize yourself i can highly recommend this software :)
Kanban has many uses in the test lab. This paper: http://kiberle.com/wp-content/uploads/2016/01/2011-Kanban-at-HP.pdf shows how a software testing group at HP used Kanban to manage process improvements, development of tools, and other special requests.
When the test lab is separate from the development team, there can be a temptation for the development team to declare the story "Done" when it is submitted for testing, and let the test team run a separate Kanban. Don't do this. The development team cannot see their true velocity when the story is declared "Done" before it is in fact "Done". An example is shown here: http://kiberle.com/wp-content/uploads/2016/01/2010-Lean-System-Integration-at-HP.pdf