Live data from Hacker News

I don’t believe in sprints

robinrendle.com

71–80 of 459 posts

Re: I don’t believe in sprints

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

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?

Re: I don’t believe in sprints

#72

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

This is correct.

Re: I don’t believe in sprints

#73
I don't like sprints either, but this take is so engineer-centric that it doesn't stand up on its own for one second.

His ideal world works for a team of engineers that have no manager, no deadline, no collaboration with other teams, etc.

Basically it works for a personal project. That's it.

Re: I don’t believe in sprints

#75
The problem that a lot of people get to with Agile/Lean is that the actual practices deviate from the original goals. The powers that be can't actually handle agile in it's truest chaotic form. So it gets bastardised from the top down (and at times from the bottom up as well).

Worse still some of the things that are advertised as 'agile' actually violate the principles. The card wall was supposed to be about as light a representation of ongoing work as you could get and facilitate the interactions with the teams. Unfortunately, tools like Jira change this to be an over-engineered process and tool (which violates point one of the manifesto). Remote work has not made this better.

Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least.

Leaving this to the side, I've seen sprints done well and badly. More often than not teams can't manage to point cards effectively. I've had a couple of teams where things just end up in a middle ground constantly (everything is a 3). The exercise of comparing this card to some previous representative card is too hard (and is itself prone to problems).

Retrospectives, can be a useful tool, or they can be a back patting exercise. Showcases without a customer in sight (put your hand up if you're the "customer proxy").

Having said that, some of the behaviours can be really useful. Breaking down overly complex cards as a part of planning helps define the work. There are other opportunities to do this, but backlog grooming / planning sessions are one place.

Having the team discuss cards and talk about complexity often reveals unknowns. I've seen a bunch of examples where things will be caught because of a dev/designer/product manager can see something that wouldn't have been identified if someone just started working on it.

Re: I don’t believe in sprints

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

If you’re post-launch, you need predictability so that you can ship the new code often. Otherwise your HEAD might be unshippable for weeks, which would be bad from the “written but unshipped code is a waste like excess inventory” standpoint.

Re: I don’t believe in sprints

#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 other hand a flexible communication and progress tracking system - especially in a fairly unpredictible business like making a novelty product - is essential in teamwork and I know no better than something like this. But this childish naming makes me suspicious about the intention and goal of those coined it...

Re: I don’t believe in sprints

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

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses…

You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.

Re: I don’t believe in sprints

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

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses…

If you place a lot of value on planning and deadlines, you should probably embrace that wholeheartedly, and not try to pretend to be “agile.”

Re: I don’t believe in sprints

#80

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…

I'm with you about holding management accountable and avoiding crap management, but I think it is orthogonal to sprints. Sprints might be a solution for some teams, but I have seen them fail far more than succeed. Actually ... I've never seen them succeed.
Post reply on HN