I was wondering if there was an SDLC (software development lifecycle) or methodology (Kanban, SCRUM, waterfall, otherwise, etc.) that was particularly well-suited for continuous delivery systems, and why?

I'm sure each methodology has pros/cons that make it suited for certain components of CD, but there must be one that incorporates principles/values that make it better geared for CD...

  • 1
    What's an SDLC? Pretty much all methodologies which are based on Agile principles (Kanban, Scrum, XP) are geared toward continuous delivery. How you choose between them wouldn't be CD but other considerations.
    – DXM
    Jan 13, 2014 at 17:43
  • I'll leave someone else to answer in depth, but SCRUM is particularly oriented around continuous delivery in that work is committed to in short 'iterations' of 1-3 weeks after which it is expected to be complete (development, qa etc.) so that at the end of each iteration a release can be made
    – Kevin
    Jan 13, 2014 at 17:59
  • 2
    ... and Kanban is even more continuous than that: take a story, work on it, move it onto "completed" queue. Release whenever you feel completed work is significant enough to warrant a new release.
    – DXM
    Jan 13, 2014 at 18:25
  • 1
    Kanban, by itself, isn't a development methodology, though. It's a tool used for scheduling work. It's a tool that's used to maintain a continuous flow of work through a process while preventing too much work from being in-progress at any given point.
    – Thomas Owens
    Jan 13, 2014 at 23:01
  • Kanban does not work very well for things that can potentially be breaking changes with any given ticket. It works more for DevOps and other roles where there is a continuous flow of tickets, but the tickets don't usually involve, for example, database migrations.
    – asthasr
    Jan 13, 2014 at 23:10

3 Answers 3


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.
  • Hi Neil, I think you could make this answer more helpful by qualifying your statements above. Eg, "Kanban teams focus on optimizing the flow of work out to customers", how do they do this? What is it about Kanban as a tool that promotes this? I think a bit more detail behind each of these bullets, ie they how or the why, rather than just the what, would help a lot.
    – guysherman
    Jul 19, 2021 at 21:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.