Ask HN: Do Agile 'Sprints' Benefit Software Developers?

No. Agile is for companies to keep track of the work their developers do. It's just that simple. The problem is non-technical people trying to keep track of what technical people do is bound to fail and cause friction.

Some of the irony of this is that the actual PM should be more like a mechanic shop manager rather than the customer. One of our current issues is that we got a new PM who is, well, as you explained above. The hardest part is for them to even write sensical tickets. They can't figure out what is BE or FE work so their tickets mix multiple items while the company bans sub-tasks that devs make.

All that said, I'm 80% sure the comment you made about sprint making it feel rushed is directly noted in Basecamp's Shape Up, which honestly is a great way to run small projects where results are more important than metrics.

As a customer of this auto shop, I insist that there will now be mandatory 15-minute standup meetings every morning where the mechanics must provide me detailed updates on what exactly they did the previous workday and what they plan to accomplish today. I better hear more than just "worked on car brakes" - I want specifics!

We will also have two-week sprints with clear repair commitments that get tracked on a big visual board. If everything isn't completed by the end of the sprint, the mechanics will need to stay late and explain to me why not during an excruciating one-hour retrospective meeting. I don't care if these nonstop status reports, sprint planning sessions, standups and retrospectives frantically disrupt the mechanics' workflow. As the customer, I deserve to know what work is happening to my car at all times! Sure, my neurotic Agile mandates may cut actual wrench time in half while accomplishing nothing. But I can't blindly trust these mechanics' expertise - they need to recognize this agonizing process is for their own good, even if they hate it. I'm the customer so we'll do Agile repairs my way, no matter how much it impedes progress!

> slight sense of urgency

This is my biggest beef with agile. The urgency is false, stressful, and unnecessary.

If you're always in a "sprint" you're never actually sprinting. No one can sprint forever.

Well, to decide whether "sprints" are a good thing or not, you have to consider the history, which is mostly centered around the alternatives.

"In the Beginning, there was Waterfall" -- prior to the era of agile practices, waterfall was king: first, gather requirements, then, design a system based upon those, then implement that system, then test it, then deploy it, then maintain it. And write volumes and volumes of detailed documentation about all of these steps.

While there is nothing really wrong with waterfall per se, it tended to annoy people greatly, due to delivering irrelevant software and tons of irrelevant paperwork in many (if not most) situations. Because unless you're, like, building a moon landing guidance system, "the business" tends to change too much between the requirements and deployment phases. And/or: the "requirements" people were simply not very good at their jobs. In any case, pretty much everyone was unhappy with the end results.

So, at some point, there was the "agile manifesto" movement, which tried to fix this from the side of both the "business" (which felt it was spending too much money all the time) and the "developers" (which felt they were doing pointless work all the time). The four main points of the movement were and remain:

(1) Individuals and interactions over processes and tools (2) Working software over comprehensive documentation (3) Customer collaboration over contract negotiation (4) Responding to change over following a plan

So, right away, most of your reservations about "sprints" seem to be negated by principle #1: Trainers, books, seminars and rigid CI/CD are not prescribed by capital-A-Agile at all. It's about you, your team, and what you decide to do. Of course, this may very well mean you should look for a different team, but that can happen due to many, may other reasons.

"Artificial deadlines" are, in my experience, mostly a commercial issue. A "sprint" is always a fixed amount of time, to be spent on development. If malfunctions and associated maintenance take time away from a "sprint", that should be covered by a support/maintenance agreement. If the same people work on both development and maintenance, the former should be paused while the latter takes place. So, a 2-week "sprint" may very well take 3 or 4 weeks, if interruptions take place.

This takes some adjustments in contracts, sales, etc. But I can assure you, that a "2 week sprint of uninterrupted development time" coupled with a "maintenance agreement that extends any development sprint by the time required for personnel to fix and re-focus" works quite well. Sure, some sprints will end up taking many weeks but that's all time that's paid for, and nobody will object to payment in the end, provided all is agreed upon in advance and backed by time-sheets afterwards.