I am working in a similar shop. As others here noted, what you describe may be agile but not scrum. I would also add that whether or not back logs and sprints makes sense depends on if it is new work or maintenance and on-going support. If the former, then a waterfall approach would make more sense for a one-person team. If not, from a PM perspective, what they are doing seems like a good approach if they have multiple projects in their portfolio.
To Agile enthusiasts, the mere mention of using waterfall is sacrilege. But people need to use common sense.
Let me give an example from a recent project of mine. I was leading a team of 3 developers on an aggressive 5-month timeline to redesign two major websites. We had daily stand-up meetings. But it was a waterfall project because it was a small team, limited life cycle, and the developers were all short-term contractors committed to the project only until launch. The project followed a very traditional waterfall life cycle. Absolutely nothing wrong with that. Except we did work in an "agile" way, we kept the stand-up meetings and we kept agile development best practices. Our small team was exempted from the larger team's weekly sprint planning meetings. Why? Because we didn't have weekly deployments. And our team didn't depend on or influence the work being done by any other team. In fact, we worked almost autonomously. After the websites launched, we then transitioned over to an agile process for on-going maintenance and support. The other developers are now working elsewhere. All enhancements are planned according to periodic deployments.
The point is, it is better to use the processes that makes the most sense for the size, complexity, and the maturity of each project. If you're doing a lot of research, then it's hard to make an estimate for the next five months, so agile is probably a better approach than waterfall.
Part of the problem is that some people seem to think you be able to plan the next five sprints out in advance. That's been the case with me before. You should not be planning more than two sprints out because if you are then you are defeating the whole purpose of having sprints. A sprint is supposed to be a commitment to deliver a realistic quantity of enhancements within a set amount of time. You should not commit to something you're not sure of. Sprint planning is by its nature short-term planning, but that's kind of the point. If you have a long-term schedule, then think about breaking things down into smaller deliverables. Or setting up checkpoint meetings based on where you are in the SDLC.
Sprint planning is supposed to be a realistic commitment about what is guaranteed to be completed within a certain time frame. If you find that the planning is not accounting for unknown variables, perhaps you should start giving ranges or pessimistic estimates. Or as other suggested, use story points. Sprints also should not be booked completely to allow for slippage and other important tasks that come up.
