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

I'm the author of the first book on Sprint Goals (Driving Value with Sprint Goals: Humble Plans, Exceptional Results). I'm not working in game development. However, I do think I can add some insights.

Sprint Planning can be very simple. I've literally started a Sprint with just a goal and a Spike. You can also work entirely pull-based (https://mdalmijn.com/p/are-you-practicing-anaconda-or-hummin...).

The Sprint is supposed to be wholly flexible. The way I describe it, it should be like a pendulum that swings by and you check the progress you've made. That's it.

Yes, it's all achievable without Sprints. The biggest difference is that the Sprint provides intent: what are we trying to achieve, and why does it matter? You could also do that with Kanban together with a goal. If you can't or don't want to set a single objective for two weeks, then you should do Kanban and not Scrum.

"Most benefits attributed to sprints could be addressed through strict WIP limits." -> No. The only difference is that you set an objective. You can use WIP limits and Sprints together.

" 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." -> Most developers don't like Sprints because they turn into a push-based batch process, where the goal is to complete all tickets in a Sprint. This usually means you actually complete less work than when you'd use Kanban.

The key to make Sprints work: * Use pull-based approach compatible with WIP limits. As I call it, Hummingbird-style Scrum. * Set a single Sprint Goal. When your estimates turn out to be wrong, which they always will, you know what matters most and you can apply focus on the primary objective.

That's it.

SAFe is a cancer. It's marketed amazingly and gets the C levels all excited about metrics and other middle management sees burndown charts and other flashy things. But in my experience it's gamified, it's not a one-size-fits-all approach, 2 week sprints complete with all the ceremonies. Nothing ever happens from the retrospectives. Nothing happens if you're delivering more points than your capacity allows. Meanwhile you fear if you don't fill your capacity enough that means you're underutilized. "We don't track points for that reason" - famous last words.

Every company I work for has wound up starting out optimistic and trying to drink the koolaid to see it slowly go further away from the original plan, but they don't seem to actually break up with it.

How will this approach work with larger teams?

I can align with that, given my own experience. Going back to your original point, of alignment, how does that work in practice, with a diverse team of different expertise and experience level?

> 3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals.

When I was running retros, I created a document which recorded reasons tasks weren't finished. If you had more than 1-2 points left at the end of a sprint, you edited the doc, and either added a new reason, or just increased the tally on an existing reason. The doc didn't have edit history enabled, so it was (mostly) anonymous.

We'd review it every retro, and look for ways we could improve. A huge problem was not accounting for personal issues. We had people who were trying to take an entire normal load of tasks during the week when they were moving to a new apartment. We had true unlimited time off at this company, so there was no reason not to just take a day off. So, new explicit guideline: Take time off for your personal life. Stop trying to cram in a full week's work when you know you'll be distracted. The team will get by fine without you, and you'll be happier when you come back.

The trouble, of course, is that these sorts of things require a high level of respect amongst the team, and sometimes that's missing. So, really, you need to work on culture before you can adopt these tools.