I don’t believe in sprints • Hacker News Board

Re: I don’t believe in sprints

#311

Post by nathias » Wed, Oct 05, 2022, 2:46 PM UTC

rob74 wrote: post #112

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…

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…

architecture has to be done first

Re: I don’t believe in sprints

#312

Post by gabrielso » Wed, Oct 05, 2022, 2:47 PM UTC

I lost 3 minutes of my life on that article and will lose 5 more to let you know you can skip it.

It's just a rant from someone that thinks they're too good to be managed, probably that kind of engineer that has 10 conflicts a week with everyone in the company because they won't budge on their unfounded personal opinions.

Re: I don’t believe in sprints

#313

Post by quesera » Wed, Oct 05, 2022, 2:48 PM UTC

29athrowaway wrote: post #183

polotics wrote: post #39

Earlier quoted context omitted.

KANBAN is good at ensuring you do not have too many themes on your plate at the same time. Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored. Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny. If any…

Don't capitalize words that are not acronyms. It's just a 5 letter word, it's not that difficult.

> It's just a 5 letter word, it's not that difficult.

Beware the careless pedant!

Re: I don’t believe in sprints

#314

Post by denton-scratch » Wed, Oct 05, 2022, 2:52 PM UTC

vertis wrote: post #291

denton-scratch wrote: post #280

Earlier quoted context omitted.

> Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. SCRUM and sprints lend themselves to "hamster-wheel management". That's an abuse, but it stilll gets labeled agile. Pair programming is amazing. Provided no pair has a total dullard (or worst: two dullards!), pairing with rotation quickly results in every member of the team knowing the whole project, so that any…

I've had some amazing pairing sessions and really really terrible sessions (FWIW I try to be a good pair). I accept everything you say about pairing, it has some really good team impacts. It gets abused though far too often not just as a tool to upskill team members but also as a way to 'keep them honest'. The always on, always teaching/learning is exhausting. The constant social interaction is grueling, and I'm an a…

Yes, I also found pairing exhausting. The hardest, most tiring, most-pointless pairing I participated in was with a diagnosed autistic. He was very clever; but I couldn't understand the code he wrote, and he couldn't explain what he was doing. And a lot of the code he wrote, I gradually discovered, wasn't actually helpful for the task.

Re: I don’t believe in sprints

#315

Post by negamax » Wed, Oct 05, 2022, 2:54 PM UTC

xxEightyxx wrote: post #305

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…

It's all about how everything is implemented. I've worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules. Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements. We engineers had two business analysts, a scrum maste…

This sounds like an organizational failure rather than sprint/agile/scrum. It works beautifully when lead in/by tech teams.

Re: I don’t believe in sprints

#316

Post by SpicyLemonZest » Wed, Oct 05, 2022, 2:54 PM UTC

tanseydavid wrote: post #284

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

>> could have it right now if you add 2 days to the sprint. Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.

I kinda feel like this shows the weakness of the concept. I’ve worked in a purported scrum model for years, and this is the first time I’ve ever heard of the idea of variable length sprints. Is there a hidden core that most people don’t implement properly, or is there no “there” there and agile consists entirely of calling the planning procedures you like “sprints”?

I’ve grown increasingly skeptical of whether adopting agile even prevents the waterfall model rather than making it less legible when it happens.

Re: I don’t believe in sprints

#317

Post by boredmgr » Wed, Oct 05, 2022, 2:55 PM UTC

debrice wrote: post #300

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, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work…

I guess all will agree that every successful product is an outcome on number of iterations and to perform progressive iterations there has to be a way / tool which can be one language across the board. That's why these tools such as Sprint exists. And I am sure if you are a good manager ( a future self ), you would sure not giving yourself a suggestion of using "post-its, emails, spreadsheets, large whiteboards , hang a TV screen, pdfs" as the preferred way of managing iterations.

Re: I don’t believe in sprints

#318

Post by alistairSH » Wed, Oct 05, 2022, 2:57 PM UTC

spaetzleesser wrote: post #292

jibe wrote: post #201

Earlier quoted context omitted.

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.

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 easily articulated. Sprints work less well for greenfield development with new tech - you just end up with long strings of spikes/analysis/PoC work (it can still work, but you tend not to have concrete deliverables each sprint).

Re: I don’t believe in sprints

#319

Post by jamal-kumar » Wed, Oct 05, 2022, 2:59 PM UTC

xxEightyxx wrote: post #305

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…

It's all about how everything is implemented. I've worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules. Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements. We engineers had two business analysts, a scrum maste…

I love how they pay people by the hour to massively waste that time with this kind of Peter's Principle nonsense. Like that's gotta be a major bleed on the bottom line at every company which acts like this.

Re: I don’t believe in sprints

#320

Post by mgkimsal » Wed, Oct 05, 2022, 3:00 PM UTC

the_af wrote: post #276

mgkimsal wrote: post #250

Earlier quoted context omitted.

> In what sense? In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". If you missed estimates without agile/sprints, and now miss estimates with agile/sprints, you may think "well, at least we're doing industry standard practices now - estimates are always gonna be missed anyway, but now we're more agile". But now you have the attendant overhead of planning/me…

> In the sense that they're 'doing' the 'industry standard' practice. "There's gonna be problems with anything". This is true regardless of whether they use sprints or not. Such a project is doomed regardless. I don't think any methodology will fix a project where most of the team is coasting, don't want to do the real work, or do not believe in the end goal. > The system is only as good as the weakest participant. I…

> How would it be better without sprints, though?

kanban, deliver something when it's done (even incremental when possible), fast feedback...

The notion of "here's what we'll do in the next X weeks" takes a certain amount of planning which (imo) is often better spent just doing first. As/when issues/questions come up, they need to be addressed then, not waiting.

You surface the problems early by some planning, then some work, then some feedback. "Sprint boundaries" don't seem to help in any of that. They help other people who want to know when something might be 'done', but it doesn't help me get feedback or clarify misunderstandings any faster.