Themed days, Timeboxing and why you should use them

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.

I always found these task management systems unrelatable because they assume you have a bunch of tasks you can schedule and order at your discretion, that you can freely ignore most tasks for days at a time, that you can actually predict your priorities up to a week in advance, and that if your workload and your timeboxing conflict then your workload will be the one that budges.

That doesn't match any situation I've found myself in as a technology professional (or as a student before that). It doesn't look like most other job roles I've witnessed either. Which leaves me wondering why I see these systems pop up again and again? They must work for somebody, but from my (limited) perspective they don't seem a good fit for most people.

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.

Really? I find this rather surprising, because I would say about 80% of all of the work i’ve ever done didn’t have a hard deadline in the near future. People sure liked to try to invent emergencies, but they weren’t actually urgent.

> I find this rather surprising, because I would say about 80% of all of the work i’ve ever done didn’t have a hard deadline in the near future.

Factually, this is correct. In practice, it often is better to play along with the fantasy that the deadline is real.

I once got half-fired from a job because the deadlines were not, in reality, hard. All kinds of things went wrong in the project - from our team's side, from the (internal) customer's side, and from the company's side (outside of both our control). The project was very late. Sometimes I was fairly open about the deadlines not being hard. We all knew that even if I got the work done by the time they wanted it, no one was ready to consume our output for over a week after our releasing it - at various stages in the project - so we were "ahead" by many weeks.

By the end of the project, it was clear my manager didn't want me on the team. I got a terrible review that year where I was accused of causing delays. I challenged that notion, and we both agreed that had I done everything by the claimed deadlines, there would not have been any observable difference. The product would not have come out any quicker. Our delays were miniscule compared to the problems on the customer's side.

They still refused to change the verbiage on my review. Internally, the department does keep arbitrary metrics, and they want the numbers to be good even if there is no actual observable benefit.

Not all jobs are like that, but many are.

The one lesson I learned from that job and the one that followed: You can have similar jobs with the same pay, but the further you are from the customer, the more flexible everyone around you becomes. In the crappy job, we were quite far down in the manufacturing flow, and had little power to negotiate timelines. In the second job (same company), we were higher up in the flow, and more of this pressure was on people downstream from us.