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

The fact that deployments happen multiple times a day is not exclusive of the fact that multiple deployments can fit inside one sprint.

I'm not a fan of Agile. But I don't mind the idea of "Let's define things we can get done in the next 2 weeks. And see what we can get done by the 2 week deadline, then reflect on it."

I think there needs to be a defined timeframe (of estimated time-boxed phases or whatever you want to call them), in order to reflect and measure outcomes.

In life, in some cases, meeting a requirement by a specific deadline is extremely important because the consequences are potentially very expensive.

For example, if you're organizing an in-person event of dozens, hundreds, or thousands of people. Clearly, your team must have produced the promised outcome by the deadline, resulting in as perfectly smooth an outcome as possible. Otherwise there is massive chaos, embarrassment, financial expense, and even legal consequences. The same consequences are present in even small & medium sized professional software companies.

Whereas, in software, if you're on a less important Proof of Concept consulting project... it might be OK to deliver 2 or even 4 weeks late-- there can be more flexibility, due to various factors.

The time period's name, its amount of time, its amount of work achieved... that's all fungible and flexible.

But to say "I got these 3 things done" vs. "...in 1 year" vs "...in 3 months" ...these are important details in the context of most peoples' work-- because time is a resource and a metric.

I really don't mind sprints. What I dislike is:

- Daily Standups that occur more than 3 days a week and last longer than 10 minutes. It's nice to see everyone occasionally. Forcing me to is a pain. For those other 2 days, I'd rather silently sit in on the Managers, Directors, and Architects' Daily standup (That said, if it's not genuine it could turn into a staged performance for the peons).

- Managers without Software Engineering experience leading standups

- Non-engineers not being required to give their Daily Standup report. Team Managers, Project Managers, others -- If I have to give a report, you should have to give a report as well. We should all feel the same pressure to be on point.

No, "agile sprints" are meant for pacing developers.

  - Issue tracking helps developers keep track
  - Kanban helps developers keep focus
  - Planning two weeks ahead helps developers keep priority

When "agile sprints" work well, they're either ultra-marathons (an acquired taste) or jogs.

I think breaking work time up into finite stretches of time and having a reassessment in between them benefits everyone, including devs.

I think it's very easy to go overboard with the concept, and it's very easy for the concept to be abused, but that doesn't take away from its basic usefulness. I also don't like that they're called "sprints", but that's just a nomenclature issue.

Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's easy to just look at the huge lists of tasks and think "Well, I'm expected to take a year to complete all these, and during that time, more work will be added to the pile, so I can just take my time" and become complacent.

That all said, sprint planning is impossible to get perfect, especially with an incompetent manager that fails to recognize patterns in point assignments. Consistent underestimations on the number of points the tasks are can look like people are underperforming. Consistent overestimations look like you have a team of rock stars.