Live data from Hacker News

I don’t believe in sprints

robinrendle.com

191–200 of 459 posts

Re: I don’t believe in sprints

#191

I'm frankly puzzled how SCRUM sprints are even expected to work with a development + QA cycle. When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ? It seems to me that this forced synchronization is just pointless and harmful. Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in te…

Exactly! I have the same experience. It is a source of eternal frustration in the team. I had situations that everyone was crushing it, the team work efficiently and at the end the team had to go through the bashing on retro.

There is an argument that you can always add features to the sprint, so you start small and then extend sprint with additional task. But it does not work, because tasks seem to take all the time that was planned for them.

However, the rituals of SCRUM like retros and groomings taking place every 2-3 weeks is a good thing. It's like hygiene.

Re: I don’t believe in sprints

#192

I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to see the applications produced by that code and to learn the size of the teams, departments and companies around the products. This article carries little weight without some of that context.

There's no meat to this article, just a rant about some management style the author doesn't like. The author goes so far as to say that only the managers can fail in software. This sounds unbelievable to me because we're all humans.

Sprints, and points, are not JIRA. Points are not Sprints. Jira is not Scrum. These are all orthogonal tools that can work well together, in my experience. They don't always work well together. If you're doing Scrum well, you'll inspect what's working and what isn't, and change it. It's possible to change so far from Scrum you've moved on from it... but I haven't seen that happen and yet still found it useful in most places I've worked.

People who dislike Scrum often complain that the defenders regularly say "well, you're not doing Scrum if you define it like that". They throw away the whole argument. Scrum that isn't Scrum, isn't scrum. You can't not-do a thing and then claim that thing doesn't work.

Re: I don’t believe in sprints

#193

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 t…

I also don't like "sprint". Many say "iteration".

Re: I don’t believe in sprints

#194
post #29

Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.

I liked the joke when I heard it. Reading it now, I'm realizing that "marathon" doesn't fit as a metaphor because we don't know the destination. Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering

Better idea, just call it "software engineering". You don't see runners trying to find metaphors in order to organize how they work.

(Sorry, I'm a bit grumpy.)

Re: I don’t believe in sprints

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

I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months. It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.…

Sprints are meant to correlate with frequent releases. Yes, sprints are a bit weird when we are talking about such large horizons. That sounds like a square peg, round hole problem.

Re: I don’t believe in sprints

#196
post #71

Earlier quoted context omitted.

Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.

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?

Most of my career has been working at places using scrum/kanban. And the vast majority of those projects delivered valuable software to customers at the estimated pace.

The ones that didn’t were easily attributable to outside factors or specific problems like an exceptionally bad PM.

Re: I don’t believe in sprints

#197

Earlier quoted context omitted.

> 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

And of course someone invented a label to put on it. BirAdam describes a very much working model that could as well be kept unnamed.

Re: I don’t believe in sprints

#198
Someone my team either had a second job or quiet quit, but according to Jira he was really productive. The reported metrics can’t be trusted. The worst part is that our manager was the only one that didn’t figure it out.

Re: I don’t believe in sprints

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

On my experience Kanban only works for IT kind of tasks, where each ticket is an isolated action, instead of a small step to a bigger goal.

Re: I don’t believe in sprints

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

Well yes it does require some dedicated PMs, owners and leads. If you are a smaller operation that does not have this, sprints might not be as beneficial. But if you are working for anything at scale as a developer, sprints aren't necessarily to track every hour of your day, it is to give you a structured path of things to do without having to know every detail about the bigger picture/compromises with product/prioritization. Also as a developer it gives you leverage because you were given certain tasks for the week so when someone comes along and tries to inject "high" priority item X, something else has to give.

I found before I was on the planning/lead side, it was hard when you did not have this structure. People would still shove in "small" tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.

Post reply on HN