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

101–110 of 459 posts

Re: I don’t believe in sprints

#101

Post by lelanthran »

SkipperCat wrote: post #12

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…

> Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress.

The real problem, of course, is the word "sprint", which (whether you like it or not) implies something.

A sprint, be definition, is unsustainable.

It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it.

Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.

Re: I don’t believe in sprints

#102

Post by mihaaly »

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…

Predictable delivery depends on the quality and not on the form.

Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish!

If one lives on and focuses on atomic deliveries only and cares no other then I agree.

But that is rarely a product, sometimes not even a feature.

Also complexity (symphony of small tasks) has to live somewhere and unpredictability of the big project will not go away with week based planning cycles.

But I too know better actually. : ) Except probably all the others if everything is done with suitable care and attention.

Re: I don’t believe in sprints

#103

Post by sillyquiet »

kixxauth wrote: post #70
sillyquiet wrote: post #57

Earlier quoted context omitted.

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

I gotta say that your distinction between 'hackers' and 'developers' is pretty ill-informed - just out of curiosity, have you primarily worked in start-ups?

Re: I don’t believe in sprints

#106

Post by kortex »

arnvald wrote: post #3

I agree with the title, but the article fails to deliver on the essence - saying "points are bureaucracy, backlog is bureaucracy" does not really say what is the problem, it does not explain what's an alternative to backlog that helps to solve the same problem (visibility of the work to be done, predictability, etc.) For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An…

This is the best criticism of agile, and jira in particular. A lot of software work just doesn't box well. I've always struggled with "when is a ticket actually done?" Merge to main? Well we don't go straight to prod, we have a single staging env, so it usually cooks in staging for a few days before going to prod, and often testing has to be in staging due to the nature of our product. But tickets are usually "done" after merge. Then you gotta remember to QA.

Honestly we need about 20% more screen real estate and 1/2 more columns for staging/prod qa.

Re: I don’t believe in sprints

#107

Post by jt2190 »

> Sprints don’t help organize things…

You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually represent completed work.

> … they’re designed for mangares who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team).

That’s one take, but managers are just as likely as anyone else to B.S. their way through the tickets: “oh yeah that’s pretty much done”. The sprint demo clarifies what “pretty much” means.

> … When you’re on [an efficient team]… then it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself.

This is extremely true, and probably the main failing of any project management method.

> … the backlogs, the sprints, the points—is pure bureaucracy. It gets in the way of productive folks…

Again, we can’t talk about the sprint unless we talk about the sprint retrospective: It’s there to help the team identify tools and processes that are inefficient, and adjust incrementally through automation, elimination, or modification. One of the things that might get eliminated is the fixed interval sprint. Or replacing relative-size estimation techniques (“story points”) with something more rigorous.

That “sprints” are used mindlessly is frequently true, but we should not dismiss them mindlessly either.

Re: I don’t believe in sprints

#108

Post by mihaaly »

ISL wrote: post #95
mihaaly wrote: post #77

I hate the word to begin with. Sprint. I do not want to rush through the work and squeeze into arbitrary time period but do it properly in the timeframe necessary (and not more). The hastle and rush atmosphere surrounding this word is repelling to me. As well as the 'stand-up'. Are we on exam in the school or what? Not being adult coworkers but people in entertainment or support group to present to each other? In oth…

Yep. The primary bad thing about the Sprint is the name. If you call them "fortnight" or "week", things make more sense.

: )

Re: I don’t believe in sprints

#109

Post by madeofpalk »

kixxauth wrote: post #56
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.

> 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 the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.

Re: I don’t believe in sprints

#110

Post by cauliflower99 »

There is this notion that Scrum is supposed to automatically fix problems. It is the complete opposite - it is designed to DISPLAY problems quickly and ensure they are not hidden underneath a layer of fog. In other words, teams using Scrum will see more problems than the one that doesn't, but it's much better to see those problems than to hide or ignore them.

Sprints ARE a tool used for planning, but not just by managers. A team can use their historic sprint data to PUSH BACK against their managers and say "No, we won't get this done in time. Now go away and fix your plans.".

Other people mentioned this is a bad strawman...that's an understatement. But I think that's what the author wanted.

Post reply on HN