We know Scrum and Kanban as flavors of Agile. Scrum is best-suited for products and development projects. Kanban is best for production support. We use Scrumban – which combines the best features of both – for maintenance projects. Scrumban is becoming very popular these days in service industries, where we have both development and maintenance projects.
Scrum in a nutshell:
- Split your organization into small, cross-functional, self-organizing teams.
- Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
- Split time into short fixed-length iterations (usually 1–4 weeks), with potentially shippable code demonstrated after each iteration.
- Based on insights gained by inspecting the release after each iteration, optimize the release plan and update priorities in collaboration with the customer.
- Optimize the process by having a retrospective after each iteration.
Kanban in a nutshell:
- Visualize the workflow
- Split the work into pieces, write each item on a card, and put it on the wall.
- Use named columns to illustrate where each item is in the workflow.
- Limit Work In Progress (WIP): Assign explicit limits to how many items may be in progress at each workflow state.
- Measure the lead time (average time to complete one item, sometimes called “cycle time”), and optimize the process to make lead time as small and predictable as possible.
A direct consequence of this difference in rules is the way the work items are handled across time.
In Scrum, you select the work you’ll be doing for the next sprint beforehand. You then lock the sprint, do all the work, and after a couple of weeks – the usual sprint duration – your queue is empty.
In Kanban, all that’s limited is the size of the queues, called the WIP limit. This means that you can change the items in the queues at any time, and that there’s no “sprint end”. The work just keeps flowing.
Scrumban = Scrum + Kanban
- Use the prescriptive nature of Scrum to be Agile.
- Use the process improvement of Kanban to allow the team to continually improve its process.
With the Kanban’s pull system in place, our flow will become smoother as our process capability improves. We can use our inter-process buffers and flow diagrams to show us our process weaknesses and opportunities for kaizen. As we get closer to level production, we will start to become less concerned with burndown and more concerned with cycle time, as one is the effect and the other is the cause. Average lead time and cycle time 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. If cycle time is under control, then burndowns are predictable and uninteresting.
Since the team now pulls work into a small, ready queue before pulling it into WIP, the team’s perspective of the iteration backlog’s utility is that it always contains something that is worth doing next. Therefore, we should use the least wasteful mechanism that will satisfy that simple condition.
A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than going through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation.
In Scrumban, we can do iteration planning at regular intervals, synchronized with review and retrospective, but the goal of planning is to fill the slots available – not fill all of the slots, and certainly not determine the number of slots. This greatly reduces the overhead and ceremony of iteration planning. Time spent batch-processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue. If a work item is ill-formed, then it gets bounced and repeat offenders get a root cause analysis.
- Just-in-time (decisions and facts just when they are needed)
- Short lead time
- Kaizen (continuous improvement)
- Minimizing waste (everything that is not adding value to the customer)
- Process improvement by adding some values of Scrum as and when needed
When to consider Scrumban
- Maintenance projects
- Event-driven work
- Help desk/support
- Hardening/packaging phases
- Projects with frequent and unexpected user stories or programming errors
- Sprint teams focused on new product development
- Work preceding sprint development (backlog, R&D)
- Work following sprint development (system testing, packaging, and deployment)
- If Scrum is challenged by workflow issues, resources and processes
- To manage improvement communities during/after Scrum roll-out
- Avoid creating/analyzing too many stories (requirements/defects) – reduce waste
- Assure the necessary level of analysis before starting development
- The backlog should be event-driven with an order point
- Prioritization-on-demand – the ideal work planning process should always provide the team with best thing to work on next, no more and no less
Scrum vs. Scrumban
Kanban is compatible with Scrum, the project management method. Adding WIP and visualization to Scrum, i.e. Scrumban, helps improve Sprint Commitment effectiveness. However, it is also introduces the WIP limit as a mechanism to catalyze incremental changes. The WIP limit obviates the need for commitment to drive change, reduces any dysfunctional reliance on heroic effort, and improves overall systems thinking when considering potential improvements. It looks somewhat like Scrum at the practice level, but at the cultural level it will look like Kanban – soft evolution rather than shock treatment and revolution.
Scrum vs. Kanban, by Dimitri Ponomareff
Scrumban: Using Kanban to take Scrum outside its comfort zone, from the Israeli Scrum User Group
Combining Scrum with Kanban for support and enhancement teams, from Innovel
Scrum as defined on Wikipedia
So what is ScrumBan?, by Yuval Yeret