Return to Answer

First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile mean.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you're not strong in CD - this is the best option to start with. It's a bit slower than CD and faster than Scrum, and it results in very good quality.
3. Scrum - it's iteration based and has a lot of extra activities. So it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. And processes don't have to be static - you may change them back-and-forth depending on current moods in the team.

First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile means.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you're not strong in CD - this is the best option to start with. It's a bit slower than CD and faster than Scrum, and it results in very good quality.
3. Scrum - it's iteration based and has a lot of extra activities. So it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. And processes don't have to be static - you may change them back-and-forth depending on current moods in the team.

First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile mean.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you don't know CD - this is the best option to start with. It's a bit slower than CD and faster than Scrum, and it results in very good quality.
3. Scrum - it's iteration based and has a lot of extra activities. So it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. E.g. personally I often go from CD to JIT/ToC and vice versa depending on the current moods in the team.

First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile mean.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you're not strong in CD - this is the best option to start with. It's a bit slower than CD and faster than Scrum, and it results in very good quality.
3. Scrum - it's iteration based and has a lot of extra activities. So it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. And processes don't have to be static - you may change them back-and-forth depending on current moods in the team.

First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile mean.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you don't know CD - this is the best option to start with. It's much faster than Scrum and results in very good quality.
3. Scrum - it's iteration based so it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. E.g. personally I often go from CD to JIT and vice versa depending on the current moods in the team.

First - Agile Software Development is about changing your process to fit your needs. Scrum is not agile, Kanban (JIT) is not agile. It's your team changing processes or coming up with your own processes that suit your situation - that's what being agile mean.

These days among the methodologies there's a clear understanding what's faster and resolves in better quality. It will depend on your qualification, team and organization what you can actually apply:

1. Continuous Delivery is choice #1 today. You can release to PRD even if features are not ready (there're techniques that allow to hide those changes). But you'd need someone who's experienced in it to make it work. And it may result in poorer quality than the next choice if you have a weak dev team.
2. Just-in-time, Theory of Constraints - with these you release every task (or group them in small batches). If you don't know CD - this is the best option to start with. It's a bit slower than CD and faster than Scrum, and it results in very good quality.
3. Scrum - it's iteration based and has a lot of extra activities. So it results in lower quality and slower (a lot slower) development. But it's still much better than Waterfall.

These are not always mutually exclusive. Again - your situation will most likely need something modified. E.g. personally I often go from CD to JIT/ToC and vice versa depending on the current moods in the team.