Live data from Hacker News

I don’t believe in sprints

robinrendle.com

181–190 of 459 posts

Re: I don’t believe in sprints

#181

Earlier quoted context omitted.

> Nothing about building software, especially innovative software is predictable. This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments. > Why do we need predictable deliveries? Say I'm building a piece of software - maybe an app the audience would use - for th…

This argument comes up a lot but this is a very narrow case. Neither you nor I are building software for the super bowl, and if we were building something with such high stakes we should start way, way early and concentrate on core functionality first. There's no real deadline for the feature we decided we needed last week.

It's not the Superbowl, but I built software for a national sporting event during my time working on VOD for a broadcaster in Australia.

I think this sort of thing - where what you're building has external hard-to-move dependencies - comes up more often than you think. Those election visualisations on NYT didn't build themselves. There's often a bunch of less-hard-but-still-inconvenient dependencies as well - you're building software for hardware, or there's advertising campaigns in planning/motion.

Re: I don’t believe in sprints

#182

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…

The issue is management rarely is looking 1-2 months out. They are looking 1-2 years out. On those scales it is impossible to estimate anything. "Oh, yeah, the rewrite will be done in 1yr, no worries" One year passes, and you haven't started!

I wish it was the norm for management to be looking 1-2 years out. Sometimes that tries to happen at the C level, but even then it doesn't seem to work its way down to line managers who are almost always focused on the next immediate deliverable. Future looking managers are the exception, not the rule in my experience.

Re: I don’t believe in sprints

#183
post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

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.

Re: I don’t believe in sprints

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

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?

Re: I don’t believe in sprints

#185
post #11

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…

I think the point of the OP is missed here. Productive teams don’t need any of this garbage; least of all a religious war about methodologies. Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.

This has a real "no TRUE Scotsman" vibe

Re: I don’t believe in sprints

#186
post #132
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?

I've worked at 3 different companies now where the system worked well and teams moved quickly and created great software. Unfortunately, that story is incredibly boring and goes against the tech blog hivemind.

This, boring things don't tend to be reported on as much.

Re: I don’t believe in sprints

#187
post #136

Earlier quoted context omitted.

If you have subpar project managers, product owners, and lead developers on your team would you really be better off without structured sprints? I guess, I'm asking, is there something specific about agile that makes a subpar team worse?

It can make them believe they're good.

In what sense? If they keep missing the planned sprint so that they must take less and less work each following sprint, isn't this telling the company there's something wrong somewhere? (Not necessarily the developers, mind you).

Re: I don’t believe in sprints

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

If you give 2 builders a set of blueprints for a house, they will build essentially the same house. If you give 2 software developers the same software spec they will give you 2 completely different pieces of software. The code is the blueprints. If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an am…

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