But humor me with an explanation, please...
There's a reason I don't work there anymore.
I don't care what the theoretical outcome is when the practical one is always this.
What kind of runner can run as fast as they possibly can from the very start of a race?
[Audience reply: Sprinter]
Right, only somebody who runs really short races, okay?
[Audience laughter]
But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
AFAIK, it does nothing to help here. But a solid leadership does help.
Agile causes a lot of those problems. GP just described all the elements of agile, "pick up next ticket as a on as one is closed", "blockers", daily status updates, etc.
When it's an agile project, either devs will choose to do the right thing, or too many developers will work on new features, whether because it gives them more visibility or because they like working on features more. And when it's not agile, either you have a product/team manager that understands the importance of not drowning in tech debt, or you have a manager that constantly prioritizes features over quality.
Neither approach guarantees that the right choices will be made, just that in Agile, the developers mostly have themselves to blame.
It's funny that Agile is always something else. It cannot be criticized because then your are doing it wrong. It's like a theory which is not falsifiable.
don't get me wrong agile is an improvement in the sense that iterating on small deliverables is better than a single giant waterfall process, no disagreement there
but yeah if your tool never delivers in the alleged benefits, ever, anywhere, then it's not good enough to say the problem is the people
tools are welded by people
if your tool doesn't take that into account and assumes and requires its users to be perfect, well, then it's not a very good tool
meanwhile doing maintenance on an existing system in an agile environment, esp with kanban, is very often literally what the poster is describing, an endless slog through tickets that aren't particularly noteworthy and thus don't really merit much consideration or celebration when done etc
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.
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".
> I think that many developers who say they dislike Agile really mean they dislike Scrum.
True say.
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.
If you've never watched Simple Made Easy I really recommend it: https://www.youtube.com/watch?v=LKtk3HCgTa8
Agile lets you manage expectations and set boundaries by scheduling a finite amount of work into a bounded amount of time.
If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?