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

61–70 of 459 posts

Re: I don’t believe in sprints

#61

Post by denton-scratch »

LtWorf wrote: post #18
gbro3n wrote: 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…

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.

Estimates should be made in abstract units (e.g. 'function points'), then converted to man-days or dollars or whatever using a scaling factor specific to the estimator. That way, the actual value of the estimate is moot; it's the consistency of the estimates that counts.

Re: I don’t believe in sprints

#62

Post by steveBK123 »

haasted wrote: post #25
LtWorf wrote: post #18

Earlier quoted context omitted.

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.

Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity. "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."

It inevitably does and then everyone slowly starts estimating everything at the middle point size in the agreed spectrum, with only 2-3 outliers

Re: I don’t believe in sprints

#63

Post by pevey »

LtWorf wrote: post #18
gbro3n wrote: 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…

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.

I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.

Re: I don’t believe in sprints

#64

Post by thenerdhead »

jcmontx wrote: post #41

I probably agree with some of the points of the article. However, when you're in a management position, you need some kind of measure that gives you previsibility. Not the best, not the worst. Serves a role.

It would be wonderful to see more diverse management styles in the workforce and not everyone complying to a single mold.

There's other ways to show progress and impact. Does it matter how productivity is shown if you can prove the former?

Re: I don’t believe in sprints

#65

Post by cies »

Sprints and (point-based) estimations on tickets are not to improve software quality, they are to improve manageability of the software development process.

If you work at a product shop, you might well be able to do without them.

If you build software for clients, the planning is VERY important in order keep the client happy. Knowing ASAP that the project is going to miss a deadline/budget/feature is key to whomever manages the relation with the client.

This is why we do sprints and estimations: to know how the project is going so we can update the client ASAP (or find another solution) when things are off.

Re: I don’t believe in sprints

#66

Post by acdha »

haasted wrote: post #25
LtWorf wrote: post #18

Earlier quoted context omitted.

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.

Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity. "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."

Theoretically, yes, but if you’re spending half of your time on process overhead there isn’t much left to do that well and most of the time there’ll be enough differences from sprint to sprint that it’s plausible that this time was late for other reasons, until you have a sufficiently long data set to show that it’s a trend.

Re: I don’t believe in sprints

#67

Post by shamiln »

Seems like the author is ranting hot air.

I’ve worked in sprints. I’ve been a facilitator and an IC and now manager (aside from sprints).

A bad team won’t improve with sprints.

Similarly a good team might not always benefit from sprints.

Almost every team I’ve worked with has improved with iterations and interactions.

The best team I’ve worked with used sprints and communicated with stakeholders well… which in turn spoke true to the agile manifesto.

Re: I don’t believe in sprints

#68

Post by websitescenes »

I get the sense that the OP has never worked on a large team or massive product with a large surface area and competing goals. I get it, for a lot of smaller endeavors that only have a few devs then sprint ceremonies would be overkill. But if working on large project with many teams, the lack of structure would be almost certain death. Entertaining tirade though.

Re: I don’t believe in sprints

#69

Post by websitescenes »

kwanbix wrote: post #28
BirAdam wrote: post #13

Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Thing is, much like governments, these models all fall short because people aren’t great. I think that if agile isn’t working for a team they should try another method, and if agile does work for a team that’s fantastic. People, imho, shouldn’t blindly fo…

> Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. That is agile for me. What is agile for you then?

I think maybe there is a conflation being made between Agile and Scrum.

Re: I don’t believe in sprints

#70

Post by kixxauth »

sillyquiet wrote: post #57
kixxauth wrote: post #51

Earlier quoted context omitted.

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.

So... developers aren't productive? This is a weird take.

Yeah, good point. If productivity equates to value creation then hackers are more productive. If productivity equates to what software management can measure, then developers are more productive.

I’m making a pithy statement about the difference hackers and developers

Post reply on HN