zlacker

Agile isn't meant to imply speed in the sense of LoC/s, though right? The speed in Agile is about getting customer feedback sooner rather than later (so maybe a kind of latency?). I don't think sprints are mentioned in the Agile manifesto or related materials.

And even within frameworks like Scrum, I don't think that "sprint" was ever intended to mean that programmers are supposed to be in permanent crunch mode.

>>romano+(OP)
Words matter, though.

Why call it a sprint if it's not supposed to be anything sprinting? We can literally call it anything we want, so why not pick a better metaphor?

I think that many developers who say they dislike Agile really mean they dislike Scrum. I mean, a rugby scrum is pretty violent, and sprinting non-stop is a good way of dying of exhaustion.

Come to think of it, some managers do seem to want the workplace to be a ruthless battleground with worker pitted against worker in a relentless flat-out sprint to seen as a "high performer".

>>romano+(OP)
There's a theory of "Agile", and then there's the reality of how it ends up being practiced in almost every instance. The latter is what matters.

>>rpeden+w5
The Scaled Agile Framework (SAFe) simply calls it an iteration. This is a neutral term with no implications about the pace of work.

https://scaledagileframework.com/iterations/

>>rpeden+w5
Many people call it an "iteration".

> I think that many developers who say they dislike Agile really mean they dislike Scrum.

True say.

>>rpeden+w5
Perception. Interpretation. Either way, "sprint" is intended to imply short burst, definite endpoint that can be seen. A Burndown is about measured capacity. The only actual speed that matters is time to failure, i.e. "fail fast".

>>rpeden+w5
If I recall right, Sprint originated from Extreme Programming, a predecessor to current agile methods.

In XP, there was very much the idea of spending time to prepare for a sprint. Get requirements and preconditions worked out, clear out possible distractions.. Then you'd use a 1 - 2 week long sprint (aka actual crunch time) to knock out 80 - 90% of a feature with everyone on the team under high pressure and positive, constructive stress. And then you'd have some time after the sprint to work with low pressure, clean up technical debt, consolidate and build up for the next sprint.

And honestly, that's a pretty effective way to work if you plan and gear up for it.

>>romano+(OP)
take it up with Rich Hickey I suppose :)

If you've never watched Simple Made Easy I really recommend it: https://www.youtube.com/watch?v=LKtk3HCgTa8

>>nradov+yb
SAFe is a failed ideology: https://seandexter1.medium.com/beware-safe-the-scaled-agile-...

>>__loam+kd1
There's nothing ideological about SAFe. It's simply a collection of best practices which work reasonably well in most organizations. You can pick and choose which pieces to adopt and which to ignore. Like any methodology, it can't compensate for toxic management, technical incompetence, or lack of product market fit.

If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?

>>nradov+It1
I literally linked an article going through why SAFe is MBA garbage that misunderstands why agile was created in the first place but if that's not specific enough for you then I'm not sure what you're looking for.

>>__loam+4J1
That article is garbage with no specifics. I don't know why you bothered to link it.