I don’t believe in sprints • Hacker News Board

Re: I don’t believe in sprints

#291

Post by vertis » Wed, Oct 05, 2022, 2:21 PM UTC

denton-scratch wrote: post #280

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

> Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least. SCRUM and sprints lend themselves to "hamster-wheel management". That's an abuse, but it stilll gets labeled agile. Pair programming is amazing. Provided no pair has a total dullard (or worst: two dullards!), pairing with rotation quickly results in every member of the team knowing the whole project, so that any…

I've had some amazing pairing sessions and really really terrible sessions (FWIW I try to be a good pair). I accept everything you say about pairing, it has some really good team impacts.

It gets abused though far too often not just as a tool to upskill team members but also as a way to 'keep them honest'. The always on, always teaching/learning is exhausting. The constant social interaction is grueling, and I'm an ambivert (ENTP-A E=51%). I pity the actual introverts.

I've discovered, years later, that I much prefer to be alone with my thoughts when programming. Not sure I'll ever go back to an open plan office either.

Re: I don’t believe in sprints

#292

Post by spaetzleesser » Wed, Oct 05, 2022, 2:22 PM UTC

jibe wrote: post #201

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…

I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.

I love it when something needs to be done to unblock a large group of testers but the dev team says “the sprint is closed. Come back in three weeks and we will consider it”. Truly Agile.

Re: I don’t believe in sprints

#293

Post by groby_b » Wed, Oct 05, 2022, 2:23 PM UTC

shagie wrote: post #237

peteradio wrote: post #204

Earlier quoted context omitted.

How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.

Plan enough is sometimes 3 months of work. "Here's all the stuff we need to do to create a MVP." After 3 months, its not done and you are trying to do the last 90% on a task you thought was already 90% done. The hard things were put off till the end and now the optimistic "it should be done in 3 months" is getting up to directors that you don't have anything that runs at all. The sprint forces a "this is what we're d…

Hot take: If you take three months planning, either it's incredibly complex or you're holding it wrong. If your directors aren't able to recognize either case well before the 3 months mark, get yourself new directors. (Source: I am one of those pointy-haired monsters. The sinking feeling in your gut starts at the end of month one, the latest)

And the third paragraph kind of lays bare the problem with sprints: The PM can only look at all the work that needs to be done if, well, there was a discovery phase to list all the work that needs to be done. That discovery looks suspiciously like planning.

That's why agile focuses on continuous delivery of value. It's excellent for projects where it's hard to estimate the full scope, but there are many intermediate targets that are valuable to the customer. You go along until enough value is delivered, and then move on. Not all projects work like that. Some things only generate any value at the end of a long slog. Some things can be delivered incrementally but require a predictable end date. (Hello, Black Friday!)

And so, you get to adopt methodology to the problem at hand. Sometimes, you really need to spend the planning up front. Sometimes it's enough to sketch it out on a napkin. Sometimes you can do things sprint-by-sprint. Sometimes, you have larger checkpoints and sprints in between. The idea that any single methodology works for every problem is an idea favored by the consulting industry, but not a reality. And it predates agile, by a lot - I've been a process consulting victim way back in the early 80s. (And the mass of miracle methodologies directly led to "No Silver Bullet")

Re: I don’t believe in sprints

#294

Post by amarant » Wed, Oct 05, 2022, 2:23 PM UTC

Personally, I also dislike sprints. I much prefer a kanban approach with just a big, prioritized to-do list, where devs just pick the top ticket and do that. Preferably a tech lead prioritizes the list together with the PM.

But to be fair, I've worked like this mostly in places that have also enjoyed a continuous deployment way of working, with possibly multiple releases per day. In other places I can kinda see the point for "this is the stuff that needs to go into the next release" kind of sprints, but even then I'm not sure it's an improvement over straight up kanban.

I kinda feel like Ockham's razor would cut the sprint from the ideal work method tbh.

Re: I don’t believe in sprints

#295

Post by dasil003 » Wed, Oct 05, 2022, 2:28 PM UTC

ejb999 wrote: post #100

kixxauth wrote: post #56

Earlier quoted context omitted.

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.

Yes all large projects have risks, however it's ridiculous to say there's nothing unique about software. How often does a nail in one corner of a building become a dependency for a bunch of elements clear on the other side? How often does a dog house have to scale to a skyscraper because more people suddenly want to use it? How often do materials and laws of physics change in the real world? How often can you not get a clear answer on whether a specific requirement is necessary?

