There is no reason for a fight; the Scrum and kanban agile methodologies can be complementary. Scrum provides simple rules imposing consistent inspect and adapt iterations and is the most widely adopted of all agile methodologies. Contrast this with kanban that has few rules: visualize your workflow, limit your work in process, and continually find ways to optimize cycle time. Should you choose between them or find ways to combine them?

Role Definitions

Scrum prescribes a product owner to manage demand, a team to manage end-to-end delivery, and a ScrumMaster to guide the process. This works as long as roles are well understood and appropriately staffed. However, stark differences from existing corporate role definitions can make adoption difficult.

Scrum emphasizes cross-functional behavior. Making activities parallel and highly collaborative can improve development speed and quality. For instance, developers often pair with testers and do testing on their own.

Kanban has no rules about roles at all. Team composition can be dynamic in kanban, but crossfunctional team structures like those in Scrum are often practiced.

Managing Demand and Delivery

Scrum achieves focus through timeboxed sprints, which help teams concentrate and limit multitasking. Unfortunately, this can result in quality tradeoffs and last-minute heroics. Scrum requires a sprint’s worth of work to be planned in advance, while kanban is made to deal with unplanned work. It is easy enough to leave buffers in Scrum while establishing simple rules to deal with unexpected demand. The timeboxed nature of sprints can help control unwanted tendencies like gold plating and scope creep.

Kanban, on the other hand, uses explicit limits for how many items are allowed to be in process at once. These approaches can effectively be used together. For instance, an imbalance in development and testing capacity in a Scrum team might be addressed through different work-in-progress limits for each activity.

Work that flows to different individuals rather than to a team is ideal for kanban, as is work involving repeatable processes commonly used in maintenance and operations projects. However, kanban can handle planned work just as well by requiring process and product review sessions.

Kanban uses classes of service to define rules around different types of work, such as defect resolution versus new development. Measuring these separately can provide more granular delivery speed information than batch velocity measures in Scrum.

Planning and Requirements Management

The product owner manages scope and requirements in Scrum; kanban leaves the job of prioritizing and managing the flow of work to the team as an open-ended proposition. Scrum uses release and sprint planning meetings to identify scope and goals by bringing teams and stakeholders together at regularly scheduled intervals. While Scrum’s sprints set a development cadence, releases are made at the product owner’s request; kanban simply includes them as a final stage in the workflow.

Grooming is the process of getting stories ready for the team to accept as work. In Scrum, preparing a few stories beyond what is likely to fit in a sprint is recommended and can effectively allow for continuous flow of work. In kanban, grooming is necessary but undefined, as wide variation in input size can generate unpredictable delivery times.

In Summary

Scrum and kanban are ideal for different situations, but they can be blended to good effect. Let teams start where they’re most comfortable; then allow flexibility in technique and tool adoption while maintaining reasonable standards around the capture and sharing of information.