Some thoughts on the differences between Kanban and Scrum 25 years ago, David Anderson and I put on the Miami Lean-Kanban Conference. At the time there were mostly two flavors of Kanban. One based on Lean and the other was David Anderson’s Kanban method here you just did Kaizen changes. I wrote an article called Demystifying Kanban for Cutter explaining the difference - see https://lnkd.in/gnQNTCxx Back then the difference between Scrum and Kanban was clear. Nowadays it seems that Scrum folks are trying to integrate Kanban into Scrum. And apparently Scrum is rubbing off on Kanban people. Back in the day we’d have never said Kanban as immutable – in fact David and I explicitly stated it wasn’t. There’s no true definition of Kanban anymore – I’m just going to talk about the differences that I see – and what we talked about back when Kanban started. Sprints – essentially timeboxing for 1-4 weeks. Required in Scrum. Could be done in Kanban but would be inconsistent with its foundation on Lean. Cadence – required in Scrum, optional but a good idea in Kanban. Scrum mandates the cadence be synchronized with the spritns. In Kanban you can have them take place anytime. In fact, you can have different cadences. One for planning, one for retrospectives, one for reviews. Kaikaku (big changes) or Kaizen – Scrum requires a jump to its way of working. Lean Kanban can do either. Kanban method said Kaizen only. Immutable – Scrum for sure. Not the Kanban I knew – but now I hear it. The idea was that you continuously improve. Just be clear that when you hear someone talking about Kanban, be clear which Kanban they are talking about. My own view agrees with Corey Ladas – “there is no Scrum there is no Kanban there is only Lean!” Now I would expand it to Flow, Lean and the Theory of Constraints.
Jim Sparks
1mo
I don’t see Scrum rubbing off on Kanban folks as much. I do see Kanban rubbing off on the Scrum folks. Incorporating the 4 Flow metrics into your Scrum team helps. Visualizing all of your work helps. Managing your workflow definitely helps. Optimizing WIP. This all helps Scrum teams get better. To perform better as a Scrum team. I haven’t heard anyone refer to Kanban as “immutable”. I’m not sure what you mean by cadences in Kanban. There is no specific call out for cadences, reviews, retros and planning sessions in the #KanbanGuide. That is one of the things I love about Kanban. It’s not a framework. It’s a strategy that is actually very lightweight and simple. It does require much discipline to do well. More discipline than Scrum actually. I do agree with you that it is important to be clear about the intricacies of whatever way you decide to work. Definitely Lean and Flow for the win.
Doug Rabow
1mo
The fixed time box is what drives most of the dysfunction in Scrum implementations. Get rid of that and take a common sense approach to our inspect/adapt/improve cadence that makes sense for you in your context, and it seems we're pretty much left with the definition of Kanban you've provided here. Seems to me like a rational approach to getting work done! I really see this as the future for any org that wants high productivity and a healthy culture. I'm only going to mildly pout over the fact that I don't think Kanban as we talk about it in software has much in common with Lean Kanban from manufacturing, but I'll survive :).
Brian Hall
1mo
I have stated (for decades now) that teams that start with Scrum migrate towards Kanban and teams that start with Kanban migrate towards Scrum -- if they are doing things correctly. The result is some variation of Scrumban that works for that team/organization. And quite frankly, that's the way it should be. But that's not Scrum! Yep But that's not Kanban! Right again! It's a custom blend of what works for the situation.
Is it still Kanban if I only visualize work (but don’t limit WIP, manage flow, make process policies explicit, or implement feedback loops)? If not … immutable.
Karl-Heinz Busch
1mo
Interesting view I would start from a different point. What is the problem to solve? Is there a flow of tasks coming in? Is the flow predictable? You use Kanban to organize the work to solve this type of problem and check if it helps. Is there something to find out how to do? Something that needs to be found out? Then experiments might help. Try Scrum as a starting point. Are you doing something the second time? Then follow a plan. Use PDCA to improve. The more often you do it the more you use PDCA and A3 thinking.
People are now talking about the difference between Scrum and Kanban's immutability (prokanban is only one i know that says it's immutable). I wrote this - might be of interest The immutability of an approach is separate from whether it is being followed or not. https://bit.ly/3XbSOoR