Once, I heard teammates comparing Kanban and Scrum in terms of ‘better’.
I could not get into this debate, because I didn’t have worked with both of them.
In my first job working in an agile environment, We used Kanban. I just listened and tried to compare what the ‘scrum-defender’ was saying to my day-to-day Kanban work.
Nowdays, I have already built some projects with scrum.
So, despite the fact that I need much more experience working agile, I can understand the debate, and have my own opinion.
In this post, I want to share my thoughts about it:
Kanban and Scrum are (just) tools
My main thought is that Kanban and Scrum can’t be compared that way.
I think they are (great) tools, and as tools they must to be used for the work they fit.
A funny way to visualize this idea, would be making the following question:
Is a spoon better than a fork?
It depends on what do you want to eat, right?
The manifesto agile says (within another many things):
– We must start from where We are now.
– Being agile is not following fixed (and unchangeable) rules. It encourages us to response to change.
Considering that, We should use the tool that fits the team (members), the project, the customer, the company…
And customize it. Learn from our errors and improve. Make experiments, fail, and improve again based on the experience.
Is one better than another, then?
I don’t think so.
I’d apply Kanban in a project with the following characteristics:
– Without end of project defined: I see a bit difficult to calculate the full length of a project using Kanban.
– A/B testing: Kanban seems more accurated for long-term projects, that fail as soon as possible and change quickly due to market changes, experiments, etc. We don’t know which features will (finally) be added.
– With hundreds or thousand final customers: Quite close to the previous one. A demo is not actually the best way to know if the new features really fit the needs.
– Not isolated project: There are many teams, adding new features at the moment to the same software, and sometimes event desynchronized. Kanban could fit more a so changing environment.
To wrap it up… I see Kanban as a tool for a continuous and ‘more fluid’ flow, given value to the user without fixed/strict dates and features.
From what I know today, I’d say Scrum fits for projects:
– With an fixed MVP: We know which is the minimum features We wish to fit the customer needs.
– With an end date: We need / must to know (approximately) how many sprints are We’ll need to finish that MVP, because We have a fixed last release date.
– Isolated (in general terms): Is an independent product/application / project, so things do not change every day.
My conclusion is that the debate should not use the word ‘better’ but ‘accurated’.
They are tools that:
– Fit specific needs
– Can work even together in the same project
– Must be customized (change with the company, the product and the team) for being effective.
For sure, this are only my thoughts, as I said, so this is my subjective opinion, that changes with experience.