Live data from Hacker News

I don’t believe in sprints

robinrendle.com

81–90 of 459 posts

Re: I don’t believe in sprints

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

Actually it is predictable, the majority of software engineers predict it at work every day (or every 2 weeks in sprint planning).

Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.

Re: I don’t believe in sprints

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

Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with? Everyone felt like we were failing even as we got a lot of stuff done.

Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%.

Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc.

Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.

Re: I don’t believe in sprints

#83
post #4

(side note: there are no crappy teams, only crappy managers) is patently false unless the manager also has the power to add/remove people from their team or fire people.

There are absolutely crappy teams, but I think what is more common is incompatible teams, or managers incompatible with their ICs.

Many folks may be unproductive with one management style yet thrive in another.

Re: I don’t believe in sprints

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

Many (most?) software projects exist in environments that demand predictability. Businesses need to be able to make promises to clients and potential customers in order to make sales and garner trust. In any remotely competitive industry these are two absolutely essential ingredients to success.

I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.

Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.

Re: I don’t believe in sprints

#85
Yeah, I don't believe in sprints either. IMHO the worst is actually the commitment for the sprint, the team shouldn't have that. They should just do the job, in their own pace, without being bothered by the end of the sprint, the beginning of the sprint, or caring about spillovers. I appreciate that deadlines couldn't be done away, as they are a fact of human life, but I don't see value in adding further overhead on top of that.

Re: I don’t believe in sprints

#86
i think it's funny how speaking of Agile is like speaking of religion or politics. everyone has an opinion and it's always a spark to fiery conversation.

like religion, I've seen Agile done poorly (extremely damaging and counter-productive) and done satisfactorily (not harming anyone with some mild benefit). theory is only half the equation, a big part of the equation is methodology and execution.

Re: I don’t believe in sprints

#87
post #42

I don't want to be rude; but this essay really isn't useful. It's a rant. To the author: You don't like sprints or backlogs? Okay. So what's the alternative? Take step back, think about the problem that agile tries to provide solutions for. Now start thinking about new solutions .. spend some time; then write an essay that makes a difference.

Agile doesn't have sprints.

Scrum has sprints. And Scrum is all about solving management problems not developer problems.

You can just drop sprints without replacing them with anything.

Re: I don’t believe in sprints

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

Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with? Everyone felt like we were failing even as we got a lot of stuff done. Additionally, despite the attempt at predictability, wider project management was lacking,…

> tickets were always underestimated

Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.

Re: I don’t believe in sprints

#89
Sprints provide natural alignment for multiple teams trying to coordinate. They also provide data about how your team makes software, frequent (scheduled) points when change is acceptable, and repetition that allows habits to form. And for teams that struggle with it, they provide a great excuse to push back on a requirements team that refuses to provide details and struggles to break down requirements into chunks that can be addressed in the duration of a single sprint.

That said, they aren’t magical. They are often misused. Not every team and every project needs them or is faced with any of the problems sprints set out to solve. And there are lots of ways to build good software.

Re: I don’t believe in sprints

#90

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 thought "sprint" was dumb at first, for exactly this reason, it's not a sprint if it's week after week. But over time it's just become jargonized, a term of art for me. It's just a unit of organization.
Post reply on HN