Scrum is more about keeping your fellow engineers informed on what they are working on so incompatible things rise quickly. It shouldn't be used as a tool for micro management but instead reviewed at the end of each sprint.
I'd tend to think the latter are "doing it wrong", but then again, who am I to say? I just know I much preferred working for the companies who did it the former way.
Also, need to ask question should not require whole team meeting.
And if the response is it's a verb not not a noun then it's really nothing but good hackers employing tried and true practices.
Granted, my team is small and close-knit. But the idea that keeping others informed of what you're doing is considered "asking permission" points to some serious pathology on your team.
And that pathology is not agile or scrum. We do scrum, and I'm sort of lukewarm about how much I like scrum. But whether we're doing scrum or something else, I am completely empowered to make my own decisions about my work. And I simultaneously value that the rest of my team keeps me informed of what they're doing. This is how we kick ass.
If a process isn't getting you what you want then change it. Is it any wonder that repeating a broken process gets you broken results each time?
That is regardless of agile or whatever development methodology you use.
I am also a big believer in hard short deadlines when it comes to doing releases. When the deadline comes, release what you have ready and put it behind a feature toggle if needed to do a phased rollout.
If you encounter situations where you are being micromanaged, try to place yourself in the role of the one who is micromanaging and try to see his challenges. That person is just somebody who is trying do his best. No one wants to suck the joy and energy out of his or her colleagues.
The reason you can't really apply "Agile" to research is that having a useful product at the end of each sprint is a central to Agile development but runs contrary to the purpose of research.
Now, you still need to manage your research process. You need to identify the specific research questions you need to answer, and you need to bound the time investment. But let's not try too hard to shoehorn a methodology primarily oriented towards IT consulting into every other domain.
It sounds like you created the tasks yourself and added them to the backlog mid-sprint. If that's what you did I'd be totally cool with it but I can tell you a lot of "agile shops" would blow a gasket over that.
This is the nonfalsifiability of a religion surfacing.
THIS is the problem. This very thing.
The implement is ALWAYS blamed.