The agility is still there, its just buffered a bit. This is really useful for concentrating. If you are in a small startup with obvious goals, I don't think you need sprints. If you are in a large organization and are constantly being pulled into different directions between new feature work, production bugs, and tech debt initiatives, having a buffer is pretty useful.

Without sprints, when the next semi-important bug comes down from production, its pretty hard to justify that its more important than the feature you are building, or especially the tech debt cleanup you are doing. Everything tends to be "important" so if there is no culture of picking a set of work and sticking to it, attention is constantly distracted from one thing to the next.

For me at least, programming is all about some momentum - its hard to get rolling but once you are, you can keep going. Sprints give me the room to have bouts of momentum, stopping every two weeks to adjust direction, and then starting up again. Without them, it feels more like pacman - darting and reacting rather than holding a steady direction.

> I think it’s interesting because the feature of the sprint you appear to like is that it completely removes small a agility.

Ideally, at the end of a sprint you'll have a concrete deliverable. Because this deliverable is concrete and not ongoing, the team should (theoretically) be able to switch entirely to a different project (or priority) afterward when business circumstances demand it.

That's where the "agility" comes in. If, on the other hand, the work is being produced as a continuous flow--without hard cut-offs--then there's no set point where the team can switch priorities without leaving behind a half-finished state.

Obviously, YMMV on how this all shakes out in practice.