Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don’t believe in sprints

robinrendle.com

Post reply on HN
Print view View original

121–130 of 459 posts

Re: I don’t believe in sprints

#121

Post by phailhaus »

kixxauth wrote: post #56
hurril wrote: 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…

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

Apple comes out tomorrow and announces the new iPhone 15. "We do not know when it will be ready. It might be tomorrow, or just as likely it will be in a hundred years."

Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!

Re: I don’t believe in sprints

#122

Post by roflyear »

melling wrote: post #116
hurril wrote: 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…

Yes, people like predictable. Tell management every project will take a month, and meet that expectation, then management will be happy. While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective. So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estima…

The issue is management rarely is looking 1-2 months out. They are looking 1-2 years out. On those scales it is impossible to estimate anything.

"Oh, yeah, the rewrite will be done in 1yr, no worries"

One year passes, and you haven't started!

Re: I don’t believe in sprints

#123

Post by d23 »

marcus_holmes wrote: post #21

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.

Re: I don’t believe in sprints

#124

Post by mekazu »

ryanmcgarvey wrote: post #84
kixxauth wrote: post #56

Earlier quoted context omitted.

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

Many (most?) software projects exist in environments that demand predictability. Businesses need to be able to make promises to clients and potential customers in order to make sales and garner trust. In any remotely competitive industry these are two absolutely essential ingredients to success. I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than ot…

Most good software that I can think of has the luxury of being delivered whenever it’s ready. It’s not estimation that improves the quality of the product but good cost/benefit analysis, although you can get one from the other.

Re: I don’t believe in sprints

#126

Post by js8 »

robertlagrant wrote: post #40
js8 wrote: post #10

Earlier quoted context omitted.

Why do you need visibility and/or predictability? I would say Steve Yegge's classic Good Agile, Bad Agile gives the answer - Kanban (or, more informally, a work queue).

> Why do you need visibility and/or predictability? Because someone's paying you to do stuff, and they might like to know what's happening. The incredible rush of money into tech in the 2010s might have given the impression that that isn't a thing, but it is, and teams that can't self-manage (including giving visibility and predictability) are going to become encumbered with more and more people managers to compensat…

OK, I take it your answer for visibility is management reporting, I am not sure about predictability, you didn't really answer it. SW development is as predictable as much you're willing to invest into research/planning, and that very much overlaps (as observed in Kanban) with doing the actual work.

When I started SW development in 2005, we had one meeting a week (Friday) with our boss, where we summarized what progress we made during the week. It was exactly what he and his superiors needed to know, not anything more.

Re: I don’t believe in sprints

#127

Post by aqme28 »

robertlagrant wrote: post #36
hurril wrote: 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…

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.

And every rebuttal is about how well it goes in the (seemingly rare) case that everything goes as its supposed to. Both are overfits of a sort.

Re: I don’t believe in sprints

#128

Post by donatj »

pammf wrote: post #92

I feel most of the criticism towards Agile coming from devs misses an important point: how it’s used to show the progress of a project to the people outside of the team. Unless you are part of a completely autonomous team, you need to communicate progress in a way that’s more informative than saying “trust me and leave us alone, it will be delivered in X months”. Spending time in meetings or writing down and discussi…

It’s horse before the cart though. It’s definitionally organizing work so it’s easy to understand and measure, rather than easy to actually work on.

That’s not an optimal way to get work done. It’s metrics.

Re: I don’t believe in sprints

#129

Post by throwaway284243 »

kixxauth wrote: post #56
hurril wrote: 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…

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

> Why do we need predictable deliveries?

Because your organisation answers to shareholders on a quarterly basis.

Re: I don’t believe in sprints

#130

Post by pacifika »

izacus wrote: post #71
robertlagrant wrote: post #36

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?

The tale of the project launch that wasn’t missed because the client was onboard with iterative delivery?
Post reply on HN