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

I've been revisiting Agile principles through "The Art of Agile Development" lately. While it's a valuable refresher, I'm having difficulty reconciling the concept of 'sprints' in Agile after 11 years in the industry. My observation is that significant time and energy go into sprint planning, discussions, and subsequent introspection when things don't pan out. Agile sprints, to me, seem reminiscent of calorie counting - good in theory but more often failing in practice.

To clarify my intent:

1. I'm seeking input primarily from software developers rather than project managers, executives, customers, etc. 2. This is not an indictment of Agile overall. I endorse limiting work-in-progress, decomposing larger tasks, continuous delivery, and scheduling improvement time - all achievable without sprints. 3. When I refer to "Agile", I'm talking about methodologies adhering to the Agile manifesto.

To be clear, I don't believe sprints inherently benefit developers, and it feels as if the Agile community hasn't adequately consulted engineers on this topic. When I've asked developers about their feelings on sprints (excluding WIP limits or task decomposition), the responses lean towards indifference or opposition. Is the effort of sprint planning worthwhile when faced with such apathy?

Common pro-sprint arguments I've encountered include:

1. Incremental improvement/Faster feedback loop. However, sprint planning seems overly complex, with most of the book dedicated to explaining a convoluted system and potential pitfalls. 2. Early value delivery. But we're in the era of CI/CD, where deployments can happen multiple times a day. Are sprint deadlines just relics of a time when physical software delivery was necessary? 3. Autonomy. I'm not sold on this either. Autonomy for developers is often overstated. We're not pursuing hobbies or creating art; we want a drama-free, predictable, and coordinated work environment where we're respected. Autonomy, especially technical, is important, but it's not the only thing that matters on a software team, and two-week Jira ticket batches don't necessarily provide it.

My reservations include:

* Overcomplication, with an entire industry of trainers, books, and seminars evolving around it. Over time, sprint discipline often deteriorates or transforms into something less Agile.

* Lack of relevance for teams practicing CI/CD.

* The creation of artificial deadlines leading to overtime, burnout, and, eventually, high staff turnover.

* Inability to handle reality. Interruptions and unforeseen tasks will occur. The database may malfunction, revealing an architectural issue requiring immediate attention. While frustrating, these could be managed with stricter WIP limits.

* Contradiction of the Agile manifesto's "Responding to change over following a plan". Sprint planning can degenerate into "micro-waterfall".

After substantial reflection, I'm left with these thoughts:

1. Most benefits attributed to sprints could be addressed through strict WIP limits. "The Art of Agile" disappointingly provides only cursory coverage of continuous planning methodologies (like Kanban, Scrumban, etc.), recommending most organizations adopt a sprint-based approach without further elaboration. 2. If sprints offer any advantages, they aren't for the developers. I've seldom encountered developers who genuinely enjoy sprints or would miss them in a sprint-less model.

Do any fellow developers here actually enjoy conducting sprints? If so, why and how do you make it work?

And if any of the book's authors frequent HN, your insights would be appreciated. The book was excellent, barring the points mentioned above.

Yup, I'd agree with this. I enjoy the "cadence" of working with a team in sprints. In a previous role with a small team, it was good to look back on the past two weeks & call out the things in a group setting that had gone well, or hear about wins that I wasn't directly involved in. Just created a great sense of forward momentum which I personally found really motivating. If some process wasn't working well for us (including the way we ran sprints) then the next retrospective would only be a couple of weeks away & we could discuss if it needed changing then. By the time I left it felt like we'd got a really well-oiled machine going. That kind of frequent communication and sense of shared forward momentum is one of the things I actually really miss now that I'm working solo again to be honest.

Positive: The alternative to sprints is frequently no process at all, not the strawman waterfall. If you can't plan two weeks of work there is no way you can plan six months work of work. Sprints mean that conflicts get surfaced regularly and not "kicked down the can" for eight months. Teams that don't release regularly don't know how to release. so they'll plan to spend six months developing something and think they'll release in six hours and end up spending another six months making a release.

Negative: If you miss a sprint with something business critical you can turn one day late into two weeks late. This process can cascade, particularly in larger organizations that have multiple teams on their own sprint cadence, that is, something that blew one sprint can blow two or three sprints instead. Conflicts surfaced by frequent sprints frequently reveal that people in an organization don't trust each other, which is a much more important problem than how you plan, schedule and structure work. (Maybe that would be good if people did something about the trust issues)

--

I'd say that (1) Kanban is the most fundamental practice of software management (well-defined work units and limited WIP) and (2) you have to release frequently so you don't forget how to release (continuous delivery) Estimates are one of many features you can add to Kanban, the value of those really depends on the project. I've worked on projects where I could quickly make a list of items to do, plan out items like "add first name field to form" in 10 minute increments, add it all up and consistently plan week-long projects with 10% accuracy. I've worked on others where it was debugging, understanding existing code, research, and resolving circular situations and in those cases it is the opposite.

Nitpicking: planning should not take a lot of effort, it should boil down to "pick the top of the backlog up to estimated capacity".

So the problem you have is perhaps with grooming/estimations. Those have more value if the product owner is not part of the team, and if you work on new developments, as they help prioritize deliverables (we can do X with N effort or Y with 3N).

I personally like sprints as they provide checkpoints, but they should not be treated as deadlines.

It your workflow is just "do this then do that" with no feedback loop related to what you'll work on, then estimations are not useful and sprints are also less useful.

The flipside of course is that they HAVE to be discrete. My issue with sprints is that they arbitrarily reduce the solution space - instead of asking "what's the right way to do this?", you ask "how much can we hack out in 2 weeks to show progress?". By putting a time/complexity limit on the work you choose to address, you are de facto ignoring any potentially high-impact work that doesn't fit into your sprint structure.

Performance optimization, bug fixes, architectural changes, dependency/infrastructure updates, developer tooling, database health, etc are rarely, if ever, prioritized in a sprint-centric workflow. Yet we know these things to be absolutely vital to the success of software.