I don’t believe in sprints • Hacker News Board

Re: I don’t believe in sprints

#211

Post by TuringTest » Wed, Oct 05, 2022, 1:32 PM UTC

mekazu wrote: post #141

phailhaus wrote: post #121

Earlier quoted context omitted.

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!

But they wouldn’t announce it until it’s pretty much ready.

> But they wouldn’t announce it until it’s pretty much ready.

Now you understand sprints

Re: I don’t believe in sprints

#212

Post by pwinnski » Wed, Oct 05, 2022, 1:34 PM UTC

stitched2gethr wrote: post #118

ryanmcgarvey wrote: post #84

Earlier quoted context omitted.

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…

> I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say. Of the software I use (slack, cloud infra, vim, Jira) exactly none of them tell me precisely when a feature will be delivered. They work ha…

Communicating hard targets to customer is always a mistake, because software is hard. For that matter, many other industries similarly try to avoid communicating hard targets, and for similar reasons.

Internally, though, Slack et al have targets and expect to deliver feature X by the end of sprint Y. They just don't tell you in case it slides by a sprint, and to avoid laying out a product roadmap for fast-moving competitors.

Re: I don’t believe in sprints

#213

Post by TuringTest » Wed, Oct 05, 2022, 1:34 PM UTC

stitched2gethr wrote: post #164

throwaway284243 wrote: post #137

Earlier quoted context omitted.

> Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for. Yep, at the end of the day, the whole world can't run if everyone is a professor emeritus just freely e…

In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this. Especially considering how often we're wrong even when we define sprint boundaries and point all the stories.

> In what company is accounting moving to software which isn't ready, and where they will experience a large fine if it's not, guaranteed by a 2 week promise? Rational people just don't do this.

You just have to sign a standard contract for building a project in 24 months, and wait 23 and a half to be in that situation.

Managers need a tool to avoid reaching that situation and renegotiating the terms in advance.

Re: I don’t believe in sprints

#214

Post by rich_sasha » Wed, Oct 05, 2022, 1:35 PM UTC

I think organizing software work is hard.

It's easy if there are only maybe 2-5 people involved, objectives are clear and not conflicting.

Usually though, you can't afford to implement every idea you have, you need to maintain old stuff while also making new stuff, teams have non trivial dependencies on each other's work, and time predictions are nebulous at best. Also software managers are generally software engineers first, not managers.

Is sprint good at these things? I don't think so (though I never managed a team with sprints, only saw other teams do it badly). But is there a better blueprint? I'm not sure either. It's a hard problem, and hearing about what doesn't work isn't so insightful.

Re: I don’t believe in sprints

#215

Post by hestefisk » Wed, Oct 05, 2022, 1:35 PM UTC

throwaway284243 wrote: post #129

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.

> Why do we need predictable deliveries? Because your organisation answers to shareholders on a quarterly basis.

Because we have budgets

Re: I don’t believe in sprints

#216

Post by closeparen » Wed, Oct 05, 2022, 1:35 PM UTC

pwinnski wrote: post #207

izacus wrote: post #71

Earlier quoted context omitted.

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.

Strict Scrum is really not the default in tech. "How Big Tech Runs Tech Projects and the Curious Absence of Scrum" is good reading here & matches my experience.

https://newsletter.pragmaticengineer.com/p/project-managemen...

Re: I don’t believe in sprints

#217

Post by the_af » Wed, Oct 05, 2022, 1:36 PM UTC

peteradio wrote: post #204

the_af wrote: post #184

Earlier quoted context omitted.

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.

That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing.

When done well, any iterative method is meant to provide early stakeholder feedback at each stage, provide some measure of progress, and have earlier warning signs that the wrong thing is being built.

> What the hell is the point of the short time framed boundaries?

It's easier to estimate a simpler and smaller thing than a larger and more complex thing. If you cannot achieve the small thing, you absolutely won't be able to do the larger one.

Re: I don’t believe in sprints

#218

Post by odd_noises » Wed, Oct 05, 2022, 1:36 PM UTC

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…

Yeah as an ex-engineer and recent product manager I was very confused how the author expected things to get done in an predictable manner of nobody knows when it'll be done. Engineers also rarely interact with the sprint process. We do sprint planning with the engineers to make sure they know exactly what they're building, how much time it'll take, and give any opinions/questions they have on the ticket. That meeting lasts for an hour (maybe less) every 2 weeks. Our daily standup is 15 mins (usually like 8-10) and the point isn't to track engineers like an overlord. It's so that if you have any blockers we can reach out to the right parties for you so the engineer can continue coding without distractions. Plus, the product manager isn't your boss to be tracking you. Your engineering manager is your boss

Re: I don’t believe in sprints

#219

Post by denton-scratch » Wed, Oct 05, 2022, 1:37 PM UTC

lwhi wrote: post #42

I don't want to be rude; but this essay really isn't useful. It's a rant. To the author: You don't like sprints or backlogs? Okay. So what's the alternative? Take step back, think about the problem that agile tries to provide solutions for. Now start thinking about new solutions .. spend some time; then write an essay that makes a difference.

I find some kind of Agile is potentially a pleasant way of handling development work. I have a couple of serious reservations in practice:

1. Part of the charm of Agile is that the devs set their own workload. That sounds empowering, but they can become like their own hyper-tyrannical manager, setting themselves unachievable workloads; that is, they become a proxy for bad management.

2. Managers can easily screw it up. For example, by wedging all projects into the same daily scrum, which then drags on for an hour; by participating in the scrum AT ALL, if they aren't doing dev work (they're supposed to be observers); by changing tasks mid-sprint, etc.

TBH I think the term 'agile' should be shunned. It's become a marketing buzzword, and has almost completely detached itself from the Agile Manifesto. If I were farming-out some dev work, and the proposal included something like "We use agile methodologies", that would raise a red flag for me.

Re: I don’t believe in sprints

#220

Post by TuringTest » Wed, Oct 05, 2022, 1:37 PM UTC

agumonkey wrote: post #144

melling wrote: post #116

Earlier quoted context omitted.

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…

This is a strange law of human groups. Only caring about negative slip. That's why everybody inflates everything to shield themselves from the backlash.

That's a good reason why sprints work well so often. They limit the amount of inflation that is possible.