Scrumban – Blending Agile, Scrum and Kanban into a methodology that works for you

Since the original publication of the Agile manifesto in 2001, the most commonly used Agile methodology has been Scrum. In more recent years, Kanban, which originated from Taiichi Ohno’s publications back in 1988, has also been embraced as an Agile methodology after the fact because it does follow the Agile manifesto. Both Scrum and Kanban provide a framework for delivering value, but they have clear differences. Combining Scrum and Kanban into what is now referred to as Scrumban is possible, but there is not one single way of doing Scrumban. We will also illustrate the variations of Scrumban so that anyone can figure out which approach is best for their needs.

Agile (4 values, 12 principles)

The details of the Manifesto for Agile Software Development can be found at agilemanifesto.org. The beauty of this manifesto is that it provides just enough direction but permits anyone to choose their ideal trajectory.

To be Agile is to follow these 4 values and 12 principles, but there are many Agile methodologies that embrace this manifesto. Ultimately, focusing on creating value for customers and promoting healthy human behaviors are the secrets to a successful Agile adoption.

Before we can understand Scrumban as a hybrid of Scrum and Kanban, we need to understand its roots within both Scrum and Kanban. (see below)

Scrum (1 framework composed of 5 events, 3 roles, 3 artifacts)

My favorite expression about Scrum is that “it’s easy to implement, but very difficult to get good at”. It’s a simple framework made of 3 roles (Product Owner, Scrum Master, Development Team), 5 events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) and 3 artifacts (Product Backlog, Sprint Backlog, Product Increment).

The flow is repeated on a set cycle (sprint), which can have a duration between 1 to 4 weeks. To learn more about Scrum, please read the official The Scrum Guide™.

Kanban (5 properties, 4 principles)

Here is Kanban explained in 100 words from our other blog, “Kanban explained in 100 words to improve both your business and personal life”:

A Kanban is a card containing details to complete a request within a clearly defined process represented on a board. The most basic Kanban board can be represented with the following 3 columns: To Do, In Progress, and Done.

The cards flow through this board to visualize the status of each card in the overall process. Each column has explicit agreements to ensure the card has completed each step expected in the process. Once the card reaches the last column, the content of the card is 100% ready for delivery or flows to another board to continue the process until completion.

The 5 Properties below are essential to ensure that you are getting the full benefit of Kanban:

1. Visualize the workflow.
2. Limit Work-In-Progress (WIP).
3. Measure and manage the flow.
4. Make process policies explicit.
5. Improve collaboratively using models and empirical evidence.

The 4 Principles are very helpful to help get started with Kanban:

1. Start with what you do now.
2. Agree to pursue incremental, evolutionary change.
3. Respect the current process, roles, responsibilities, and titles.
4. Encourage acts of leadership at all levels.

To learn more about Kanban, read our blog “Doing, Being and Flowing in Kanban (5P/3M)”, but for the purposes of this article, we will explain the 5 Kanban properties under the Scrumban section below.

Scrumban

So what is Scrumban? Well, there is no official definition, and there should not be. Just like Scrum teams often blend engineering practices from eXtreme Programming (XP) into their Scrum framework, there is no exact level of how much XP is needed to be Scrum/XP. Blending Kanban into Scrum (or vis versa) is just a question of what the team is seeking to improve as a team.

Going from Scrum to Kanban…

In this scenario, the Scrum teams continue to do the 11 elements of Scrum but start to introduce the 5 Kanban properties.

Step 1 – Visualize the workflow by improving your Scrum task board

To get started, a good Scrum team should always visualize their sprint backlog on a task board.

In the early days of Scrum, when we used physical boards for co-located teams, we would set up a board with the same four columns (To Do, In Progress, Verify, Done). To this day, most online tools provide that same standard 4-column board in their Scrum templates. Newsflash…this is a Kanban board!

Moving from Scrum to Kanban usually starts with improving the task board to have more meaningful columns. As we know in Kanban, the first property is to visualize the workflow, and Scrum loves transparency and using information radiators. We have seen many teams simply add or modify their tasks board to provide a better way to flow their work.

Step 2 – Limit Work-In-Progress (WIP) and pull process

Yes, now that the Scrum team understands that they have been using a Kanban board all along, it’s time to also embrace WIP limits. This is a great way to embrace another concept in Scrum, to not pre-assign the work but to let the team self-organize and pull the work during the sprint. By setting WIP limits on the columns of your board, we increase the focus of the team. Only the work that is committed every morning at the Daily Scrum should be in WIP, everything else should stay in the To-Do column.

One of the benefits of having WIP limits in a Scrum team is to prevent anyone on the team from hoarding the tasks that they prefer. This will help team members break out of their comfort zone and break down silos within the team.

Another benefit is my favorite sports analogy in Scrum…I love basketball, and I always ask teams who should take the last shot when there is 1 second left in the game (and your best player is unavailable). The answer is simple…whoever is open.

The best way to embrace this mindset is to flow cards within their WIP limits so that you have a consistent flow of work, and on the last day of your sprint, your team members are not waiting for someone else to pick up the work. Whatever work is left on the board should be picked up by… whoever is open.

Over time, teams get very good about cross-training each other to prevent having only one person who can do something (take the last shot).

Step 3 – Measure and manage the flow

As your workflow through your Scrum task board, start measuring how many tasks your team completes every day (throughput) and how long do they generally take on average once someone picks up the task in a sprint (cycle time).

Also, look for columns on your board where tasks stay the longest; this will help you identify any bottlenecks within your team’s process. These bottlenecks can often be resolved by cross-training and/or improving the flow by modifying the board and WIP limits.

