Can Scrum and Kanban Coexist?

There is much debate these days over which is better, Scrum or Kanban, but a better question would be how do you use the strengths of both to your advantage? To determine the answer we need to know the common elements of both concepts as well as the differences.

I talk about Scrum in some detail in an earlier entry, but Scrum in a nutshell is a way of breaking down complex problems into simpler solutions. Scrum uses self-organizing teams that make a commitment to stakeholders to create a unit of work that is shippable. Scrum teams are cross-functional and deal in iterations of shippable product.

Kanban is a Just-in-time concept originally developed by Toyota as a way to control production. Kanban is "pull-based" meaning that production is based on current demand and is usually based on a strict set of rules. An example of these rules from Toyota are as follows...

1. Do not send defective products to the subsequent process
2. Subsequent process only takes what it needs
3. Produce only the exact quantity withdrawn
4. Level the production
5. Use Kanban as a means of fine-tuning
6. Stabalize and Rationalize the process

I personally believe that Scrum and Kanban cannot only coexist, but can compliment each other well. For example, when an IT product is requested, Scrum is a good candidate for managing that creation. Use sprints to create shippable product and get customer feedback. Once the product is stable, the backlog tends to shrink, which is where I think Kanban comes in. As new requests are made, they can be handled in a just-in-time way. Dedicating a sprint to a simple feature request defeats the purpose of being agile. My Scrum master instructor mentioned that you don't always have to create a great meal, sometimes you just need to heat up some macaroni and cheese. So, if you're making macaroni, just make macaroni.

To recap, I like both Scrum and Kanban and we tend to use both here successfully. Generally, on larger projects we use Scrum, but that tends to evolve into Kanban over time as the project turns into a mature, finished product. Kanban is used as part of a continuous improvement process with a focus on quality.

A Quick Intro to Scrum

Quick Definition of Scrum

• Scrum is a way to break down complex problems into smaller, more manageable pieces.


• This is done with a self-organizing team that works for an allotted time (a sprint), usually two weeks to deliver a potentially shippable product.


• Contrary to what some believe, the sprint does not deliver partially complete work. The completed work is fully tested and ready to show to stakeholders with any documentation or artifacts.


• At the end of the sprint, a review (sprint retrospective) is held where the process is examined and any recommendations for process improvement are discussed. As the next sprint begins, another chunk of the product is worked on and the cycle repeats itself.

Real Life Scrum Example

My Grandfather was an auto mechanic and my Dad was an auto-mechanic which pretty much made me an auto mechanic growing up. In fact, from the time I could hold a wrench I was working on cars. I didn’t realize it at the time and it didn’t have a name, but we practiced Scrum back then.

Each morning when we arrived at the garage we would get a cup of coffee and all gather together to talk about what we did yesterday, what we were going to do today and any impediments we might have.

Dad: "Need anything on the engine rebuild for Mr. Brown?"
Me: "No, everything is by the book, so far."

Dad: "Alright, I’ll start the brake job while take care of the 2 oil changes."
Me: "I have to get gas in the parts truck, so I'll do that when I drop the rotors off."

Dad: "Sounds good. We can each take a tune-up, break for lunch, then double-team the water pump on the Ford this afternoon."

This was our way of self-organizing and while it wasn't the purest form of Scrum, as a Scrum master I make an effort to relate that experience with software development.


For more information visit http://www.scrumalliance.org/.