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

51–60 of 459 posts

Re: I don’t believe in sprints

#51

Post by kixxauth »

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…

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.

Re: I don’t believe in sprints

#52

Post by gnfargbl »

robertlagrant wrote: post #34
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…

> I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Assuming you don't stop there and keep doing those things, I don't see why you don't like agile.

I think the parent is coming from a place where projects have a defined start point and a defined deliverable at the end. In that situation, they might be advocating for spiral development [1], which isn't really that different to agile. It's a bit more process-heavy maybe, but as always these things are what you make of them.

[1] https://en.wikipedia.org/wiki/Spiral_model

Re: I don’t believe in sprints

#53

Post by fooblat »

For me this article joins a long list of "I don't believe in X" where the author has apparently only experienced bad versions of X.

Most of the time with the articles, the answer to "X done poorly" is to switch to "Y done well" but doing X well would have likely worked too.

Personally, my most enjoyable job as an engineer was when I worked on a project by myself in 1 week sprints. I spoke to my manager twice a week: 15-30 minutes Monday morning for "sprint kickoff" and 15-30 minutes Friday afternoon for "sprint wrap up" and how I spend the rest of the week was up to me. When a second more senior engineer joined the project it was even more enjoyable to work on it together in the same sprint format.

Having a great manager also helps a lot!

Re: I don’t believe in sprints

#55

Post by LtWorf »

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 did. I said I would not stop doing it until he'd stop. So we just continued this way.

Re: I don’t believe in sprints

#56

Post by kixxauth »

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…

Why do we need predictable deliveries?

Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

Re: I don’t believe in sprints

#57

Post by sillyquiet »

kixxauth wrote: post #51
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…

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.

Re: I don’t believe in sprints

#58

Post by wwilim »

From the dev team's perspective, sprints are a good tool to force the business people to pay attention to you. Booking a few hours of your prospective end users' time each week helps ensure they focus on collaborating with you, think about what they want, and understand what you want to tell them.

Re: I don’t believe in sprints

#59

Post by [deleted] »

criley2 wrote: post #23
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…

The one thing agile helped here is to take that process and make it fast. The problem with "Requirements, prototype, feedback, iterate, qa, qa, qa, release" is that most large shops turn that into a 3 year process. As in, a group sits in a room for 6 months and writes some insane "Requirements Doc". Then six months of prototyping against it before any customer has seen anything. Etc etc down the line until you're a p…

[deleted]
Post reply on HN