3 Departments that Could Benefit from Kanban

Nearly everything we hear and read about agile processes these days focuses on the software development process. This makes sense for several reasons, not the least of which is the simple fact that development is where agile has lived longest.

But agile and lean methodologies have actually been proven effective in many different environments outside of software development.

Kanban, for example, actually became widely used as a means of managing work flow in a manufacturing setting, specifically in the Toyota factories in Japan in the 1950s. The principles developed and perfected in the manufacturing world have now been successfully adapted to numerous different industries and circumstances.

Why Use Kanban Instead of Scrum?

Scrum is arguably the most popular agile methodology in use today, and it does have some similarities to Kanban. There are several key differences between Scrum and Kanban as well. When determining which of the two is better for a particular team or circumstance, a number of factors need to be considered.

• Flexibility: If the work flow would benefit from added flexibility and/or the type of work being handled is difficult to accurately estimate before beginning, Kanban’s more adaptable framework may work better.

• Scheduling: If scheduling is tightly controlled and it’s vital that work be finished by a given time every time to meet business goals, Scrum’s more structured sprint schedule may be the best choice.

• Team size/collaboration: If the bulk of work on any given project is handled by one team, and especially if that team is co-located, Scrum works well to allow everyone to visualize the current sprint’s work and collaborate appropriately. Kanban does the same, but in a more flexible way that can work well for multiple teams and even teams that are not co-located (assuming the technology used to collaborate is up to the challenge).

There are more factors to consider as well, but the real key is to understand that Scrum and Kanban each have their own pros and cons. There really is no absolutely right answer for any given team or organization. Often the best option is a hybrid combination of the two that maximizes the best aspects of each. This is a matter of experimentation and optimization that each team must handle on its own.

To help illustrate these differences and how they can be analyzed, let’s take a quick look at the classic agile use case: a software development firm. Automatically, Scrum is the obvious choice for an agile framework to be used in software development. But, below are reasons why three departments in this organization may be better off going with a Kanban-style solution or creating a hybrid.

The Development Team

If the dev team’s work is fairly straightforward and uncomplicated, the structure of Scrum may just be overkill. They may not need to have the set roles of Product Owner and Scrum Master, or the need for daily standups, sprint retrospectives, planning meetings, or any of the other artifacts and ceremonies that go along with Scrum.

They may simply need to visualize what work needs to be done and set some common sense WIP limits that help them keep work moving along at a reasonable pace. That’s Kanban.

Of course, it’s rare for a dev team to have that straightforward of a decision on their hands. More often, a particular project fits the bill and Kanban makes sense for that. Or, certain aspects of the Kanban methodology – like WIP limits and how the flow is visualized – make sense, but only in conjunction with a more structured sprint iteration and a daily standup.

Either way, the team needs to understand the value of various processes and pick the very best option for the current circumstances.

The Operations Team

Unlike Development, the Operations team will often find Kanban’s more flexible framework to be the optimal choice. Operations tends to have a large number of interruptive projects popping up throughout the day or week, each with its own prioritization level and expected completion date.

A Scrum arrangement is largely based on estimated work and a set sprint length as decided by the team. Stories popping up all over the place play havoc with this. A Kanban setup offers more flexibility for interruptions without creating bottlenecks or failed sprints, even though estimation and prioritization remain key.

By planning out a week in advance (perhaps on a Monday morning), an Ops team can review the current Kanban board and determine what can reasonably be pulled from the backlog to get attention. But, if something new of importance pops up, that item can simply be inserted into a WIP column as soon as space is available – rather than waiting for the next sprint.

This allows the Ops team to be more responsive to technical issues that affect end users or to major bugs that suddenly come to light.

Of course, if the organization has implemented some level of DevOps, this may make it possible and more appropriate for both Development and Operations to function using the same methodology.

The QA Team

With the Quality Assurance team relying on work completed by the Development and Operations teams, and those two teams likely running on difference cadences and releasing work from different projects at different times, it’s hard to imagine a QA team working at its most efficient within the structured Scrum framework.

A Kanban process, on the other hand, makes perfect sense for QA as their backlog and priorities are continually filled by the other two teams. Maintaining a constant flow of work as efficiently as possible allows the QA team to slide through changing priorities and various projects without unnecessary slowdowns.

For more information on Scrum and Kanban, and for help deciding which would work best in your unique circumstances, we recommend the excellent webinar, “A Peek Inside Scrum and Kanban.”