Live data from Hacker News

I don’t believe in sprints

robinrendle.com

201–210 of 459 posts

Re: I don’t believe in sprints

#201
post #6

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…

I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.

Re: I don’t believe in sprints

#202
post #155
post #112

Earlier quoted context omitted.

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what…

I understand the feeling, but isn't everything eventually broken down into small tasks?

Yes, and sprints are a tool to prioritize between them and create predictable schedules for the part that has been broken down already.

Re: I don’t believe in sprints

#203
post #6

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…

I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months. It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.…

Yeah, I've tasted all of those pain points myself. At $work our app developers expect a working API with all the new routes and endpoints from day 0. We manage this, of course, since we're all adults by simply talking to each other. But... yeah.

Re: I don’t believe in sprints

#204
post #184
post #112

Earlier quoted context omitted.

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what…

What would be the alternative without sprints? What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture? Isn't such a team screwed regardless of how they allot work?

How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.

Re: I don’t believe in sprints

#205
post #6

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…

In my experience, the “predictable deliveries” delivered by agile are based on behavior changes induced by the methodology. Specifically, focusing on stable point velocity per sprint focuses the team on creating sprint plans that safely deliver. This reduces the potential accomplishments of the team - they reduce throughput and delivery to a level that can be safely accomplished every 2 weeks. I have yet to find a st…

Linear.app is an example of a startup that "successfully launched using agile" and focused on "releasing features to production", while working with 2 weeks cycles (not "sprints"):

https://linear.app/method

Re: I don’t believe in sprints

#206
post #123

Agree mostly. Jira is a nightmare. Sprints are pointless. But the backlog is useful. I find it amazing how what seems like a great idea when I think of it looks utterly pointless when I see it still on the backlog 3 months later. It's a useful tool to deal with our tendency to fall in love with our ideas.

I don’t think backlogs are bad. The notion they’ll ever be fully groomed or in control is the pernicious fiction that makes people do weeks of useless busy work to get themselves back to the same place: a massive unwieldy backlog.

Agree completely. the idea of a backlog as a neat list of things we're definitely going to do someday is crazy ;)

They're a holding pen for ideas. The good ideas get implemented immediately, the bad ones get deleted. And there's a huge middle ground of "yeah, I guess we could do that, but it's not urgent and there's other stuff to do first" that lasts forever.

Re: I don’t believe in sprints

#207
post #71

Earlier quoted context omitted.

Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.

One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?

It pans out more often than not, which is why it's the default. For now. Eventually something better might come along, but until then, this is working for many, many, many productive teams. Including mine.

Re: I don’t believe in sprints

#208
post #112
post #6

This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…

And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what…

My experience from my previous $work was that things never quite got completed. I really tried arguing for a more sprint-based approach but they didn't like what they expected to be undue overhead. I disagreed since ... well, you can't have a conversation about overhead if $thing is not even done, can you?

Re: I don’t believe in sprints

#210
post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

Wrote extensively about this a few years back and it generated a great discussion here.

https://news.ycombinator.com/item?id=17154355

Post reply on HN