10 ms·
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.
- mydriasis 3y agoI like sprints because they're discrete. We agree to a certain bit of work that can get done in a certain period, and we do our best to complete it. It helps us to think about breaking up our tasks, and how tasks can be broken up. At the end of the sprint, we get to take a bit of a breath, and prepare for more upcoming work. Kanban style means that it's just a marathon. There's no time to stop and take a breath, there's no time to celebrate anything that gets done, because the workstream is just infinite instead of divided. That's my two cents, anyway.
- BigglesB 3y agoYup, 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.
- perrygeo 3y agoThe 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.
- JohnFen 3y ago