This one should be short… When I think about Scrum vs. Kanban question (which is coming back like a boomerang over and over again) I really have just one single distinction in mind – time boxing vs. flow.
If you think about Scrum and Kanban as a process frameworks (and I do so) then you can find more similarities. They both show you how to organize the work flow, give simple tools (backlogs, kanban boards). They focus on team collaboration aspect of the process. They give you simple visual indicators (burndown charts, cumulative flow charts) to quickly spot problems as well as simple metrics to give you the basis for planning (velocity, cycle time).
What is different is that Scrum creates fixed time spans and concentrate some activities around those time boxes boundaries (planning, demos, retrospectives) while Kanban goes for the continuous flow, which usually means that the mentioned earlier activities will blur a bit and change their character to more ad-hoc (instead of Scrum’s meeting oriented) style. So the question you need to answer is actually which type of work flow fits better your organization and the character of your project(s).
Do you prefer cycle with boundaries when you can for example reach your stakeholders every two weeks? Or maybe you need a freedom to make your code base unstable for let’s say 1 week and get it back to deployable state after a sprint without a pressure that this will affect some other features that need to be shipped in the meantime? Scrum might be better here.
On the other hand if you don’t need strict boundaries and you prefer to manage things in ad-hoc meetings. If you can ship features one by one or can work on them independently. If each of those features brings enough value to be shipped alone when it’s ready, then you may find Scrum too limiting and go for Kanban. Maybe you don’t have direct access to your users, your users prefer smaller increments wand want to get updates whenever they are ready. Go Kanban.
As always, you should probably be choosing the best of those two worlds. The important thing to remember is that the framework is not enough. You need to have a high quality engineering practices behind it. And those practices may be the same no matter if you choose Scrum or Kanban. So don’t spend too much time on it.