Scrum-ban

It's well known, that as far as Kanban audience goes, a lot of it is composed of current Scrum-doers. Therefore it makes great sense to direct the education and information about great Scrum-Kanban hybrids towards them. As well as people completely new to Lean in general. So, whether you're tired of Scrum or intrigued by Kanban, read about Scrumban to possibly get closer to finding your perfect tool.

Index cards and boards

Lean methods have long been associated with task boards, and quite early on there had been remarks assigning a similarity between those boards and industrial Kanban systems. Probably the greatest advantage of having a board in the work room is the transparency you get from having the process in front of everybody's eyes. Second most valued property, according to Corey, is the ease of applying any changes to the workflow, achieved by the board's flexibility. As for a board's disadvantages, Corey makes an observation, that having the visual aid itself doesn't help so much yet. You are still able to pile up lots of items on it and get flooded with uncompleted tasks.

Kanban board

Corey provides an insightful analogy between what Kanban does for a development (or any other) process and what currency does for economy. In the end, just as an currency supply is about the control of the economy, Kanban is about workflow control. A simple means to a desired end. Therefore, a task board that applies no WIP limits is not a Kanban board at all. A real Kanban board controls the workflow by doing two things: limiting the number of items in progress and producing an environment, in which it's possible to make a request for something specific and be sure to achieve it.

Pull method

Typically associated with Kanban, requires a little bit more than just having a backlog of items. As long as you remain within time-boxed iterations, meaning that specific items still need to be done by certain date, you're not facilitating pull. Having a well cut-out process, with WIP limits adjusted to the real capabilities and a backlog of size-controlled items, allows the team to be actually able to pull work as and when they're ready for it. Now, should you need to stay within timed iterations, you can still achieve a pull system by setting a due date on the entire backlog, can't you? All items equal in priority, the team decides and picks their work as they go. This, therefore is probably Scrumban now.

Flow

Once the system is set, you're ready to define the process stages a bit more precisely. Make sure it reflects the actual process steps one by one, henceforth allowing you to monitor the overall condition of the team and possibly be able to make some adjustments where necessary. It's also the right time to begin monitoring the whole system via cumulative flow or lead and cycle time diagrams, depending on what matters more.

Improvements

As soon as the team has gotten well used to the system, and the monitoring capabilities are being utilized to the full, you should be ready to begin observations of any opportunities for improvement. Keeping track of the changes in the cumulative flow over a few months in particular can be indicative of any under-achievements or weaknesses.

Planning

In keeping with the iterative nature of Scrum, but taking note of the need to adjust to Kanban, the best way to plan the work ahead is by setting a limit to how many items can go in the backlog. Since now you have some idea on the team's capacity (workflow analysis) you don't need to make estimations, all you need to do is think of how many and which items the team needs to focus on during this iteration, and place them in the backlog, ready for them to pull.

Advice for Scrumban kick-starters

In Corey's experience, the biggest step that you need to make to move on from an ineffective Scrum is decoupling of planning and release. They shouldn't overlap and definitely don't need to be tight together. All that the planning team needs to provide for the developers is the best thing to pick up next, they don't even need to be concerned by when it will be released. Any other planning can be considered waste, since brings no value to anyone.

Further perfection of the process

If Corey was to state the next thing to improve in that process, it would be setting a notification mechanism for letting the planning team know when the developers are starting to run low on the backlog of items to pull. At this point he still defined their process as basic, indicating that there is still a lot more to be achieved (by addition of swimlanes, structural dependencies and more). We can see from this, that it's easy enough to start a Scrumban system, and the benefits and growth capabilities are large enough to be intriguing.

Read our article on Scrumban »