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

351–360 of 459 posts

Re: I don’t believe in sprints

#351

Post by pwinnski »

closeparen wrote: post #216
pwinnski wrote: post #207

Earlier quoted context omitted.

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...

Who said anything about scrum? The comment was about "agile," of which scrum is only one possible implementation[0]. Sprints are not only found in scrum, but also in other agile approaches, like kanban.

Two-week sprints seem to be the default in tech, although I've worked at a company that very successfully used one-week sprints. That's completely separate from how strictly companies try to follow "scrum," if at all. I've run into kanban more often than scrum, personally.

0. https://en.wikipedia.org/wiki/Agile_software_development

Re: I don’t believe in sprints

#352

Post by peteradio »

the_af wrote: post #334
peteradio wrote: post #330

Earlier quoted context omitted.

If developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.

With sprints, the work of developer z would get broken up in more manageable chunks. The backend project would be very high risk otherwise. More in general, coordinating between related but separate projects is a hard problem in software engineering, and it's orthogonal to whether you use sprints, kanban, waterfall or whatever methodology.

The work is to read and synthesize a 10k+ smorgasbord, how do you break that into 2 week sprints?

Re: I don’t believe in sprints

#353

Post by robertlagrant »

PaulHoule wrote: post #148
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…

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.…

> Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.

You can just ship 2 days into the next sprint if you need to. You don't have to only ship at the end.

Re: I don’t believe in sprints

#354

Post by robertlagrant »

js8 wrote: post #340
robertlagrant wrote: post #245

Earlier quoted context omitted.

> OK, I take it your answer for visibility is management reporting, I am not sure about predictability Not reporting. Reporting is an internal function. People would like to know what's happening and what's going to happen, so that they know roughly what to expect for planning purposes elsewhere in the business, e.g. marketing. Not just reporting for its own sake.

If you want to know how long it will take to develop a feature, just create a task for this research/design/planning and schedule it as usual in Kanban. Still, no sprint required.

I'm not saying a sprint is required. You were asking why visibility and predictability would be a good idea. Sounds as though I've convinced you!

Re: I don’t believe in sprints

#355

Post by pjmlp »

thegrimmest wrote: post #296
pjmlp wrote: post #189

Earlier quoted context omitted.

Unless the construction blueprint includes the construction workers skill set, and the bill of materials, I doubt it.

Construction blueprints do indeed include a schedule of materials and finishes.

And as we all know they always deliver on time with top quality.

Re: I don’t believe in sprints

#356

Post by robertlagrant »

b3morales wrote: post #347
dolmen wrote: post #331

Earlier quoted context omitted.

We modulate sprint length based on resources available. There is no point to keep a strict 2 week sprint if during one week most of the team will be on vacation (ex: Christmas), so we make the sprint duration to 3 weeks.

I am curious why you would change the duration rather than changing the workload. Sprint velocity is a ratio of both components: either can be adjusted to preserve it.

Yes, changing the workload would be the normal approach. Same for if people are going to be on training courses, or the team decides they need to spend more time on training in general, so they're going to lower their workload permanently by 5%. I can imagine it becoming really hard for the team to track their velocity if the sprint length varies.

Re: I don’t believe in sprints

#357

Post by robertlagrant »

hurril wrote: post #203
PaulHoule wrote: post #148

Earlier quoted context omitted.

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.

Day 0 is presumably agreeing the API contract, day 2 is mocking that, day 3 is implementing tests, day 4 is coding? Hopefully they know that? :D

Re: I don’t believe in sprints

#359

Post by samatman »

kortex wrote: post #335
samatman wrote: post #229

Earlier quoted context omitted.

My high school mentor loved to say "beware of inconvenient fictions!". The most boring choice would be "section", and boring might be good here. We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round". I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling…

Absolutely, I completely agree with every point in this comment. Round would have been a much better and more neutral term for "one unit of agile work". "Sprint" is tantamount to "bursty and not sustainable". Same with "ceremonies", that one bugs me too, though not as much. I still don't know WTF a scrum is however (not even sure that's an agile-specific term). > The fundamental unit of scrum is a small team of peopl…

Scrums are a bunch of lads violently fighting over a rugby football.

Baffling.

Re: I don’t believe in sprints

#360

Post by lwhi »

marcus_holmes wrote: post #87
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.

Agile doesn't have sprints. Scrum has sprints. And Scrum is all about solving management problems not developer problems. You can just drop sprints without replacing them with anything.

I'm sorry, but; no.

Developers aren't the only part of a product team.

You can't just drop sprints without failing to meet other objectives.

Post reply on HN