Software is arbitrary logic which many stakeholders expect to be magic. It's not the same as any kind of construction project.

Re: I don’t believe in sprints

#296

Post by thegrimmest » Wed, Oct 05, 2022, 2:28 PM UTC

pjmlp wrote: post #189

sarchertech wrote: post #145

Earlier quoted context omitted.

If you give 2 builders a set of blueprints for a house, they will build essentially the same house. If you give 2 software developers the same software spec they will give you 2 completely different pieces of software. The code is the blueprints. If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an am…

Unless the construction blueprint includes the construction workers skill set, and the bill of materials, I doubt it.

Construction blueprints do indeed include a schedule of materials and finishes.

Re: I don’t believe in sprints

#297

Post by tcgv » Wed, Oct 05, 2022, 2:29 PM UTC

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…

I also sensed this piece to be an emotional criticism to sprints, backlogs and tickets, lacking structure, evidence and logical arguments.

For instance:

> (...) they’re designed for managers 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).

I disagree. Visibility and documentation of work are important for having everyone working in a project on the same page in an efficient manner, and definitely not a sign of lack of trust on the team.

From checking the author's information I found that he's a "writer and web designer". So maybe he comes from a different background that led him to develop this pessimistic views on scrum.

I'm personally more attracted to Kanban than to Scrum, even so I can see value in Scrum when run in a disciplined manner.

Re: I don’t believe in sprints

#298

Post by jacobyoder » Wed, Oct 05, 2022, 2:30 PM UTC

david422 wrote: post #290

jacobyoder wrote: post #268

Earlier quoted context omitted.

> sprints give more discretion to the teams when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance. Worked on another smaller team longer - 2 years. As t…

I think the answer here is to point your current tickets higher. When someone asks for estimates on time, or points, you give a higher estimate so as to not leave as much tech debt behind. In theory or course, may not work in practice.

Potentially, some, yes. However, when goals have already been decided, and 'missing' those goals is a 'bad thing', there's only so much you can do. We'd gone from collaborative to 'command and control'. And... FWIW, we got a lot more done under 'collaborative', but it was mostly just 'me' on the dev side and one other person on the product side.

At some point though, many of the original assumptions about problems are understood to have been fundamentally wrong/misaligned, and need some revisiting. You need to touch old code, whether to delete it, or to have it align with new standards or new ... whatever. Touching anything that didn't relate to an explicit 'agreed on' jira ticket was seen as wrong/bad. I ended up bundling in 'fixes' of unrelated stuff when working on 'new' stuff because... it had to get done, but was ignored or rejected during any sort of planning.

I've heard it said that "to go fast, do it alone. to go far, you need a team". I can get on board with that, but you need a team in agreement and competent. I have a colleague working on a small team and... they're mostly just completely inexperience and bad, but there's no self-awareness. Taking direction from the guy who was in high school last year, while ignoring the person who's lead multiple teams and has delivered high value software for 20 years... that's a bizarre imbalance that can't be fixed with 'sprints' or process alone.

Re: I don’t believe in sprints

#299

Post by amadvance » Wed, Oct 05, 2022, 2:30 PM UTC

denton-scratch wrote: post #238

amadvance wrote: post #158

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…

> When a sprint starts, what QAs people are expected to do ? Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.

We may not call people QA, but in the end each person has different skills, and the same problem will arise inside developers.

Anyway, the same happens for any multi-phase cycle. Like with code review. When there are dependencies between people, you are going to need extra items to work on while waiting, and this fights with the requirement that everything should be done at the end of the SCRUM sprint.

Re: I don’t believe in sprints

#300

Post by debrice » Wed, Oct 05, 2022, 2:33 PM UTC

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…

Yes, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work to do.

I understand the author's heated post, because I've been there so many times, and I think THIS IS THE POINT of this article, the point that you are missing. Good manager shouldn't rely as much on a set tools that are broken or unfit for their team.

I my opinion, not enough people question Sprints and their viability and benefits. And he's right, backlogs are by far just a list of the things you wont do.

If your tool cannot fix your issues, the manager should. Use post-its, emails, spreadsheet, large whiteboards, hang a TV screen in the room, pdf, discussions... There is endless possibilities, be creative.