It’s common to hear about Kanban in Agile Methodology, but there’s more to them than just a simple tool for workflow management. It’s very successful because it is not only for engineers and project managers to use. It can also be used in any area that requires some kind of organization and needs to be visualized for better track and optimization.
A kanban board is an agile project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency, or flow. It can help both agile and DevOps teams establish order in their daily work. Kanban boards use cards, columns, and continuous improvement to help technology and service teams commit to the right amount of work, and get it done.
In Engineer teams, it’s often that the work they perform is invisible and intangible, so a Kanban Board helps to easily picture the tasks in progress for easy understanding for people outside the project. In spirit of its original Japanese meaning of “Visual Signal”. These boards have 5 key elements:
One of the first things you’ll notice about a kanban board are the visual cards. Kanban teams write all of their projects and work items onto cards, usually one per card. For agile teams, each card could encapsulate one user story. Once on the board, these visual signals help teammates and stakeholders quickly understand what the team is working on.
Another hallmark of the kanban board is the columns. Each column represents a specific activity that together composes a “workflow”. Workflows can be as simple as “To Do,” “In Progress,” “Complete,” or much more complex.
Work In Progress (WIP) Limits
WIP limits are the maximum number of cards that can be in one column at any given time. A column with a WIP limit of three cannot have more than three cards in it. WIP limits give you an early warning sign that you committed to too much work.
Kanban teams often have a backlog for their board. This is where customers and teammates put ideas for projects that the team can pick up when they are ready. The commitment point is the moment when an idea is picked up by the team and work starts on the project.
The delivery point is the end of a kanban team’s workflow. For most teams, the delivery point is when the product or service is in the hands of the customer.
Although Kanban has been widely adopted by software development teams, it was developed in the 1940s and 1950s to boost manufacturing efficiency at Toyota factories in Japan. Kanban is particularly effective for continuous delivery workflows such as content marketing and inventory management. A great example of this is a car company in the 50’s decades, normally the production chain in these companies was focused on “pushing” parts through as quickly as possible, and machines were optimized to produce.
They realized that every car didn’t have the same complexity a figured that it wasn’t necessary to push all the parts of a production chain at once. Instead, they used the same system as a grocery store, they saw that grocery stores used visual cues to “pull” inventory through the process rather than focusing on “push” units. For example, when a customer purchases a carton of eggs they refill that purchase “push” from the inventory, then order another carton of eggs from their supplier, “pull”.
This is how a customer purchase pulls through inventory. If it weren’t this way the grocery store would fill the eggs to the ceiling. Regardless of sales, visual cues, and “pulling” became an important part of these car companies’ manufacturing process.
After this Toyota created a system of boards, production lists, and cards.
- Boards contain or encapsulate a project or a workflow.
- Lists contain and often prioritize cards that share a similar status or attribute.
- Cards describe the task, including related or supporting information.
At its most basics, Kanban boards may have as short as three lists, “To do”, “Doing”, and “Done”, for marketing and software projects should include several lists, Like this:
- Backlog: These items are still early stage. As such, they are not yet ready to be worked on.
- Tasks that are ready to be worked on. The highest priority task should be at the top of the list.
- In progress is where cards go once work has begun.
- In review is the stage when tasks are reviewed, approved, or sent back to “in progress” for more work.
- Done is the status of cards when the work is complete
This methodology is very similar to Scrum, yet not the same workflow. Both are used in engineering teams to improve workflow quality, streamline tasks, and have a record of the project process for Agile teams. The benefits of Kanban can be realized across the value stream from project managers, and team leaders to executives. Engineers can visualize their work, limit their work in process (WIP) and quickly identify bottlenecks. Executives appreciate the ability to receive a birds-eye view into the status of high-priority work across their portfolio.
Software teams adopt Kanban to be more flexible in their process improvement efforts and better visualize the results of their continuous improvement. Through increased collaboration, an environment is established where cultural transformation is actively pursued.