Use Kanban. By dropping the fixed timebox, it will allow your team to adapt more easily to the quickly changing priorities of your business.
Use Scrum. Both frameworks work best when you break your work down into small incremental pieces. I find the Scrum Sprint timebox can help teams new to the practice recognize their deficiency (work not completed at the end of the sprint) and adapt (retrospective).
Use Kanban. Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items.
Use Kanban. The lightweight framework that Kanban provides works very well in a culture of continuous improvement. They will know the right times to hold a retrospective. For teams new to this practice, the regular cadence of a retrospective ceremony will help teams establish this practice.
Use Kanban. Note that both frameworks excel in an environment of strong technical practices. However, a Kanban team may be able to reach a higher optimization level by having a constant flow of work.
Use Kanban. Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity.
Use Scrum. Again, you can achieve predictability and high level of productivity under both frameworks. For new teams, Scrum provides more guidance and resources of how to handle release planning and progress tracking.
Use Kanban. Kanban has a lower level of Ceremony and may be easier to incrementally introduce into your organization.
Use Scrum. Not that Scrum has a high level of ceremony in comparison to methodologies such as RUP, PMBOK, and PRINCE2, but it can integrate well into a culture requiring more documentation. From a Lean perspective we would question the need for this potential waste. The reality is that sometimes we have to fit within a certain culture and incrementally work ourselves out of it.