Using Kanban in Software Development

If you’re looking to get started with applying a project management methodology to your workflow, Kanban might be just what you need. It’s relatively easy to get started with and the core practices can be applied one at a time as your team needs them, making it a great option for teams hoping to provide a bit more structure to their project management.

When you’re developing a piece of software, it’s essential to manage the overall project well to ensure that all the members of your team are on the same page and that the project keeps moving forward. Traditionally, project management has taken what is known as a waterfall approach. This means that work flows from one phase to another, with any changes requiring a restart of this flow. However, in recent years, an “agile” approach to project management has become much more popular. In contrast to the waterfall model, agile project management is “an iterative approach to managing software development projects that focuses on continuous releases and incorporating customer feedback with every iteration.”

Under the umbrella of agile project management, a few methodologies have taken shape:

• Scrum is a methodology where an individual called a Scrum master manages the flow of work, dividing it into sprints of consistent units of work to be completed by the Scrum team. After each sprint, the previous sprint is evaluated, and learnings are taken into account to adjust for the next sprint.
• Kanban is a methodology that focuses on visualizing the flow of work, managing this flow, and helping the entire team work together while limiting the amount of work in progress to ensure everyone is working efficiently. This is the methodology that will receive the focus of this article.
• Extreme Programming (XP) is a methodology that focuses most specifically on the development practices of the team completing the work. XP is best suited for small, co-located development teams where the technology being used allows for automated testing.

In this article, you’ll learn more about the Kanban methodology and see how it can help your team manage the software development lifecycle more efficiently.

What Is Kanban?

The Kanban methodology was first developed and used on a large scale in the 1940s when the Japanese car maker Toyota started using it to track and manage their workflow. By assigning tasks and products that were in progress to cards and only allowing team members to perform work that was attached to the cards in front of them, the Kanban system helped them to make their workflow more efficient and ensure that less time and materials were wasted throughout the entire manufacturing process.

Image courtesy of Atlassian

It wasn’t until the early 2000s, with the rise of Agile programming, that the Kanban method began to be used in the software development world. Because the Kanban methodology focuses on the flow of work through a system, the same principles that made it useful in manufacturing can be transferred over to a software development process as well. Some of the core Kanban practices—visualizing the flow of work, limiting the amount of work in progress, and implementing feedback loops, among others—are particularly useful in software development. Because of this, software teams around the world began adopting Kanban as a methodology for running their projects, and it is still widely popular today.

Kanban operates on four principles: (1) start with what you do now; (2) agree to go after incremental change; (3) respect the current process; and (4) encourage acts of leadership at all levels of the organization. These four principles make Kanban an approachable process that allows teams to get started right away and scale up gradually over time, with input from the entire team.

In contrast to many other agile programming methodologies, some teams find Kanban easier to get started with while still being able to realize some of the same benefits around process management. Kanban focuses on the speed of delivery of work and of delivering tasks as soon as they’re completed rather than waiting for the conclusion of a sprint. Also, because the focus is always on the next highest priority card, streams of work can be reprioritized in real-time while still allowing all the various stakeholders and team members to view the current progress and status of work at a glance. However, some teams like and need the more rigid process of some of the other methodologies. For example, engineering-focused teams might benefit more from the principles of XP, especially if they need more guidance on the engineering side of things.

Many teams have found that the principles of Kanban give them all the benefits of having a structured methodology while making it easy to get started, even if they haven’t used a particular system of project management before. Let’s take a closer look at what Kanban is all about.

The Core Practices of Kanban

As with most systems, Kanban is defined by a set of core practices that help teams structure their workflow:

Visualize the Flow of Work

One of the most important principles of Kanban revolves around visualizing the flow of work. In teams without a project management system or plan, it’s oftentimes not clear how the work flows. And when the flow of work is unclear, it can be equally unclear where bottlenecks are happening or how the process could be made more efficient.

However, with Kanban, the process starts with visualization. The cards representing each piece of work can be moved from one stage to another. This is crucial to the process because it allows everyone on the team to know the current status of the work, as opposed to this knowledge being stuck only inside the head of the person completing the work.

This initial step of determining how work flows through a system can yield insights into potential efficiencies even without implementing all the other practices of Kanban that will be discussed below. Because visualizing the flow of work in a previously opaque system can bring such impressive productivity gains, it’s an important practice to implement first. Sometimes these cards are divided into swimlanes—horizontal lanes on your board that help you to subdivide relevant groupings of work even further. Additionally, color-coding cards or applying labels allows everyone to be able to quickly see how work is grouped together.

