It depends.

I like to use the analogy - you wouldn’t go into a supermarket and buy only products belonging to one brand (unless you find that brand offers all the products you need at the best value with the best expiry dates for your needs). The same applies for any methodology - why limit yourself to “just” Scrum or “just” Kanban? Take the practices from several methodologies and stitch them together, and keep removing and adding these until you end up with a patchwork blanket that you absolutely adore.

But where’s the “Silver Bullet”?

There isn’t one. Take the things you like/works for your circumstances from several methodologies and ignore the others. I dislike certain practices of Kanban - such as the names of the emerging roles - “Service Request Manager” (most similar to the Product Owner) and “Service Delivery Manager” (aka the ScrumMaster) just makes me want to vomit.

At the same time, I dislike estimations in Scrum. It is human nature to want to translate story points/t-shirt sizes/etc. into time. That is how we work. Customers want to know deadlines and so we force ourselves to come up with estimations. In my experience, monitoring the lead time of different work item types for your team, over time, is the only way of providing customers with release dates, with a reasonable level of confidence. A burndown chart can be useful for the team to see how their actual rate compares to the “ideal” rate, but burn-up charts as used in GROWS, or Cumulative Flow Diagrams (CFDs) from Kanban are much more realistic for setting customer expectations (in my experience).

We’ve all heard the idiom “don’t put all your eggs in one basket” and this is definitely what you should apply for software development, whichever methodologies you are considering.