I'm going to chime in that "slower" and "waterfall" are also orthogonal, but discuss it from a completely different point (hence not replying to that comment).

Agile, done right, -can- (and I'd argue, -should-) be slow, in the context of what this is talking about. 'Slow' doesn't mean delaying working on coding until all requirements are defined (i.e., waterfall), it means once you start working, to make sure you've thought about it, to make sure you're careful in your implementation, that you pause and think about what you're doing, don't just breeze over edge cases or possible error conditions.

You can think slow or act fast even given one requirement. Say I have a requirement, "I need a REST endpoint that gives me X information".

The fast approach is to just say "Okay, this is getting information; that's a GET. We've already been writing this in this language and framework, let me just stick a new endpoint in the router file that gets that info and returns it".

The slow approach is to say all of that, and then follow it with "Okay. What happens if this information isn't there? Can that happen? If something goes wrong, do I need to return a sensible error message along with the HTTP error code? Does the consumer understand a specific kind of error message, such that it will be displayed to the user? As part of getting X, are there any additional parameters that we need; i.e., is it enough to get -all- Xs for the call, or is the size of it likely to be enough to warrant getting just Xs that match (filtering criteria)? Does the DB need to be optimized for that sort of query?" Note that agile -does- mean you probably don't address all of those as part of this story; KISS, YAGNI, etc, still apply. But taking it slow means you -think- about those things.

What's the difference, if it doesn't lead to any change? Well, thinking about it means you likely cause any failures to fail gracefully, in a well defined, recognizable, predictable manner. It also likely means you've brought up those issues, and you can determine whether they should be tackled at all; you might be able to do them as part of this story if they're small, or add some hooks such that it'll be easy to add them later, but it might also lead to creating new stories, that get prioritized into the next sprint.

Now, while people argue you need to move fast and break things sometimes, I'd argue that taking things 'slow' like that -is always better-. Why? Because if you take things slow, you can still choose not to do something. The overhead of just thinking about it, and then actively choosing to take the fastest path, is very, very small compared to just rushing in to do the fastest path. Maybe 10% extra or so. But as often as not, taking it slow will lead to you coming up with additional work that you really need to do; without it your app will fall over, or your users will get pissed off, or whatever. While that then feels slower (you are, after all, doing more), it's getting things done that -need to be done-. If you'd taken the fast approach, you'd realize you need them later, but in hindsight would justify moving fast because "well, we didn't know that then, and we got features out the door". Sure, you didn't know that then because you -didn't pause to think about it-. You can't claim that you couldn't have predicted it, and moved to avoid it, because you never tried to predict it. If you -did- spend some time thinking, and fail to catch something, then you really couldn't have predicted it, because you -tried- to. You've optimized for the best possible path as you can understand it at the time; taking the fastest path may or may not land you there, and you can't know whether it was optimal.

In short, moving fast means defaulting to not doing the extra work; moving slow means thinking, and actively -deciding- what level of work needs to be done. You can be nearly as fast as 'moving fast' (by thinking about it and deciding you don't want to do the extra stuff), but you can also decide that certain tasks really need to be done, and that, while making you slower, leads to a better product.