Limit WIP (Work in Progress)

One of the bottlenecks of many existing project management systems is that each member of the team has a ton of work that’s considered “in progress.” Because of this, team members are constantly jumping back and forth between tasks and not dedicating enough focus to any particular task. This essentially ensures that there’s always chaos and misunderstanding surrounding what work is currently getting done. It also makes it difficult to plan for future availability and the completion of future work. However, by limiting the number of tasks that can be considered in progress at any given time, the Kanban system ensures that work flows smoothly through the system at all times and ensures that all team members are on the same page about current priorities.

Image courtesy of Mircosoft

A good rule of thumb for this is to make sure that any given team member has no more than two items in progress at any one time. For example, if you have five team members, you should have no more than ten items in progress at a time. If this means a team member ends up with extra bandwidth because of this restriction, they have the freedom to help other team members with tasks they might be stuck on. By limiting the WIP and reallocating extra bandwidth to help on some of the other in-progress tasks, you ensure that the most important work gets completed first.

Manage Flow

Once the first two practices have been accomplished, it’s important that you continue to manage the flow of work. This could mean anything from modifying the steps in your workflow to make it more efficient to changing your work-in-progress limits given the size and speed of the team. It could also mean using your new system to identify bottlenecks and finding a way to improve them. Specific applications will vary, but the goal of this principle is that the Kanban system you’ve put in place continues to get better as you execute on it.

For example, you might notice that even once you’ve set up your flow, tasks still aren’t moving through the system fast enough—you might still have too much work in progress. Experimenting with lowering your work-in-progress limit to see if it can focus the team and start to help work flow faster could be a good first step to take.

Make Process Policies Explicit

Once the process is defined, it’s important to make the policies around the process explicit. Without explicit policies, even the most well-defined system can fall into disarray over time. To ensure that everyone on the team is on the same page, you’ll want to clearly specify things like how bugs are prioritized against existing planned work, who can move cards throughout the process, how work gets assigned, and so on.

Implement Feedback Loops

Feedback loops are very important to the Kanban methodology, both in terms of evaluating the work that you’re doing as well as evaluating the Kanban process itself. Getting feedback on completed work ensures that future work that moves through the system will be even better and more efficient.

Feedback loops, for example, might involve a regular retrospective with the team. This would surface questions regarding how everyone feels the day-to-day work is going, whether they feel the process is too burdensome, and most importantly, if they can (and should) include input from end-users or the customer support team. Feedback loops are critical in determining whether the process is really working, especially if there’s work that is being recycled through the system because it doesn’t meet a quality standard or doesn’t work well. All the process efficiency in the world doesn’t matter if the work output is not up to standard, and if that’s the case, adjustments need to be made.

Improve Collaboratively, Evolve Experimentally

Because everyone on the team will have a different perspective on the process, it’s important to make improvements collaboratively. Even though Kanban doesn’t have scheduled retrospectives like Scrum or other methodologies, it’s still important to evaluate how the process is working as a group and take everyone’s suggestions as to how the process might be improved.

Then, as suggestions are made, consider evolving the process according to these suggestions experimentally—give a potential improvement a try and see if it actually does improve the process or the flow of work over a given time period. If it does, update your process policies to reflect this change.

Wrapping Up

If you’re just looking to get started with using a project management system or applying a project management methodology to your workflow, Kanban software development might be just what you need. It’s relatively easy to get started with, and the core practices can be applied one at a time as your team needs them, making it a great option for teams hoping to provide a bit more structure to their project management.

To make Kanban work within your organization, communication is crucial. Making sure your team is on the same page through every step of the process is the best way to ensure that it works for you. Using a tool like Status Hero can help you to keep track of who is working on what and replace lengthy meetings with succinct online updates, allowing you to implement the Kanban process faster and even more efficiently within your team—especially if your team is remote.

With tons of integrations with other tools your team is already using, Status Hero is the easiest way to make sure your team is on the same page, especially when implementing something new like Kanban in software development.

Status Hero, paired with a software development methodology like Kanban, will completely change the way your team builds software, and you’ll wonder how you ever did it any other way.

By Keanan Koppenhaver. Keanan is the CTO at Alpha Particle where he helps publishers modernize their technology platforms and build their developer teams.