[marcus_holmes]

This totally misses the point of timeboxing.

Timeboxing is an alternative method to goal-setting. The classic case is diets: instead of saying "I will lose 10kg in a month", timeboxing says "I will eat healthier and take some exercise every day for 2 weeks and see what happens". The difference is to do something different for a set period of time, and then see what the result was, rather than set a goal and a deadline.

For those of us immersed in Lean Startup thinking, where goal-setting doesn't really work any more as a motivation method (who cares if I fail in my goal, that I set myself 2 weeks ago, the important thing is what have I learned in that failure?). Time-boxing is a great alternative because it doesn't judge, it all about learning what happens if we change behaviour.

Timeboxing as setting goals and "exclusion zones" misses the point of it. If you say that you're going to "timebox" writing those two missing features today, but don't manage to complete them, then what happens? Do you extend to tomorrow? Then you're not really timeboxing, you're just saying "I'm not answering any calls until I've finished these features". Which is a totally different thing.

Properly timeboxing this would be "I'm going to spend today working on those features". I don't make any commitment to finish them. I don't know if I can finish them in a day. There's no judgement if I don't - I successfully spent a day working on them, and that was the requirement. After that one day I will know more and may be able to make a judgement or commitment about completion. Or not. I'll know after I spent the day working on them, not before.

[hliyan]

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.

[koyote]

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.

[RHSeeger]

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.

[balfirevic]

> 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

[k__]

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.

[balfirevic]

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

[k__]

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

[Qwertious]

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).

[ehnto]

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.

[specialist]

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.

[guywhocodes]

There's a painful parallel to democracy here but that would probably be too off topic.

[tonyedgecombe]

No process can fix bad management.

[pantulis]

And no management can fix a bad process too.

[verletx64]

This doesn't particularly make sense.

[rightbyte]

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