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

401–410 of 459 posts

Re: I don’t believe in sprints

#401

Post by arnvald »

js8 wrote: post #10
arnvald wrote: post #3

I agree with the title, but the article fails to deliver on the essence - saying "points are bureaucracy, backlog is bureaucracy" does not really say what is the problem, it does not explain what's an alternative to backlog that helps to solve the same problem (visibility of the work to be done, predictability, etc.) For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An…

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

You need visibility, because if something is done, but nobody knows about it, it's almost as if it wasn't done at all.

You need predictability, so that people who depend on your work can make future plans (and I'm not talking about promising the day of delivery, but simple "this week / this quarter / this year / probably never")

And yeah, Kanban is a good alternative, but the article does'nt mention it at all

Re: I don’t believe in sprints

#402

Post by 015a »

bkq wrote: post #2

I get the hate for sprints, and the bastardisation of agile. I think however, the root cause of this is the way in which our society as a whole has been modelled, in a top down manner where control is wrested from the bottom, and perceived control is given to those in between. Each of these articles that make, valid criticisms in my opinion, always makes me think of Bullshit Jobs [1][2]. Most of our lives nowadays ar…

I could not agree more, and I think this take is one of those mental jumps that the pro-Sprint crowd hasn't made yet, but would if they adjust their mental view of how organizations are structured to see it.

My long term pet theory (like, next 10-30 years) is: we have this cohort of "kids" growing up now in an environment where there's plenty of money to be made in non-traditional independent ventures; think YouTube, Etsy, Fiverr, or even professional consulting. Not millions for everyone, but a stable living. The internet unlocked this; it just took a couple decades for it to really blossom. Synthesize that trend with the growing "r/antiwork" "end stage capitalism" "quiet quitting" mindset that many people millennial and younger hold. Then you consider declining western populations. I think there's real potential that traditionally structured top-down companies will face challenges competing for talent in the coming decades; and we'll see an increasing trend of peer-driven organizations (you can think of this like worker owned or highly unionized shops, but its less about the ownership structure and more about the power structure and incentive/responsibility culture).

Re: I don’t believe in sprints

#403

Post by pjmlp »

sarchertech wrote: post #376
pjmlp wrote: post #355

Earlier quoted context omitted.

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

I’m not really sure what your point is.

That construction work is just as bad as software delivery, when the same shortcuts in quality are taken.

Re: I don’t believe in sprints

#404

Post by spaetzleesser »

alistairSH wrote: post #318
spaetzleesser wrote: post #292

Earlier quoted context omitted.

I love it when something needs to be done to unblock a large group of testers but the dev team says “the sprint is closed. Come back in three weeks and we will consider it”. Truly Agile.

Testing should occur within the same sprint as dev where possible - if you're throwing all work over a fence to a distinct QA team, you're doing it wrong. If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task. And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively eas…

“ if you're throwing all work over a fence to a distinct QA team, you're doing it wrong.”

That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.

Re: I don’t believe in sprints

#405

Post by mgkimsal »

hirvi74 wrote: post #389
marcosdumay wrote: post #348

Earlier quoted context omitted.

> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!" Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban. Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won…

> WIP Do you mind defining this?

Work In Progress, I think they're referring to.

Re: I don’t believe in sprints

#407

Post by slowmovintarget »

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…

Sprints, at their best, are interruption buffers. They provide a preset time before which, engineers shouldn't be interrupted from getting stuff done by whipsawing to new priorities.

That big new product is still going to take three months to deliver, regardless of sprints, but you don't get to pull the team off working on it for some new idea until next sprint.

Re: I don’t believe in sprints

#408

Post by WorldMaker »

hirvi74 wrote: post #389
marcosdumay wrote: post #348

Earlier quoted context omitted.

> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!" Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban. Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won…

> WIP Do you mind defining this?

"Work in Progress".

"Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)

Re: I don’t believe in sprints

#409

Post by the_af »

mgkimsal wrote: post #343
the_af wrote: post #332

Earlier quoted context omitted.

Kanban is good for some situations, but in my experience the problems of a weak team (or lack of vision of the big picture) only get exacerbated with this methodology. Again in my experience, in some environments kanban is an excuse for having the team on a constant death march to burnout.

And... in my experience, 'sprints-point-cards-planning-estimating' can also be a recipe for having the team on a constant death march to burnout. Doesn't mean it always is, but... find what works for the team. Let the team decide. I'd go further and say "let the people doing the bulk of the code work make these decisions first". Make process adjustments after some baselines are established to see if those adjustments…

Agreed, but is anyone arguing that the team shouldn't decide?

Re: I don’t believe in sprints

#410

Post by the_af »

marcosdumay wrote: post #348
the_af wrote: post #283

Earlier quoted context omitted.

Kanban is also fine, for the reasons you mentioned. I wonder if TFA favors this methodology? Do note Kanban can devolve into "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!". It happened to my team, and we had to ditch it because the stakeholders weren't onboard with no fixed cadence of deliveries.

> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!" Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban. Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won…

> it's safe to say that this is not kanban

But that's the problem with agile.

Nobody can or wants to pin it down. When it fails, "you are not doing it properly". The stated goals are iterations, early feedback, people over processes... except when they aren't.

Post reply on HN