This is what we've been using for some years now, despite the general Scrum-y pressure in the organization I work in. (It is not a mandate, note we get no blowback for what we do as it is under our control, I'm just saying most of the rest of the teams definitely do something more Scrum-y.)
I am a big believer in "true agile", since "Agile" (note capital letter) has become heavily corrupted. "True agile" can really be summed up as "try some different things, keep what works for you". My team has a large number of independent projects, more than one per person. Because of that we tend to have one person working on a given project at a time, as that is a cheap way to avoid coordination overhead if you are able to get away with it.
What we found for "sprints" is that we couldn't plan anything with them, because the variance in how much time we were actually going to have to work on a project was too high. We might have the full two weeks to work on what we said we were going to work on. We might have a fire on another system that pulled that person away for literally 3/4ths of that "sprint". We might have an emergency feature request that could do the same thing. We found this variance to dominate the rest of our time planning, which resulted in our "sprint planning" being a bad joke. Nor could we just "git gud" at sprint planning, because the variance in the amount of time we had to spend on it was far, far too pathological.
I do not present this as evidence that "Sprints" are bad for everyone, only that there are cases where they really don't based on my experience as well. This has been my personal working mode for most of the last 10 years, and they've never worked for me. We've switched to a much more Kanban style of planning, which gives us the flexibility to deal with our issues without wrecking all our plans. I personally take the brunt of a lot of the highest frequency switching in our team, and my primary goal is that on a given day, I am working on one project, with a secondary goal of trying to keep it chunked up by week. That latter often fails, but I definitely try to avoid switching projects mid-day. (Which also fails, sometimes due to fires, but I've noticeably improved on this metric in the past couple of years.)
We've tried at least twice to switch to a more Sprint-y method of organization to better match the rest of the organization, but failed both times. I'm fine with the attempt, I'm just very glad we've also retained the flexibility to admit it was a failure, and that it isn't mandated from above that we must do the Sprint approach.
The vast bulk of teams in the rest of the organization I work in does have 3-7 person teams all working on one particular system, and while nobody ever escapes from the possibility of fires, they have a lower variance on the impact on that for all sorts of reasons. (Most notable being that 3/4ths of a week for one person out of 3-7 is a lower impact than 3/4ths of a week out of what was effectively zero people, which means it was actively drawing against what was nominally another project's time. That's a really big difference.) Sprints work much better for them. I'm sure they fail them sometimes but they generally seem to work for them.
