A good idea can become a spoiled mess if you use the wrong approach to realize it. Software development is no exception, and broadening your knowledge of Agile processes not only helps keep a project from spoiling but also serves as a powerful tool for your organization.
Enter Kanban, the visual, tactile way to coordinate a workflow and reduce waste while maximizing efficiency. Using simple cards and a chart to define your process, Kanban’s methodology is the low overhead way for teams new to Agile to improve their workflow.
This article will explore the basics of Kanban and how you can use it as another tool in your project management tool belt. As with all new tools, let’s start by understanding what the heck it is!
Table Of Contents
- How Kanban Evolved into a Methodology for Software Development
- The Kanban Methodology for Software Teams
- How to implement Kanban Roles in Software Development
- The Pros and Cons of Implementing Kanban for Development
- Three types of Software Teams that Could Benefit from Kanban
- Getting Your Development Team Started with Kanban
- Is Kanban Right for You?
How Kanban Evolved into a Methodology for Software Development
Chances are you’ve heard of Kanban, but it’s less likely you know the story of its origins. What is now an Agile method for developing software started in Toyota’s automotive factories, longer ago than you may think.
Kanban originated in these Japanese facilities around 1940 as a method of addressing waste in the day-to-day workflow. The word “Kanban” comes from the Japanese word for “sign” or “billboard,” in reference to the cards which structure this approach.
What Toyota would do is accompany automotive parts with physical cards that detailed the part, what needed to be done to it, and where it needed to go. The act of passing these cards along a workflow reduced issues and made it easier to spot waste.
It’s a process older than most people in today’s tech sector, but despite that, it persists as one of the most popular methods of Agile development still practiced to this day. The transparency of a Kanban card moving along a workflow has been adopted in the field of software development with great results. Kanban lets teams get straight to the point and focus on reducing waste where it’s most apparent in software – in the workflow. But now that we have an idea of where it came from, let’s get to the interesting part – how do I use it on my development team?
The Kanban Methodology for Software Teams
If nothing else, Kanban can be summarized in three core structures: the Kanban board as a visualization of work, the Kanban cards and their transitions within a workflow, and the limits on Work In Progress (WIP) for the measurement of throughput. Now let’s break down these features to discover the core of its magic.
The Kanban Board
The Kanban board is the cornerstone of modern Kanban. Toyota may have attached their cards to parts in their factories, but it’d be pretty unwieldy for a development team to tie kanban cards to their codebase. Enter the Kanban board: a visual display of a team’s workflow and the work currently in progress. The board is made up of columns, each representing a specific step in your workflow.
Every step from starting a task to claiming it as done exists on this board in chronological order from left to right, while the transitions between them are recorded and shared with the team. Think about the workflow at your job. Can you break it down into a sequence of steps? If it’s not immediately easy for you to do this, then there’s already some benefit to doing Kanban!
Creating the board alone is a good way to collaborate on what could be confusing about your team’s workflow, and visualizing it is an easy way to suss out those issues. Think of it as a horizontally-oriented checklist.
The Kanban Card
But where there is a workflow, there have to be tasks, and the Kanban board isn’t complete without the accompanying Kanban card. The card is the identity of the methodology. Simply put, it is a record of work that needs to be done. Each task gets its own card, and those cards are placed on the Kanban board under the appropriate step in the workflow.
As work is completed, the corresponding cards are moved to the next column on the board. Once a card has entered the “Done” column, it can be removed. These cards need to be simple to read so that a board of many cards are easily understood at a glance. They should include a title, a sentence summary, and a priority or a due date. Everything else can be in supporting documents elsewhere.
The Limitations on Work In Progress (WIP)
We have the building blocks of Kanban, but the bulk of its usefulness comes from the ability to limit work in progress and measure throughput. Humans have a limit to their WIP, but it’s common to ignore this and end up with a backlog of tickets at a certain stage in the workflow, creating a bottleneck. In Kanban’s methodology, each column of the board can only take on so many cards, usually one per person.
By visualizing the process, it forces team members to be cognizant of their output and address issues with the workflow. All the while, cards that do make it to the end are collected and added to the throughput value. At the end of a week or month, you can check how many cards made it to the end and compare it to previous throughput values to see how your process is improving.
How to implement Kanban Roles in Software Development
Kanban is generally quick to implement, and may not require a dedicated project manager at the beginning or when practiced with smaller teams. Moving cards across the board is intuitive, and the management overhead can sometimes be shared on a consensus basis.
As Kanban matures in your team, you may find a need for a dedicated manager or want to assign some of its prescribed roles, such as the Service Request Manager (SRM) and Service Delivery Manager (SDM).
In more robust Kanban implementations, an SRM is responsible for gathering the requirements of stakeholders to form and prioritize tasks, while the SDM controls the process for delivering functionality once completed.
In the software world, this can mean one team member serving as a single point-of-contact for change requests, while another is responsible for facilitating the delivery of those changes (such as in a CI/CD pipeline). Although you may not initially choose to assign these roles, it is good to know that they’re available if they serve your process.
The Pros and Cons of Implementing Kanban for Development
Now, of course, Kanban isn’t the cure-all project management tool; it has its pros and cons. While it is relatively easy to implement and convince colleagues of the benefits, it also doesn’t stand perfectly on its own and can exacerbate some existing management issues. Let’s break it down:
Pros of Implementing Kanban:
1. Low Overhead
Overseeing the use of a board, cards, and measuring throughput is easy compared to most methods of project management. The benefits of Kanban don’t require a whole lot of extra work to witness.
2. Reduces Waste (an easy buy-in)
Kanban excels at highlighting process issues and solving them. Not only is this a great thing to do in any company, but it also makes getting buy-in easy. What team could oppose reducing waste in the process?
3. Objective Bottlenecks
Without the proper process, bottlenecks may be defined as “they are too slow” or “the work is too long,” which may not be straightforward to solve. Kanban uses measurements of WIP limits and time in a column to get accurate depictions of bottlenecks so they can be solved directly.
Cons of Implementing Kanban
1. Lacks Iteration
Building software in iterations is a cornerstone for most modern development processes, which is not intrinsic to Kanban at a ticket level. You can, of course, build iteration on top of Kanban, but it often ends up being its own separate process.
2. Sizes set by Workers
Kanban estimates come from frontline workers, and the measure of throughput depends on that. Though this can be a good thing, it can be abused if those people aren’t motivated properly and showing that motivation happens outside of Kanban.
3. A Piece, Not a Whole
Kanban facilitates workflow nicely but doesn’t have an answer for most other areas of project management. When it comes to complex projects that include those areas, Kanban needs to be paired with other techniques like Scrum. Having multiple techniques on one project can confuse the team.
Three types of Software Teams that Could Benefit from Kanban
All teams are different; there are some that will benefit significantly from Kanban and some that may not gel with the approach. Here are a few types of teams that can benefit from a Kanban approach:
A Team That Has Enough Resources but Is Still Tripping Over Parts of the Workflow
Though it’s often the other way around, it’s possible that your team has everything they need to succeed, but they’re not being utilized correctly. Four developers can do a lot more than two developers, but if they don’t have a proper workflow, their productivity can suffer. Kanban is of great benefit to teams like this because if there are enough resources to do more work, then the process is the first thing to improve. Being able to focus on each step is what Kanban is best at, and teams like this will quickly see process improvement.
A Team That Wants to Be More Agile but Is Still Getting Used to Cross-Functional Roles
A cross-functional team is one that puts all members on equal standing, provides enough expertise to complete their tasks, and takes shared responsibility for the ticket at all stages. When adopting Agile principles, one of the hardest things to do is change the team mentality to that of a cross-functional team. Teams like these are a cornerstone of Agility, but their use is downplayed in the operation of Kanban – for better or worse. Having a cross-functional team has great benefits; however, if your team needs to take baby steps towards Agile, Kanban is a great place to start. It doesn’t directly prescribe a team structure and its simple representation of workflow functions well with both silo-based and cross-functional teams.
A Team That Wants to Do Agile-light Without Doing Agile-wrong
As much as I love Agile, it’s fickle when it comes to half-measures in that it often starts to crumble if you only dip your toe in. When a team is hesitant to do full Agile but wants to get a taste of it, Kanban is a great way to go. It’s simple to start with and easy to buy into so that a skeptical team can adopt the whole process without any half-measures. No matter the team, I’d always recommend full Kanban over only part of another Agile method.
The bottom line: If your team has the capacity to work on its process despite some apprehensions of practicing Agile, chances are Kanban will be a good route to take.
Getting Your Development Team Started with Kanban
Kanban – though simple on the surface – is hard to appreciate fully in a single article. I highly recommend looking around the web for different descriptions of Kanban at different depths. Here are a few links to start you off on your journey:
Is Kanban Right for You?
That’s Kanban, from its mechanical beginnings as a manufacturing process to a well-recognized process for managing software development. Like any system, it has its flaws, but it is hands down a useful tool to have at the ready when processes start to break down, or bottlenecks appear.
Kanban is as easy as laying out your workflow on a board (physical or virtual), moving cards through each step, and observing the process. Keep an eye open for bottlenecks, address issues as they pop up, and before you know it, you’ll be on the path to effectively using this framework.
When you get back to work, look for where it might help to visualize tasks or improve your workflow and start applying Kanban!