How *do* you do Scrumban?

In a recent post on a technical forum, a Dev manager had the question (paraphrased here) – My organization wants to operate in a Kanban way but maintain the structure of sprints and burn down charts to keep track of progress. Is it ok to do? Is Scrumban the correct methodology? If so, what is the best way to implement it?

This is a fairly common question a lot of Agile teams that are starting to look at Kanban have. You are a Scrum team with well established Scrum tools and practices. How exactly do you get started with Kanban? Is what you end up doing known as Scrumban? Implicit in these questions perhaps is the worry – will my Scrum practices and results get diluted or vitiated in some way?

I was happy to respond to the questioner and it seemed to work well for them!

What is Scrumban?

In the simplest level, Scrumban is just the application of the principles of the Kanban method on top of your Scrum processes. Kanban, as clarified by David Anderson in his famous Kanban Blue Book, is not a software development or project management methodology. It is a method to visualize and improve what you currently do. If you currently do Scrum, you can still use Kanban to visualize your work and improve your delivery of products. Often, teams who do this call the resulting changed/ improved process Scrumban.

Kanban’s fundamental principles are:

• Visualize your current process
• Implement WIP Limits and the Pull method; and
• Improve Flow by addressing any process bottlenecks and evolve gradually

So, in the words of the questioner, the fact that the team wants to retain the tenets of Scrum and “work in a Kanban way” is a perfectly good place to start.

Visualize your current process

Start by defining the Kanban board that visualizes the process your Scrum team currently uses to develop, test and deliver/ deploy the user stories. Instead of just the Ready-Doing-Done board, expand the Doing column into each step the user story goes through.

Here, it is useful to note that many teams only visualize the tasks within each User Story on the Scrum Board, not the User Stories. With Tasks, it is easier to just use the Ready – Doing – Done structure for the Task Board. However, with Kanban, you get the opportunity to visualize the User Stories in a Scrum Storyboard – which could be a higher level Swim Lane on the same Kanban board, where you can define the detailed engineering process that a user story goes through.

By doing this, you can fully visualize the journey of each user story as it goes from one stage to the next, and start to study process anomalies much more effectively.

Your Kanban Board might look like the one below – of course, you’d model your actual process on the board –

The main swim lane tracks your user stories. As mentioned earlier, this lane is the one that visualizes the actual process that your user stories go through – and will help you identify bottlenecks or problem areas where your stories tend to slow down and pile up due to reasons such as hand-off delays, external dependencies (waiting for a customer confirmation, or an infra team to complete some provisioning task), etc.

You can have a separate lane to track the tasks associated with each user story – though that is optional. Once you get used to the User Story level management of work as the story goes through each stage of the dev process, you might find the tasks to be redundant.

Define WIP Limits

Once you get used to new visualization of the Kanban Board, you can implement WIP Limits on each stage/ step – to reflect the maximum amount of work that should be there in each step at a time. Kanban reinforces the principle of reducing multi-tasking and finishing what you’ve already started before taking up anything new. (Stop Starting. Start Finishing!).

How do you define WIP Limits? Initially, you might start with no WIP Limits. Once you have observed what the typical flow of work is, you can decide how much WIP Limit should be specified per stage of the workflow. WIP Limits are shown as numbers on each stage, as in the picture below:

The famous Don Reinertsen gave the formula of defining WIP Limit to be twice the average work-in-progress that you initially observe. Most teams typically define WIP Limits equal to 1-2 times the number of people working in each stage of the workflow.

WIP Limits work like constraints in a channel through which work is flowing, similar to the banks of a canal. Without the well-defined banks (constraints), water will tend to spread and stagnate instead of flowing in the desired direction. Similarly, WIP Limits ensure that work already initiated flows through to the end of the value stream before new work is pulled in to the channel. Once work is pulled in, WIP Limits help you ensure that it keeps moving forward.

Defining WIP Limits and the importance of WIP Limits has been dealt with in earlier blog posts as well.

Address Bottlenecks/ Improve Flow

As your team starts to observe flow and evaluate the stages where work is getting blocked, you will automatically be able to discuss these in your team meetings and address the problems being faced. Solutions might range from adjusting WIP Limits in earlier stages to regulate flow better, defining explicit policies (a key Kanban principle) to handle work that is getting held up in a prioritized manner (such as document and code reviews), adjusting resource assignments and so on.

The other aspect of doing so is to encourage implementation of Pull in the real sense. Most teams and people have a hard time saying ‘No’ to additional work. Defining WIP Limits gives them a tool to do it more effectively, since WIP Limits are jointly defined and determined by all stakeholders – and provide an explicit contract to both sides that no stage of the work will be overburdened. Teams can say No more effectively or at least ask their customer to take out something else if pushing some new work at them. This can have an almost magical effect on how new “urgent” work stops getting pushed at the delivery team!

Moving from Scrum → Scrumban (→Kanban?)

There is no prescribed “best way” to move from Scrum to Scrumban or Kanban, nor is it desirable to get into such semantics. You can continue to just do Scrum, with the added features of Kanban to help you manage work better and to improve. You are free to call the resulting improved process – that has been completely tailored to your (team’s) needs what you want!

As you start introducing Kanban in your team, you should continue to use various aspects of Scrum such as the 2 or 3-week Sprint time buckets, metrics such as burndown or velocity charts and other Scrum-related ceremonies that are working well for your team especially the Daily Standup and the Retrospectives.

At least initially, nothing needs to change in terms of your Release and Sprint Planning. As you use Kanban effectively, especially WIP Limits and other concepts such as defining explicit policies, using Classes of Service for prioritizing work and committing to SLAs, you might decide to make changes to your overall process that could include dropping some Scrum related concepts such as the time buckets of 2 or 3 weeks, estimation, etc. as Kanban will help you deploy more continuously and give you the ability to make forecasts of what you can complete in each amount of time.

You may also choose to adopt additional Kanban metrics such as the Cumulative Flow Diagram, Lead Time and Flow Efficiency while dropping the Burndown chart since you might no longer be doing estimation or tracking hours. In fact, the Scrum community itself is no longer emphasizing effort estimation as being necessary for Scrum.

To learn more about Scrumban, you can look here – What is Scrumban? â€“ which provides some more details and references other experts on the topic of Scrumban, such as Core Ladas and others, that you might enjoy.

Hope this helps. If you need more help on how to implement Scrumban, you can reach out to us - we would be happy to help!

This article was originally published on my company's blog here.