I do believe that "do something for a set period and see what happens" is the wrong way to look at timeboxing.

Rather, (at least to me) it's "don't extend the deadline, instead reduce the scope". You slice your deliverables small enough so that if you miss the deadline, it's not an all-or-nothing situation. You can always deliver a usable subset of what you planned/forecast.

Take your example, "writing those two missing features today". You might just end up delivering one of those features if your forecast turns out to be inaccurate. It's more effective if the timebox is larger and the tasks are smaller.

I always see timeboxing as ensuring that an exploratory task does not blow up in terms of time spent on it.

This means you'll hear something like: "I'll timebox improving performance of this feature to a single day; it would be nice if we can get a quick win, but it's not really blocking if we do not.".

Maybe within 10 minutes of profiling you see that one line of code that is copying large data structures around unnecessarily and a quick refactor speeds the feature up 5x. Or maybe you spent all day on it and haven't found anything that's quick to fix: You fix up a couple of small inefficiencies and speed up the feature by 2%. You write down your findings and at least now the team will know that optimising that feature will be a larger undertaking and should be estimated as such.

I have also done it for very edge case bugs where no one is really sure what the cause is and fixing it is not high priority. You might get lucky and work it/fix it quickly; but if you don't, then at least you're not spending a week when the remaining 4 days could've been spent on something of higher priority.

And yet, every single time I've been involved in scrum, specific goals have been assigned to every cycle, and people expect those goals to be met.

> Scrum uses timeboxing for all of the Scrum events and as a tool for concretely defining open-ended or ambiguous tasks.

> And yet, every single time I've been involved in scrum, specific goals have been assigned to every cycle, and people expect those goals to be met.

I don't doubt that's true, but it's not how things are supposed to work in scrum: https://www.scrum.org/resources/commitment-vs-forecast

I never heard good things about scrum. Just people saying "that's not how scrum is done!" all the time.

Edit: I don't mean to say scrum proponents are wrong, but if so many people get it wrong there seem to be a fundamental problem with scrum.

> but if so many people get it wrong there seem to be a fundamental problem with scrum

It's the same problem with all methodologies - if the management is in charge of the process and it doesn't like some aspect of the process it will ignore that aspect.

This isn't solvable by tweaking the methodology.

I hate management as the next dev, but blaming the "customers" of the methodology doesn't help.

If Scrum is X, but everyone saying "Scrum" is referring to Y, is Scrum X or Y?

The answer is it doesn't matter. The problem here is that people are doing Y not X, and discussing semantics is only useful as an appeal to authority (which to be fair can be pretty darn useful sometimes).

Scrum/Agile are useful tools to get buy in and a bit of restructuring done, but I feel as soon as you start doing real work you will just have to figure out what flavor works for your team, and what modifications need to be made to the process to make that happen.

The Agile Methodology is to argue about The Agile Methodology.

It's the CIA Simple Sabotage Field Manual applied to project management.

Any work accomplished is entirely accidental, and will be remedied during the next sprint planning meeting.

No process can fix bad management.

And no management can fix a bad process too.

This doesn't particularly make sense.

It makes sense if you don't include "replace the current process" in the set of "fix current process".