Step 4 – Make process policies explicit

This is another easy one to implement…Most Scrum teams invest in creating a Definition of Done so that teams know what it means for a task, story, sprint or releasable feature to be 100% Done.

In Kanban, we must make the process explicit so that the team easily knows when it’s appropriate to move a card from one column to the next. This is like writing a Definition of Done for every column of the board. The great benefit of having explicit agreements as a team is the faster time to onboard new team members.

We have also noticed significant improvements in quality when teams clearly list items like complete unit testing, complete code review, doing a shoulder check, etc… These simple reminders within each column will help teams embrace new habits around building quality within the process.

Step 5 – Improve collaboratively using models and empirical evidence (Kaizen)

The spirit of continuous improvement (Kaizen) should be in all teams, but with Kanban, it’s a core property, so it must be clearly in place. In Scrum, we should absolutely continue to do sprint retrospectives as an implicit way to improve as a team, but continuous improvement should not be limited to retrospectives.

Because in Kanban, we only have a board, we are constantly looking at better ways to improve anything related to the board and/or the way work flows through the board. There is always a better way to do something!

This last property is also fully embraced by Scrum, as both methodologies encourage teams to experiment and capture the results as empirical evidence to decide the best course of action.

There are so many ways Scrum teams can benefit from blending Kanban or XP, but please become great at Scrum first before trying to improve it. Scrum works very well when teams respect the framework of the 11 elements. We did not, in any way, suggest stopping following all aspects of Scrum, but instead promoting improving on top of it.

Going from Kanban to Scrum…

In this scenario, a Kanban team is choosing to leverage concepts from Scrum, or a team has done both Scrum and Kanban and is now confirming the best of both worlds for their specific needs.

Timeboxing

The obvious difference between Kanban and Scrum is timeboxing. In Scrum and many iterative Agile methodologies, we create a healthy sense of urgency by inventing timeboxes (ie: 2-week sprints).

This helps teams focus, but the deal is that the timebox (sprint) is set at sprint planning, and it doesn’t change during that time frame. If this rule is often broken, then you should get a new Scrum Master and/or educate your Product Owner about the importance of protecting your sprint.

Kanban teams work on a continuous flow of work that starts and ends when the work clears the WIP columns on the board. Introducing a timebox can help teams and management set short-term goals but would not include a deep sprint planning session.

Instead, we would simply make sure that specific cards are assigned to a queue column based on the throughput of the team. If we know that a team can complete 10 cards per week, then every week, we must make sure that 10 cards are 100% ready for the team to consume that week. This creates a just-in-time backlog of work.

Daily Scrum

This one is simple, every team should do a Daily Scrum. Kanban teams can and should introduce a brief team stand-up session to increase collaboration and cross-leverage knowledge.

If the cards on the Kanban board do not move very often, then the stand-up doesn’t have to be daily. It can be 3 times a week (Monday, Wednesday, Friday) or 2 times a week (Tuesday, Thursday), and worst case, once a week. The format should remain consistent with the 3 questions from Scrum (What did you accomplish? What are you going to accomplish? Any impediments?).

The only caveat is that Kanban teams don’t have Scrum Masters, so that role would not be there to remove impediments for the team. If you do Scrumban, then you will most likely keep your Scrum Master. If you don’t have a Scrum Master, then embrace emerging leaders on your team who love process, and/or have great soft skills.

Sprint Planning, Reviews, and Retrospectives

As mentioned regarding timeboxing, planning would be very light if a Kanban team chose to re-introduce sprint planning. Many Kanban boards include planning in the first WIP columns in the form of names like review, analyze, plan, prioritize, etc… Planning should be part of the entire flow, not a separate activity.

Reviews can easily be brought back by scheduling such a session on a cadence and doing a demo of all the cards that reached the Done column since the last review session. We often see Kanban teams just connect often with the requester during the process of delivering the work and for sure when it reaches the Done column.

Retrospectives are just as great! Although Kanban teams will always be seeking ways to improve, bringing back a scheduled retrospective session will provide a valid outlet for the team to have a dedicated session to talk about improvement opportunities.

Roles

Be aware that in Kanban, we don’t need Scrum Masters or Product Owners, as these are specific roles for Scrum. If you are moving from Kanban to Scrum, you will not necessarily need to create these two Scrum roles. Often Kanban teams have many requesters across the organization related to many different products, so electing a Product Owner for a Kanban team does not always make sense.

If your Kanban team and board are closely tied to a process (not a product), then we have seen Process Owners be identified to help teams have a clear person responsible for making decisions impacting the team’s flow or work. These Process Owners are usually well versed in Lean and Six Sigma, as they are focused on visualizing the value stream and also contributing to improving the process with the team.

So should you do Scrum, Kanban, or Scrumban?

If you are a Scrum team seeking to improve even more, then introducing Kanban or XP concepts in your Scrum team can be very beneficial.

If you are new to Scrum or dislike Scrum, then don’t just call whatever you are doing Kanban. Too many teams call themselves Kanban to get out of doing Scrum. There is an art to doing Kanban, so don’t screw it up.

I strongly believe that it’s critical to empower teams on the road to self-organization, but not to the point of inventing a methodology or only doing what’s comfortable. Please stay away from the “Do Whatever” methodology with 0 principles, structure, or discipline.

In the end, it’s all about improving as a team. Scrum and Kanban can absolutely work as individual methodologies and produce great results. Investing in Scrumban must be a natural progression or a conscious decision to solve a specific problem that your current methodology is not solving.

So much more could be said about Scrumban, but hopefully, this is a good start to help any team considering it. Feel free to download the Scrum vs Kanban online presentation on SlideShare.