Live data from Hacker News

I don’t believe in sprints

robinrendle.com

381–390 of 459 posts

Re: I don’t believe in sprints

#381

Earlier quoted context omitted.

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.

Jaded conspiracy theory:

I believe some people within certain organizations are aware of the waste at some point or another, but it's the price said certain organizations chooses to pay in order to implement a great micromanagement system.

Re: I don’t believe in sprints

#382

Earlier quoted context omitted.

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

Agile means everything is up for being changed as makes the most sense, so in the (rare) event that you really have a task with 0 sensible deliverables you would indeed likely do longer sprints or no sprints. If that's not mutable because of some management mandate your not really doing Scrum, your doing "process inspired by Scrum" and saying you are doing Scrum. That said your description of "read and synthesize a 1…

Bingo! It's nuanced and process shouldn't rule people. Unfortunately process often rules people and those shops will insist to their dying day that they are agile.

Re: I don’t believe in sprints

#383

Earlier quoted context omitted.

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!

カンバン then!

Re: I don’t believe in sprints

#384
post #237

Earlier quoted context omitted.

Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all. The sprint forces a "this is what we're d…

Hot take: If you take three months planning , either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest) And the third paragraph kind of lays bare the problem with sprints: The PM…

I believe you misread my "Plan enough is sometimes 3 months of work." which was referring to the wording of the parent comment "How bout, plan enough then just build the thing until we agree its usable and correct."

Plan it out - be it a napkin or post it notes or whatever. That isn't three months of planning.

My point is one of that if you do a "just then just build the thing until we agree its usable and correct" often doesn't get a first milestone until a month or two down the road.

Sprints, being frequent, are there to help people identify issues with planning sooner so that issues with timelines earlier.

Often the "then just build the thing" gets down a month and the customer or business realizes that you're not building the right thing... or that you're doing a demo of what was built and get a "oh, I thought you'd be further along by now - there's no budget left for this work."

Sprints are designed to make projects that fall into those situations fail sooner. The fail fast part of agile is often a hard pill for people to swallow. https://www.agile-academy.com/en/agile-dictionary/fail-fast/ and https://www.ibm.com/garage/method/practices/culture/failing-...

Planning up front or as you go or how much isn't at issue with sprints. It's making sure that the project doesn't go too far off the intended goal or is too far behind what the budget allows for - and making those issues visible sooner so that the appropriate changes (less scope, more budget, more timeline, or just canceling it all together) can be done sooner in the process.

Re: I don’t believe in sprints

#385

Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress. A good manager facilitates these items. A bad manager just throws tickets on a Kanban board. Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective…

10 years into my career I'm still waiting for this mythical "good manager". It's almost as if there's some intrinsic opposition between workers and employers, hmm...

There was some research that when MBAs were hired as managers for dev teams instead of other devs, dev compensation fell. Managers and devs play a different game.

Re: I don’t believe in sprints

#386
post #112
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…

> if they were ever aware of it

This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine).

Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding redundency. I seriously have little idea of anything I build will for the project will ever be used again in a different part. Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes.

Any feature I implement becomes an internal debate of how much abstraction is necessary vs. YAGNI.

I've since given up on even trying. Once the project is more or less finished, I'll properly just run back through it and then properly abstract, refactor, etc.. You know -- spend more time doing something twice than properly the first time, but whatever.

Re: I don’t believe in sprints

#387
post #100

Earlier quoted context omitted.

There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.

Yes all large projects have risks, however it's ridiculous to say there's nothing unique about software. How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? How often does a dog house have to scale to a skyscraper because more people suddenly want to use it? How often do materials and laws of physics change in the real world? How often can you not get…

>>How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side?

Thats like asking 'how does naming my local variable X instead of Y have any dependency on code in other functions? and assuming that summarizes the complexity of writing code.

I take it you have never built a large custom house from scratch.

Re: I don’t believe in sprints

#388

Earlier quoted context omitted.

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!

Instant karma. Thank you, phone keyboard.

I rate my comment a perfect 7/5.

Re: I don’t believe in sprints

#389
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…

> WIP

Do you mind defining this?

Re: I don’t believe in sprints

#390
It's true. But then also it isn't. Sprints (or Scrum) are useful when trying to force an Agile process within an organization that isn't Agile. If you're working in a true Agile company there's no need for sprints (or Scrum).
Post reply on HN