How does Scrum differ from Kanban?

Scrum versus Kanban (or is it Agile versus Lean versus Design Thinking?). Or is it why DevOps is impossible if you’re not Agile? Or….? 

Big questions all of them, no doubt – but this one, Part 1, is just about Scrum versus Kanban. We’re calling it Leanscrumbanile Thinking… other similar blogs are likely to follow.

Another blog for people confused by some of the trending business terms du jour, often carelessly used and poorly defined, if at all.

This one was prompted by a marketing professional I know who found herself being asked to prepare material for both Scrum and Kanban, and noticing what looked like a significant overlap.

So, the basics.

Scrum

• Started life as a product development method
• Originated in Japan.
• Pre-dates agile (dates from 1980s).
• Was later called Scrum by a group of American adopters.
• Yes, it’s named after that game-stopping embarrassment in rugby union, when the two forward lines, each organised into three rows, lock together waiting for the scrum-half to put the ball in crooked. Hopefully, your stand-up meetings are nothing like a rugby union scrum (rugby league scrums are more civilised affairs). Reading the original Harvard Business Review about Scrum, it is clear that the authors were far more interested in the team-interplay in rugby (forwards and backs) than they were specifically in the scrum itself.
• Is based on an assumption that the requirements of the customer are likely to change (and are not initially knowable in their entirety).
• Uses iterative and overlapping stages, rather than sequential ones.
• Is lightweight (few rules and procedures).
• Uses small teams (single figures).
• Uses teams that are built around three roles: the product owner (representing the voice of the customer); the scrum master (the facilitator); the developer.
• Breaks work into time-boxed (i.e. limited to a fixed duration) sessions called sprints, usually around two weeks long. The sprint is the central ritual in Scrum, and comes with its own protocols for both planning and execution, including the Sprint Demo at the end of the sprint.
• The other major ritual is the Daily Stand-up meeting, usually about 15 minutes long, a practice that is now copied, often quite unthinkingly, in environments far removed from Scrum and Agile.

Kanban

• Is a scheduling system, used in lean manufacturing.
• Supports just-in-time manufacturing (JIT is a core Lean concept), and seeks to restrict the amount of inventory required by the manufacturing process.
• Is also Japanese, starting its life as part of the Toyota Production System (TPS) that later became known as “Lean”.
• Dates from the 1940s.
• Means “signboard” in Japanese; Kanban cards were used in TPS to send messages from downstream parts of the production/consumption system to upstream parts to indicate a shortage of parts, components etc. This triggers the production of an agreed quantity, which then flows through the system to the required process part. Physical cards have now often been replaced by automated messages, emails etc., although the physical cards still exert a powerful attraction for Lean adherents.
• Is therefore a demand-pull system, rather than a supply-push system – demand triggers production.

How are they similar?

One major similarity is that they are both now used in Agile software development.

• Scrum shares with Agile the principles of short development delivery cycles, and the changing nature of requirements.
• The use of Kanban, particularly in software development, majors on its visual management elements (the Kanban board).

Scrum Boards and Kanban Boards look very similar.

• Kanban boards are governed by a rule on how much work can be at each stage in the process, a rule which does not apply in Scrum.
• Scrum Boards describe the work of a single cross-functional team; Kanban Boards can be used more flexibly.

How are they different?

Kanban is a continuous flow method, whereas Scrum is discontinuous, being based on discrete, time-boxed sprints.

Kanban does not use the roles prescribed by Scrum.

Kanban is oriented around individual items, Scrum around batches.

Kanban is more flexible with respect to changes; Scrum doesn’t allow them within a sprint.

Scrumban….Is it a thing?

It is. Scrumban was introduced in a 2009 book by Corey Ladas. Originally it was designed as a transition path from Scrum to more Lean and Agile software development methods. In fact, it has resulted in a set of hybrid forms; simplistically, these forms tend to use Scrum to guide how the work is done and Kanban to guide how the work is managed and improved.

Conclusion

I think, for all their similarities, they’re still distinctly different, which is why I think using them as complements beats seeing them as competing methods. I do think Kanban in software development has been stretched quite some way from its original purpose, and that what is being majored on there is not what its major purpose was in manufacturing  – it would be nice to think that people using its visual management features also understand its role in managing inventory in a demand-driven way  – and if they don’t, I don’t suppose it much matters.

What it won’t change is that Kanban’s role in Lean manufacturing is as central today as it always has been – and always will be.

Next time, we’ll have a crack at agile, in its myriad re-inventions……