How Kanban Will Help Your Engineering Team Stay on Track

A few years ago, I found myself facing a good problem: the team of software developers I manage–and the internal proprietary software system we’ve developed–had grown to the point that we clearly needed a bug tracking system to help us with productivity and workflow.

I turned to a popular open source system, Bugzilla, but quickly realized that I needed something more sophisticated. In addition to tracking bugs, we needed a way to prioritize tasks, identify who was working on what, determine how long things were taking, and what was preventing tasks from being completed.

I knew we couldn’t be the first development team to have these problems and didn’t need to reinvent the wheel. This is when a search for proprietary bug-tracking software led me to the world of agile software development.

Agile Software Development

Without realizing it, our cross-functional team had already gravitated towards an agile approach, which emphasizes:

• Self-organization
• Collaboration
• Flexibility
• Adaptation
• Rapid response

Agile software development promises to address the sorts of issues we run into as a team: changing user requirements, evolving time constraints, and uncertainty in user satisfaction.

Two common frameworks in agile software development, Scrum and Kanban, both seemed equally valid, but certain aspects to kanban appealed to more to me both on professional and intuitive levels.

What is Kanban?

kan + ban

(visual) + (card)

Kanban, which translates in Japanese to “billboard,” is a visual approach to tracking work as it moves through a process.

It started with Toyota in the 1940’s when a shop-floor supervisor, Taiichi Ohno, identified a need to track and manage the process of putting an automobile together on an assembly line.

Ohno eventually became the founder of the Toyota Production System, known for its efficiency in productivity by minimizing waste. In his kanban model framework, line workers moved a literal card across columns to signal to team members that a task was completed and ready for the next step. When there was a bottleneck in the pipeline, it was immediately visible to the team. Instead of waiting around, team members jumped in to keep things moving.

Kanban helps you answer the question:

How can I optimize my team so that the requests coming in are getting through the pipeline?

The most simple setup for a kanban board can be defined by three categories:

One of the things I immediately found appealing about kanban is its visual approach to project management. Like 65% of the population, I’m a visual learner– even those who aren’t still process visuals 60,000 times faster than text, according to research complied by 3M (the company behind Post-it).

It helps me to get the “to-do” list out of my head and onto a board I can look at. Because software development is inherently “knowledge work,” it’s essentially invisible. Kanban allows teams to visualize the knowledge work that otherwise exists in our minds.

While the manufacturers at Toyota looked at a literal, physical board, our remote team uses a virtual kanban board on Jira.This allows the team to have shared access to the board and, for a bunch of people who spend most of their work time in front of screens, it was the easiest format to integrate.

Benefits of kanban

The most helpful thing about visualizing the work process, as the Toyota line workers discovered, is that bottlenecks become obvious. An agile team includes members who specialize in one area of development but can adapt and jump in when a project is stuck in another area. Using our digital kanban board as a collaborative group, team members can shift from a productive area to a bottleneck, where the team is getting stuck.  

A key for managers using kanban is to establish with your team that once a task is in the pipeline, it won’t get pulled.

Developers work best when they can achieve a state of flow and hate it when they are pulled off a task without getting to see it through completion. You get a loss in efficiency when you determine a task needs to be done in five days, get developers working on it, and pull them off during day three to change to something else.

Because tasks get through quickly with the kanban method, managers can change priorities and shuffle the order in which tasks go through the pipeline without interrupting developers. Developers, then, get the satisfaction of knowing the tasks they are assigned to will be seen through to completion.

Who will kanban work for?

Kanban will work best for cross-functional teams who have…

• Evolving user/customer requests
• The ability to deliver software iteratively
• Management who is open to changing the development process

Get the most out of kanban by ensuring you have…

• A leader who will continually re-prioritize the line-up of pending tasks without interrupting those already in the pipeline
• Daily stand-up meetings (or shared-screens) in order to visualize the work (this is how a team becomes self-organizing)
• Achievable WIP (work-in-progress) limits: there should be a limited number of tasks in progress at any given time, with no new tasks being started until the WIP is completed

Like implementing any change, when you first transition your team to the kanban method, expect some slow-down and delays as everyone adjusts. Some of my developers were enthusiastic about the new method, some were neutral, and some were completely uninterested.

While some individuals on a cross-functional team might believe it’s a waste of time for them to participate in the kanban efforts of tracking tasks and participating in stand-ups, remind them that the group will move faster in the long run. Kanban honors each team member’s time, skills, and talents equally, reminding your team that the whole is greater than the sum of its parts.