You may have heard it as the cool new hip thing. Maybe it was your friend who said, “Yeah, we’re using scrumban now. Its nothing like scrum.” Well in that case let’s get to know what’s going on with this ‘new’ thing and if it’s really useful for your team.

What is it?

Scrumban literally is a mix of Scrum + Kanban. Kanban is a principle deviced by Toyota in the 70’s as a part of their Lean manufacturing and Just-In-Time Manufacturing which made Japanese car industries one of the world leaders in car manufacturing. Kanban is basically process improvement. Mix that with the product delivery focus of Scrum and you’ve got one hell of a tool.

With Kanban boards in Jira and Trello as a modified ‘kanban’ board, you might have encountered Kanban before.

But what exactly is Kanban?

It’s a visualization system to see how the work is flowing through a process. This allows us to identify the bottlenecks in the process to speed up production.

Its usually as simple as placing cards into 3-4 rows:

• Backlog (Optional if not needed)
• To Do
• Ongoing
• Done

The secret lies in managing the flow and limiting WIP(Work in Progress). When you limit WIP, you try to encourage your team to finish the work at hand before ‘pulling’ new work. You can set hard limits of how many WIP’s are currently ongoing at a point of time. When you manage the flow, you observe where the work is getting piled up. Is it in pulling more work before its done? Is it in pulling too little? If needed you can redefine your Done/Done/Done Criteria.

Why do I need it?

Well, when teams start to run into process related problems that have a hidden root cause maybe you need Kanban. Did you ever run into:

• The right person isn’t the product owner.
• The product owner isn’t doing a good job managing requests.
• We are using scrum but the team is taking longer to develop things.
• Managers need to go directly to the developer.
• Product owner isn’t helping/choking our flow.

Okay, maybe you need it if you encountered these situations.

Okay, how would I use it?

As summarized in ‘Kanban and Scrum: Making the Most of Both’:

“What we’ve come to realize about Kanban is that it is an approach to change management. It isn’t a software development or project management lifecycle or process. Kanban is an approach to introducing change to an existing software development lifecycle or project management methodology. The principle of Kanban is that you start with whatever you are doing now. You understand your current process by mapping the value stream and then you agree to WIP limits for each stage in that process. You then start to flow work through the system by pulling it when kanban signals are generated.”

This means:

• Start with what the team does now: Stick to the existing processes
• What is the current process: Map your value stream, and see what is taking time and what isn’t. Most often we have misconceptions on what takes the most time and what doesn’t. Use hard data to back up the truth.
• Work In Progress limit setting: Kanban is designed to work through
• Pull system based on kanban signals: Understand when new work needs to be pulled and see if any bottlenecks are being created

Closing Thoughts

Don’t force it on your team if its not needed, yet Scrumban can be a powerful tool in conditions right for it. Hope this article helped you decide if you needed scrumban!