The other day, inspired by the conversation Marcin Floryan started on twitter and carried on in a subsequent blog, I tweeted a follow-up question: Describe the difference between Kanban & Scrum in one word.
I should start by thanking those who took the time to contribute an answer and engage in the ongoing conversations afterwards.
Before revealing all of the responses, I should explain a purposeful difference in the questions that Marcin and I posed. Marcin’s question ‘Describe Waterfall vs. Agile in one word’ pitted one delivery paradigm against the other, whereas I attempted to avoid this in my question because, well frankly because too much breath has already been wasted on that debate.
Some of the respondents saw it as an unfair comparison, including Marcin himself. The intention with the conversation was just that, to have a conversation and not to spark some sort of celebrity death match – I was genuinely interested in the outcome. I hope with that said, that those that held back from responding might feel more inclined to leave a comment on this blog.
Marcin Floryan was the first to respond with ‘cadence’
Paul Dolman-Darrall gave an initial response of ‘flow’ and then later changed his mind to ‘protective’
Mike Burrows was next with ‘evolution’ – however he did go on to point out that he saw a significant difference – to which I suggested that his one word would be ‘incomparable’
Bob Marshall suggested ‘conformance / compliance’
Wayne Peacock gave two suggestions ‘pull’ or ‘planning’
Kief Morris suggested ‘pull’ or alternatively, ‘batching’
Karl Scotland sided with Mike and suggested ‘perspective’
Olaf Lewitz said there was ‘none’
Mike Sutton agreed with Olaf and said there was no difference
Jens Meydam then suggested ‘rhythm’ (he later added ‘teamwork’ & ‘steps’)
Finally, Renee Troughton suggested ‘pseudoscience’.
That’s all very well, but what the heck does it all mean?
I’ve summarised my understanding of the answers with an explanation below:
Cadence / Rhythm / Flow / Planning
Scrum defines a series of events: Sprint Planning, the Daily Scrum, Sprint Review and Sprint Retrospectives – all of which must happen within a Sprint. The Sprint has a defined cadence (or rhythm), and so the events are all in synch with each other. Kanban on the other hand talks of cadence and specifically suggests cadences should be decoupled – indeed Kanban’s actual focus is on iterationless Flow.
Pull / Batching
Strictly speaking both Kanban and Scrum operate a pull system: in Scrum the team commits to the amount of work they think they can complete in the Sprint and so it is not a very pure implementation; Kanban differs here in that it focuses more on the work items and will only begin more work when there is capacity – it uses Work In Progress limits to ensure that not too much work is undertaken concurrently.
The difference between Kanban and Scrum when it comes to batching is more pronounced. Scrum batches by time; a Sprint, recommended as 30 days but often shortened to 14, constrains the amount of work the team undertakes – this is a very definite attempt to control batch size. Kanban takes a different approach, as I’ve stated, it focuses on the work items and their flow – the use of Cycle Time to track the progress of work items is not uncommon. Kanban itself does not explicitly state that you should focus on the batch size though. However, it is likely that in time, a focus on Cycle Time will uncover the need to reduce batch size.
‘Conformance / Compliance’ and Protective
Essentially, the suggestions here spoke of the approach that the two processes take – Scrum ignores the status quo and dictates how a development cycle should run, whereas Kanban specifically states that you should start with your existing process and seek to improve from there. This has led to the phrase ‘evolutionary, not revolutionary’ being used to describe the difference by some (see next heading). These two suggestions from Bob Marshall and Paul Dolman-Darrall respectively, created a good deal of conversation on Twitter as to the merits of the two approaches. I myself in my last company used an approach suggested by Jeff Sutherland called Shock Therapy – see a previous post on some of the experience here and so these suggestions struck a chord with me.
Evolution / Perspective / Steps
As alluded to above, these three suggestions all speak of the approach to change that Kanban and Scrum have. Kanban states that you should start with your existing process, visualise the workflow (Karl’s point about perspective) and make the process policies explicit in order to seek opportunities to improve using the scientific method. This would usually lead to small, incremental change. Scrum however is far more prescriptive and consequently is considered to take a big-bang approach. Scrum will also expose opportunities to improve and in fact, in my opinion it is far more clear about where the dysfunctions exist – it relies upon the rest of the organisation being prepared to change to overcome the issues uncovered. In addition Scrum doesn’t suggest the use of data to quantify the issues it exposes outside of its ecosystem, nor the potential benefits of the change and as a consequence, in my experience can lead to more resistance from those in the larger ecosystem.
None / No Difference
Here, suggestions from Olaf Lewitz and Mike Sutton also caused continued conversation. They struck a chord with me too, the suggestion being that both Kanban and Scrum could be used to bring about change and consequently, there was no difference.
While Kanban does reference the Lean principle ‘Respect People’, again, it doesn’t dictate any change per se and so as a consequence, does not focus specifically on the team. Scrum on the other hand has defined roles and a clear definition of who is in and out of the team.
Enough already, whose gang are you in?
I have to say that the conversation hasn’t necessarily helped me land on a definitive answer. I agree with Mike that it is usually ‘Kanban with’ – that’s possibly because I’ve never seen Scrum work at scale (I’m told it’s possible – I’ve just never experienced it for myself – quite the contrary) and I am drawn to Kanban’s principle that you should use models and the Scientific Method to make improvements but, and this is a big but, Kanban still seems lacking; it seems to actively avoid challenging the organisation too much. On the flip side this is where Scrum falls down in my experience – it challenges an organisation a little too much – I do wonder though if that speaks more of the prevailing mindset in organisations today than it does of Scrum though.
What of my own word then? Well I suppose I would offer ‘attitude’. Scrum acts like a spoilt brat, demanding everything its own way – eventually everyone tires of it and just ignores it. Kanban acts more like a middle aged duffer – always pointing out why your argument is wrong based on experience and data but is just as easily ignored.
Goes to the people that contributed to this blog post: Philip Black, Jabe Bloom, Sean Blezard, Rob Bowley, Mike Burrows, Mark Davidson, Paul Dolman-Darrall, Marcin Floryan, Torbjörn Gyllebring, Olaf Lewitz, Bob Marshall, Jens Meydam, Phil Murphy, Wayne Peacock, Karen Rodgers, Karl Scotland, Mike Sutton, Renee Troughton.
Thanks to them for taking the time to enter the conversation.