There’s an article at Jeff Sutherland’s blog by Jim Coplien, who apparently thinks that Kanban is for people who can’t do Scrum properly. Ouch.
Both the Toyota Production System (which Scrum hails from), and Kanban both have their roots in manufacturing processes – and all the way back to Scientific Management. According to Jim, when people are using Kanban for software development, they’re not doing it correctly. All of the examples he gives, refer to physical manufacturing activities, where people have to physically move things around.
Apparently Kanban should be used to monitor inventory buffers, and in Scrum/Lean, inventory is something to avoid, so the existence of Kanbans is a sign of inefficiencies.
To be completely honest, it sounds like a ridiculous argument over semantics. If software development has co-opted Kanban into a new methodology that appears to work, then constantly comparing it to its manufacturing origins is a waste of time.
People getting snooty about how the 90% of all business who claim to be using Scrum but aren’t actually ‘doing it right’, only end up looking like pretentious idiots.
I would expect that these 90% of businesses have developed a hybrid model that works for them, at the current point in time. They’ve taken into account their company culture and other factors they find important, and built a process that works.
My assertion is that the development methodology is irrelevant to the client. The business rules and requirements have been established and signed-off on, so how it gets built is up to the developers. The client will only care that what they were expecting will still be delivered, with no surprises.
I’m sure that the manufacturing origins of Scrum, Lean, Kanban and the myriad of other methodologies are fascinating, but software development needs something different, and it seems that developers have gone and built something for their needs.