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

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.

If everyone on the team is aligned and knows what the priorities are, sprints are rarely needed. When you do sprint, it's reserved for real emergencies. You don't need to play games to carve out time for X because everyone agrees that X needs to get done. Then when X is done, you move onto Y. Serialize. I won't say it's the only way to build software, but this method almost always produces a superior quality product compared to arbitrarily carving up tasks and trying to bin-pack them into sprints.

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.

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.

Sprints are a huge disruption to the established order of project and product execution. They are an artificial time block competing against real world priorities. Companies that do agile sprint execution well have created an environment where planning above the developers is in sync with "time boxed development". Achieving that varies widely. This, in my opinion, is an area ripe for innovative thinking.

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.

WIP limits are great until you're waiting for more information from a supplier on one ticket, feedback from a customer on another, and help from an expert from another team on a third ticket, so you sigh and pick up a fourth ticket so you're getting something done.

Artificial deadlines aren't great - but you can always extend a sprint if the team needs it. And preferably your tickets shouldn't be a whole sprint long anyway, you should be getting multiple small things done in that time.

Sprints are one tool in your toolbox. Use them when it makes sense to do so.

I view them as most helpful around scope limiting. The goal is working software of some sort by the end of the sprint. That requires you to think about the problem at hand and how to break it apart such that you can achieve that goal inside the sprint. Some work doesn't require this boundary. Some work does.

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.

However, the rest of Agile deserves a special circle in hell.

My problems with it start around the time when I'm being impeded from the actual work. Justifying the hurdles I've anticipated or bike-shedding on the cover sheets

That being said, my experience is that most teams start off being strict about sprint planning and boundaries, but over time back off more and more until sprints are a very abstract planning/check in every two weeks, which is fine.

Just personal experience, YMMV.

In a highly interrupted team, sprints don't work. Try lean/Kanban.

You've not mentioned retrospectives, which are an important part of improving your processes, without that how can you make improvements?

There's nothing in agile that talks about deadlines, it's about commitment.

I don’t think it’s useful to have a very rigorous planning process, or be persnickety about things finishing within the sprint vs. 2-3 days carryover. I particularly hate the rituals designed to reduce autonomy, like PMs managing backlog priority or story points poker exercises. On my team engineers are responsible for their projects and the sprints are just periodic check-ins where you say what you have been doing and what’s next.

Scrum is a fine default for any software engineering team working on app/website-style engineering projects. But if their process never veers away from default Scrum, they're probably not a very good team. I've discovered that good teams are fearless about retros. They take suggestions seriously If they're unwilling to try new things, they're always going to underperform teams that experiment with process, and keep the good and reject the bad.

Scrum (and similar processes) makes every engineering team move at roughly the same speed. This is good news if you have a poor-to-medium quality team and is frustrating if your team would be speedy without the process. Teams that don't adapt the process to themselves and their companies are always gonna feel like they're stuck in the mud.

These methodologies are designed to be a "good enough" default way for non-technical managers to organize and manage projects in a domain they don't really understand.

Imagine how confusing going to the mechanic is when you don't really understand cars. You're constantly left wondering if he's bull-shitting you about the cost and effort involved in a repair and if any progress is being made and work is actually being performed. So I get why this needs to exist, but I understand that it's not about benefiting the developer.

By far the most productive teams I've worked with have been on six week iterations, with an at least approximate idea of what they're supposed to achieve in the next 90 days. One week out of that six is basically given over to demo, retro, and working out what the next one should achieve, but there is enough slack in there to accommodate the inevitable ups and downs, which two week Agile/Scrum pretends is not a thing. The lead developer is almost entirely focused on integrating the work of the others, and building strategy for the next iteration with product/marketing and the other team leads.

The other incredible tendency of highly productive teams is a lack of communication . . . because they don't need it. It may be more accurate to class this as a lack of noise, and clarity over what needs delivering. (i.e. product and the leads have done their job). I used to have to visit different teams in many locations, and you could tell how productive they were just by how quiet it was, interrupted only with the occasional "Dave, you broke the build!"

That said a 1 or 2 week deadline is much better than the 6 or 12 month deadlines you easily get otherwise. If management needs to have deadlines, shorter ones are less damaging.

I believe the original idea was that there would be plenty of downtime where the team would study the problem and think about the best way to attack it. Then when there was a solid plan, the team would sprint to execute it before returning to thinking carefully about the next issue.