The problem is your company has no idea of what it's doing. You don't estimate bug fixes or research and development. You time box them, and once you've spent all the time allocated, you report back to your team on your findings. If you can't fix the bug in a sprint, you simply work on it in a later sprint.
Second, real feature developments sounds like an epic. Those are stories that will span multiple sprints. There are ways to handle them.
Bug fixes, R&D, and real feature development are the entirety of what we do.
If none of those fit into sprints, what is the point of having them? What is the benefit of describing a feature as an epic sliced into stories spanning sprints, instead of just, y'know, getting it done?
No, they do fit into sprints, quite nicely. Time boxing gives you a deadline and accountability. Using research and development as an example, you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect. The sprint mechanism catches that sooner, preferably at the end of a single sprint, then months down the line. It's fail early fail often. Splitting a story into an epic forces the realization the feature is complex, and in many cases, seeing those numbers there quickly turns the feature from a must have into a "nice to have."
A key point to agile is that you are presenting the output of your work to the customers at regular defined intervals so the customers can decided if what you're doing it worthwhile. The daily sprints are a mechanism to detect when something is wrong.
Fail early, fail often is a fundamental component of agile.
> Time boxing gives you a deadline and accountability
An arbitrary deadline, often forcing you to interrupt your flow and then spend extra time next sprint reorienting yourself to pick up the same task again. And artificial accountability. (Did Alice overrun her time-box because she was lazy? Or because the bug was really tricky? Nobody knows! Is Bob a rockstar, or is he just really good at plausibly over-sizing small tasks? Perhaps!)
> you go off, spend months researching a new search algorithm, only to come back to hear the customer tell your approach was wrong in restrospect
That's kind of strawmanny. In no methodology should someone be allowed to wander around for months with zero feedback.
In "traditional" process the PM is in communication with the customer and keeps enough of a handle on where things stand to be able to pull the brakes when necessary. Agile seems to want to offload that work either into some vague diffusion-of-responsibility within the team, or to the customer herself (which seems bizarrely idealistic) or, most commonly AFAICT, to a de facto PM under another name.
> so the customers can decided if what you're doing it worthwhile
I have literally never met a customer who didn't want everything right now. A good traditional PM is able to manage those customer expectations. Few developers I've met have those skills or want to be spending their time doing that.
"An arbitrary deadline, often forcing you to interrupt your flow and then spend extra time next sprint reorienting yourself to pick up the same task again. And artificial accountability. (Did Alice overrun her time-box because she was lazy? Or because the bug was really tricky? Nobody knows! Is Bob a rockstar, or is he just really good at plausibly over-sizing small tasks? Perhaps!)"
You know at least 2 weeks in advance you have to be able to give your customers a report of your findings. If that interrupts your flow or forces you to "reorient" yourself, that sounds like you have poor planning and time management skills. If Alice is consistently missing her deadlines, or if Bob is consistently over-performing, the team needs to analyze the tasks being given to those individuals.
"That's kind of strawmanny. In no methodology should someone be allowed to wander around for months with zero feedback."
There is a difference between "go research this and report back" and "go research this for 25 hours and get back".
"I have literally never met a customer who didn't want everything right now. A good traditional PM is able to manage those customer expectations. Few developers I've met have those skills or want to be spending their time doing that."
Agile and the constant feedback cycle help to manage those expectations. It's another tool in the PM's toolbox.
Of course they all do. Another fundamental part of agile is the constant communication between customers and the team.
