There exist a lot of different concepts for agile software development. Scum is one of the most known concepts, which is also very popular and established in a lot of companies. Another concept, often used in software support teams, is Kanban. Scrum as well as Kanban offers a lot of nice best practices, tools, rules and procedures. So what happen if we try to combine these two concepts to get the best of the two worlds?

 
What is ScrumBan

In ScrumBan we applying the Kanban methods to a Scrum context. So you start with Scrum and apply the Kanban thinking to it.

 
When do you need ScrumBan

Let’s say you do Scrum and you deliver working and tested software every sprint. There is a great collaboration and no feeling of wasted time. The retrospectives are done to find impediments and dealing with them. If that is the case, everything looks fine and so I’m not sure whether you need ScrumBan.

But most teams are not there yet. They have problems with their sprints. Features are not implemented, commitments cannot be fulfilled, the software is not necessarily working or tested and the discussion in the retrospective is focused on how to calculate the right velocity, estimation inaccuracies and similar issues. If you are working in or with such a team, ScrumBan can help. It will offer a good chance for changes and can guide your through the improvement journey.

 
Basic principles

ScrumBan is an application of the Kanban Method, so naturally the three basic Kanban principles apply.

1. You start with what you do now.

That is your Scrum. So you start where you are and use everything as you know it from you current scrum process: the sprints, scrum master, sprint backlog, taskboard, sprint burndown and whatever you are currently using.

2. Agree to pursue incremental, evolutionary change

You have to accept that things will change over time. So you might adapt some of the aspects of Scrum, add new practices or drop some. The important thing is that you agree to adapt you process in a way to meet the business goals more effectively.

3. Respect the current process, roles, responsibilities and titles

Again, you start with your actual Scrum process, your organization, roles and your job titles. You might get some ideas for change when you try ScrumBan, but the Kanban Method is about introducing those changes when they make sense, not as a big change up front.

 
Practices

There are five basic Kanban principles. These can all be used to adapt and improve your Scrum process.

1. Visualize the workflow

Scrum teams already visualize the work on the scrum board. But it is not satisfactory to visualize the sprint backlog and the status of the backlog items only. It is important to make the flow of work visible as well, from the early requirement stage to testing and finalizing.

2. Limit WIP

Limit the work in progress by limiting the amount of possible items in each progress step. So you may for example define that there is a limit of three items in the test step. Once a limit is reached, the alternative to starting a new story is to go and help others deal with their story. Limiting WIP introduces pain because the team members may not be able to do what they are comfortable with. By improving the team’s process in the future the flow will get better and the WIP limit will be less painful. Limiting WIP is a great way to drive real collaboration at the team level.

3. Manage Flow

Start looking at the cycle times of stories to find room for improvement. Take care about a healthy flow of work, see struggling stories and find ways to help them along.

4. Make management policies explicit

Many teams have explicit team rules. Now you do the same with the process rules: Make them explicit. This will help the team to know and understand the management policies. This is an important point for improvements. Explicit rules can and will be discussed and the team may think about these rules and how they affect the workflow and the results.

5. Improve collaboratively

Use your retrospectives to improve the process. Now, with ScrumBan, you have a lot more information about your process. By using the above practices you will get many details about the process and you can use these knowledge for improvements of the development process.

 
Possible process adaptations

Above I have introduced the basic principles and practices. Of course these principles and practices will result in very different process adaptations depending on you project, company, environment and so on. At next I will show you some process adaptations which may occur when you use ScrumBan.

In Scrum you have sprints which are fixed working units, starting with planning meetings and finishing with a retrospective and a review. So at the start of each sprint you need time to get the whole machine started, then you can work very focused on the tasks, and at the end of the sprint there is a phase to finish the sprint, clear the table and start over again. In Kanban you are more focused on the flow of the single stories or tasks. By combining these two concepts you can establish sprints which are more in a flow and the meetings at the start and at the end of the sprint are more like a short pit-stop. You can compare the workflow with a car drive. In Scrum, the sprints feel like driving up and down. You start a sprint and have to go up the hill and at the end of the sprint you can drive down the hill and increase your speed. In Kanban it is more like driving on a straight street and have some pit stops from time to time.

This feeling will be reinforced if you adapt your planning meetings to this process. In Kanban you will start your tasks depending on the work in process. Therefore you will do just in time task planning and not an advance planning of all tasks for a sprint. Therefore in a ScrumBan process you may switch to a planning meeting „light“. That means you do a normal planning meeting and discuss the goals of the sprint but you do not discuss every task in detail. This detail discussion is moved to the daily standups and you will speak few minutes about a task as soon as you start to work on it.

Another point which will be changed if you use ScrumBan is the project controlling. As we measure the cycle time and the lead time of tasks, this will become the primary focus of performance. If cycle time is under control and the team capacity is balanced against demand, then lead time will also be under control. And in this case the classical measurement method of scrum, like the burndown charts, will become predictable and uninteresting.

 
Summary

By using Kanban in addition to Scrum, you may evolve your Scrum process to be more flow oriented. Kanban will help you to improve the process and the collaboration between the different team members and sub-teams. You will get some new tools and principles which may help you to lift up your Scrum process to the next Level.