FWIW, let me add another response here.
I would have answered the question slightly differently from Sarov in that I'd say "...one approach would be to have it same as Scrum, except with a Kanban style visualization board, and Kanban concepts of WIP Limits and Pull."
Kanban is not a software or project management methodology by itself. It is a visualization and improvement method that can only be applied to an existing method, be it waterfall or Scrum or others, including non-software, non-IT processes. So you might even consider simply applying Kanban to your current waterfall process to get the benefits of Kanban.
I just responded to a similar question so I will post that link here - hopefully, that is OK with the StackExchange powers that be :)
Also, just to share with you our own story - we are a software house that now uses Kanban for all our product development. We were a 'waterfallish' company earlier - we never adopted Scru and moved directly to Kanban.
We also made changes to our Engineering practices where we adopted a TDD approach to development and adopted Test Automation and now, increasingly, Continuous Integration/ Continuous Deployment practices.
It has taken us 3-4 years to evolve - and our Kanban board - which has gone thru multiple revisions - looks like this -
However, from being a 2 minor and 1 major release a year back in 2009, we are now a "monthly release like clockwork" organization. We deploy both on SaaS as well as to out on-prem customers, so it is possible to support both.
We have experienced significant business benefits as our customers see us to be very responsive to their needs (due to frequent releases based on customer feedback and suggestions), our CEO is happy as we deliver regularly so the fear of "missing a major release or release date" is no longer there, and employees are happy as no one is pushing them to do too many things at a time (Kanban's focus on reducing multi-tasking) and holding them accountable for estimates, etc.
I am not sure I fully understand your keenness to have sprints not only due to the desire to deliver to the market more frequently or but because you also want to plan defect fixes properly. However, that IS an important consideration whether you do sprints or not.
Kanban helps you reflect this reality that many software teams face - of working on both "value demand" (new features/ user stories) and "failure demand" (defects), by either visualizing them with different colors or in different swim-lanes (as you see on the image above, altho' we use swim lanes for different products; for us the card colors are the way to distinguish between work items of different types). The interesting thing is that while our user stories come from an upstream separate Kanban board we use for our roadmap planning (so that is our backlog), the defects (both customer-reported and internally found) are directly added to the Ready column of the swim lane and typically get a higher priority than everything else. As soon as a developer who can work on a defect is free, they will pull the defect and work on it first.
We do releases roughly on a monthly cadence, but we also have a 'soft'policy of making a release when we have enough of value done and ready to deploy (say, 15-20 users stories and defect-fixes).
In addition to the basic Kanban tools above, we also religiously follow some of Kanban's practices - the bi-weekly Replenishment Meeting to prioritize what will go next in our upcoming releases, and a Month Retrospective for lessons learned and a Quarterly Strategy Review meeting to make sure all stakeholders are aligned to what the product team is doing. Of course, the Daily Standup is the basic team-level meeting.
Hope this helps - not sure you will get prompted about this response as you have already marked another answer as the right answer :-) You can read more about Scrumban here. And if you need, I will be happy to answer any questions you have about your transition - good luck with that!