Comment by theshrike79 | Hacker News Reader

Comment by theshrike79 | Hacker News Reader

Scrum is meant to protect the team from changing requirements mid-work and it's a good way to work when you have a "client" that requires "features" to a product.

There is a well-defined standard process for them to add things to the backlog and there is a written down definition in which state items in the backlog have to be in so that they get picked up for the next sprint. If the team works with just one client/product, the client can prioritise the backlog.

During the sprint they can't give any input or request "just this one quick feature". The work is locked during the sprint. If they REALLY want something, the Agile Manifesto says to drop and delete all ongoing work and start a new sprint from scratch. Exactly zero clients have agreed to that - they really weren't in that much of a hurry with the feature.

After the sprint the client gets a demo of what the team achieved. An actual demo with the actual product. Not a powerpoint presentation of an ideal state or a video done in a demo environment. At this point the client can provide feedback and new features and we GOTO 10.

Usually a single member needs to be defined as a firefighter who takes on bugs and production issues that can't wait for the next sprint, but we don't tell that to the client. If there is no urgent work, they work on the sprint tasks as normal.

--

Kanban on the other hand works if the tasks have no dependencies with each other, like building maintenance or IT/DevOps type stuff.

"Install new laptop for Karen with standard package" doesn't require a sprint, anyone on the team can do it. Or "Set up AWS account with ECS for team B"

> Scrum is meant to protect the team from changing requirements mid-work

Do I need this protection? Why cannot I protect myself? Do I want this type of protection? Especially if it comes with all the negative downsides of Scrum.

Scrum is based on the imho often wrong assumption that a team needs "protection" of some sort. If your team consists of 16 year old youngsters only this might be true and this type of protection might be useful.

All this "protect the team from changing requirements mid-work" is nonsensical anyway, because no _really_ valuable work is done in 2 weeks. If the requirements _really_ changes you have to throw away the code for the old requirement. You can throw away 2 weeks of coding or 2 days. I'm pissed off more by 2 weeks of dead code. If the requirements adopts a bit its better to adopt early. And change in focus and priorities (which is _not_ a changing requirement): I'm happy to do so if I'm convinced it's for the good of the company and I'm happy to say "Sorry, this will have to wait until I'm done with what I'm currently doing. Please come back next Tuesday.".

Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work.

Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week".

This is why in Agile we have the Scrum Master who fields all requests like that and tells Marketdrone A to fight Marketdrone B on whose task is more important, because team only has enough time to complete either task on the next sprint. Every time someone tries to interfere with the team's work they firmly direct the person to the SM. In a few actual cases the team's SM has physically removed the over-eager middle manager out of the team's space with their "few quick requests and improvements".

I'd really want to know what kind of tasks can't be completed in two weeks in your opinion.

The tasks in a sprint aren't "build a house from scratch" -level, you split them until they're in manageable chunks of time. In a single sprint you might have the task of clearing the plot from any trees and laying down the markers for the house's base.

Then the client comes in and approves the direction or asks you to make the bathroom a bit bigger or move the house 5 meters to the east - which is still easy because the "house" is just stakes in the ground with string connecting them.

And again you pick 2 weeks of work you know your team can finish and the client checks that everything looks good. etc etc.

It really isn't complicated. I think the majority of HN has only been subjected to cargo-cult Agile or some kind of Agile-ish system where you just use the terms, but none of the actual processes.

> Yes, you need the protection.

You lost me there. This is the fundamental problem with Scrum; this type of paternalism where "programmer" is a synonym for "idiotic code monkey", borderline autistic who isn't capable of dealing with demand from the outside. And all programmers are the same, all organisations are the same and all type of development work is the same. Everywhere. If only we would be doing "Agile" right.

The protection in Scrum is "opt out". By default the process says that you're protected.

If the team feels that they don't need it or want it, they can drop it and just hang an "extra work and ad-hoc requests welcome" sign on their team area :)

Most teams I've worked with want to focus on the agreed work just among the team for the assigned sprint length and not have to deal with ad-hoc requests.

+1 in my experience most people that criticize scrum simply have a bad experience with a half baked implementation of scrum.

If it's implemented well it's fantastic. You get to focus on the important stuff during the sprint. Issues tend to get caught early on because experienced team members chime in during planning poker. The whole team takes responsibility for the sprint together. This leads to lots of knowledge sharing and collaboration within the team.

Once the team velocity is predictable it also becomes much easier to ask for x amount of time per week for refactoring work as the impact to project timelines can be easily quantified.

> Scrum is meant to protect the team from changing requirements mid-work

But this will happen from time to time. People writing tickets or even devs when checking the tickets don't read the related code. So you have a big and important source of uncertainty. Some things are technically constrained.

That's what the backlog grooming and planning sessions are for. The devs who will be doing the work estimate the work.

If stuff looks really vague, do a "planning" or "discovery" task on the issue first, where you dig through and maybe even prototype what you need to do.

But yes, requirements can change during a spring, but it should be very very rare and not a regular event.

Reply on news.ycombinator.com