Frankly, I think you should look at them all. Scrum because it heavily emphasizes iterative and incremental development. XP because it gives a lot of advice on the technical side of development. Kanban because it emphasizes WIP limits and flow.

That’s how I’ve come to know them anyway; I’ve noticed they’ve all influenced each other heavily over the years. In either case, no methodology has all the answers.

For me, a very important core idea for everything “continuous” (both continuous delivery and continuous deployment) is making things as small as possible: make the stories smaller, so they’re finished sooner, which makes you focus on iterative, emergent development with quick feedback. But also make the components in your application itself smaller and more decoupled.
I.e. if you focus on small services that communicate with each other through some form of messaging, the services become easier to understand, easier to test, and there will be less chance of your changes inadvertently rippling through to other parts of your code.

For a more elaborate albeit more “extreme” explanation on the latter, here are 2 very interesting videos: https://vimeo.com/79866979, https://vimeo.com/74452550

I will start with SCRUM. SCRUM has powerful principles that will guide your team through your projects.

It is a powerful, simple, and flexible framework. Since it’s a framework it doesn’t handle every step that you might need in your SDLC. It only provides basic guiding principles that’s why SCRUM is usually used with other practices like XP and continuous delivery.

Sample implementation of SCRUM and other principles:

• SCRUM and Pair Programing (XP)
• SCRUM and Continuous delivery
• SCRUM and Planning Game (XP)

I strongly believe that Kanban is better suited for continuous delivery (CD). Here are some reasons why :

• Kanban and CD complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.
• Kanban teams focus on optimizing the flow of work out to customers.
• Kanban helps you create a steadier workflow and you can absorb
  unplanned work (such as bug fixes) more easily. You’ll be able to
  re-prioritize work and focus on finishing the work you have started
  rather than switch between tasks.
• Kanban does not require timeboxing of sprints and as a result
  priorities can be shifted quickly to meet business needs. An urgent
  fix or on improvement with very high priority can flow through at a
  rapid pace.
• Kanban promotes incremental improvement, which is essential to
  success with continuous delivery.
• Kanban’s roles for Service Request and Delivery managers are more
  in-line with the flow of CD in when compared to Scrum’s more
  process-focused roles.
• Scrum is based on regular fixed length sprints while Kanban is based on continuous flow and does not have to respect the length of sprints.
• In Scrum, delivery is done at the end of each sprint if these are approved by the Product Owner while Kanban is based on continuous delivery.