Can Kanban and Scrum Ever Really Get Along?

So what do we do? Close the book on any combination of the two? Is each one used in its own separate dish, but never together? If the development team is willing to adopt the role of a gourmet, Kanban and scrum can be blended into a uniquely satisfying dish with a little skill and imagination. Let's take apart the recipe. 

What is Scrum?

Let's do a quick recap of our ingredients so that we understand the range of flavors we're working with.  

Scrum is an agile development process that aims to promote efficiency. The scrum methodology breaks up the development team's workflow into sprints. A sprint is a predetermined amount of time (usually one month) in which the team has to complete a unit of work. That unit of work typically consists of a completed portion of code, i.e. a shipped piece of software. At the end of each sprint, there's a process called the sprint retrospective. A blameless retrospective a group meeting in which the development team, product owner, and scrum master meet to evaluate what went well during the previous sprint, what went poorly, and what the team can do better in the next cycle. 

The sprint is a highly controlled, goal-oriented process with a focus on continual refinement. Quality and efficiency are the heart of the method. 

What is Kanban?

Kanban is another agile development process, albeit with far deeper roots. It can be traced back to Toyota in the late 1940s. If you were to distill Kanban to its essence, it is a highly-visual method of workflow optimization. Kanban itself is a Japanese term for "billboard," or "signboard."  

Kanban is what's known as a just-in-time (JIT) production method. In its initial iteration on Toyota's factory floor, each department would communicate supply needs and other work-critical information using interdepartmental cards passed to the relevant department as necessary. For example, if a stop on the production line was about to run out of necessary materials, they would pass a Kanban on to the warehouse, ordering a precise amount of replacement parts.

In its modern iteration, Kanban serves as a way to map out a team's workflow. It is usually divided into four categories:

• To do
• Work in progress (WIP)
• Review 
• Completed work

Companies that utilize modern Kanban methodology use virtual boards rather than printed cards. These virtual boards are capable of showing an incredible amount of high-value information about each task or unit of work. Using this method, production teams remain adaptable, using a JIT approach to meet changing job demands. 

What Are the Key Differences That Prevent Synchronicity?

Kanban and the sprint are from the same family of spices, but they're hardly the same flavor. There are a few key differences that prevent the two from coexisting in complete harmony. 

First off, the two differ greatly in terms of job roles. In scrum, job roles are well-defined; that set structure is as much a part of the sprint's effectiveness as any other factor. In Kanban, however, job roles are not so clearly defined. There is more freedom, and thus more open collaboration using the Kanban methodology. 

Kanban is also a continual process whereas the sprint is a discrete and finite unit of work. Because the sprint has a set time frame and a rigid goal driving the end result, there is far less adaptability but a high level of efficiency present. With Kanban, all deliverables are produced on an as-needed basis. When the work comes, the team's workflow is engaged. The time constraint isn't as rigid, nor is there as definitive an end point to the process; workflows are constant and responsive to arising needs. 

Sprints are a well-organized process. The scrum master decides what each sprint's goal is before the production cycle begins. Thus, the sprint's purpose is codified, and achieving results becomes a necessity. With scrum, changing a project's direction mid-cycle is impossible. Kanban embraces the opposite ethic; changes can occur at any time during project development. Kanban does not rely on a retrospective for process improvement. Instead, improvement is continuous. 

How does each methodology measure its success? Scrum is like a snowball rolling down a hill. As it goes, it picks up speed and power. Each sprint strengthens the overall process, making the next cycle possible. Kanban, on the other hand, measures success based sheerly on speed. The shorter each development cycle, the higher the level of success attributed to the final product. 

The Value of Integrating Kanban and the Sprint

Kanban and the sprint certainly seem like competing methodologies. Like the chef in our example, is there any way to blend the two flavors to form a complete meal? Can you have your cake and eat it too?

The best advice we have is to be adaptable about your systems of adaptability. Kanban and the sprint will never play nicely together, at least 100% of the time. The two are opposing methodologies at heart, and they employ contrary tactics to arrive at a similar result. To gain the most value from each, your team should look to layer one on top of the other. 

It helps to begin your development process using the stricter of the two methodologies and branch out from there. It can help to focus your project and smart goals by imposing the sprint's strict timeline and definition of the work unit. Once the team becomes fully accustomed to the strictures of the sprint, elements of its rigidity can be taken away, and the Kanban method can be substituted in.

It's like building an engine. Scrum is the fabrication process that gets the machinery up and running, while Kanban is the ongoing maintenance and operation. Or to put it into our cooking metaphor, scrum is like browning the meat in preparation for the creative agility that turns it into an entrée.     

Is being adaptable the same thing as being efficient? Free of context, the two can look strikingly similar. Adaptability and efficiency serve as the core tenets of an agile development process. Like a professional chef hard at work in their kitchen, the goal is to make the two into complementary flavors that enhance the finished product equally. In the world of agile development, Kanban and the sprint retrospective are two such ingredients. By their very nature, however, these two flavors go together about as well as oil and water, or worse yet, orange juice and toothpaste.