Agile trip - [Scrum|Kan]ban

For me the solution is Kanban. Maybe it sounds scary first but you can have your useful scrum meetings (standup, retro, planning) if you like.

With kanban:

• you do not need to change anything at the first day, you do not need anyone else to be changed around you to make things work without being frustrated. You can slowly and effectively change what is needed later.
• you can visualize your actual workflow from the beginning to the end. Usually you do much more than to do, in progress, done. If you have 3 rounds of QA and 2 rounds of code review, and a slow and time consuming release process, you can create columns for them. From that very moment everyone (including you) will see how many states does a ticket need to go through before you can forget it. Because this is what matters, not only the to do-in progress-done...
• you do not need to lie that anyone can pick up a task, you can define what column belongs to what part of the team (well it will mirrored in the WIP points anyway), so everyone can see how the load is balanced. If there are bunch of columns what belongs to one or two guy, you will immediately see it (more importantly show it to others)

I like the fact that you can make your current process visible, and you do not need to change it. You will not have problems with estimating tickets from QA or dev point of view, because it does not matter. You do not need to estimate anything because the time will show you what is your velocity (here it is the lead time), and that is your real velocity. that is the amount of time you need to push a feature to live. You will not need to convert the complexity in yours and other's head to time because it is based on time already.

If you worrying about the planning things, that can be solved easily as well. If the amount of tickets in the ToDo column is lower than X you can do a planning meeting and refill it. If only 5 ticket is ready because the project owner was on holiday you put that 5. It is not an issue at all, you just have to do the next planning earlier. If your team members cannot pick up any task (frontend, backend whatever devs) you do not need to solve it asap, or do weird personal planning meetings upfront. If someone is lack of tasks he can pick up something, or request a ticket from the PO, it is all dynamic. You can also create a column to collect tickets for specific releases, and you will always see how much testing effort is needed for that release. You can even define WIP on those columns to avoid big releases. If you have multiple teams working on the release you can use one board with swim-lanes and handle everything together. If you often forget the end-to-end test of a feature implemented by multiple teams in a period of months, just create a column for it...

if you have too much columns you can create more subset of the boards based on the roles in the teams. QA will see different columns than a dev, a project manager, etc.... 

You can do whatever is needed to make your life easier. The WIP will make sure to not be stuck, it will force you to move tickets forward, and the rest depends on you. You can adapt it to your workspace you will not depend on anything. 

Kanban is more like a tool than a process.