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.

user:	AA6YQ
created:	November 16, 2015
karma:	7