Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Themed days, Timeboxing and why you should use them

jamalx31.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Themed days, Timeboxing and why you should use them

#11

Post by spiffytech »

colechristensen wrote: post #8
spiffytech wrote: post #4

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…

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.

The environments I work in presume or dictate my task ordering and priorities according to the needs of my team and the broader business, with no concern for the restrictions imposed my my personal task management syntem. My boss/team expect me to work on The Things We Agreed on, in The Order We Agreed On, and I'm expected to start as soon as I wrap up my WIP from our last round of planning.

Sometimes I get deadlines, and sometimes it's more that the team expressed confidence we could do certain tasks in a certain amount of time each, and then someone went and made a GANTT chart planning our whole next quarter, even though everyone knows it'll get changed up in a couple weeks, because the business needs to make related plans. Then the schedule is treated a plan and not a prediction, and people get frowny when you don't hit target dates because they're also being held to not-really-plans they based on your schedule.

There are plenty of legitimate (and illegitimate) reasons the business would want to hold you to a date pulled out of thin air, but for this discussion the important point is that the entire system is predicated against rogue individuals making unilateral plans to prioritize or delay work for opaque, arbitrary reasons without the involvement of the stakeholders who presumably were the impetus for those tasks. I.e., "theme days", 1-3-5, etc. don't seem workable in the environments I've worked in.

Re: Themed days, Timeboxing and why you should use them

#12

Post by justtart »

gdsdfe wrote: post #9
jasonladuke0311 wrote: post #5

Articles like this are so ridiculously tone-deaf. As a working stiff, I can't reasonably shove all communications into one day and spend another writing code. I suspect the overwhelming majority of readers of this site are in a similar position.

I don't think this was meant to be a step by step guide, it's more of a "here's how I built my system and why you should build one for yourself"

Yes I saw it the same way. I think the main takeaway is task-switching causes inefficiency so try and reduce that. He offers his way but do something using that idea that works for you.

Re: Themed days, Timeboxing and why you should use them

#13

Post by bigmattystyles »

I can’t help but think this is a result of capitalism gone awry, the need to never let any time be wasted, to the point of scheduling time with ones kids. And I’m not far left of center, but yeesh. If you enjoy living life this way, more power to you. When I was younger I might have thought this sounded great. Now that I’m touching 40, it sounds like a self-made prison.

Re: Themed days, Timeboxing and why you should use them

#14

Post by colechristensen »

spiffytech wrote: post #11
colechristensen wrote: post #8

Earlier quoted context omitted.

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.

The environments I work in presume or dictate my task ordering and priorities according to the needs of my team and the broader business, with no concern for the restrictions imposed my my personal task management syntem. My boss/team expect me to work on The Things We Agreed on, in The Order We Agreed On, and I'm expected to start as soon as I wrap up my WIP from our last round of planning. Sometimes I get deadlines…

Well usually those kinds of things would be not just how you worked but discussions had with the team about how work got done. More or less all of the environments I have been in how work was done was an open discussion with the team and management, not just something dictated to us.

Re: Themed days, Timeboxing and why you should use them

#15

Post by spiffytech »

colechristensen wrote: post #14
spiffytech wrote: post #11

Earlier quoted context omitted.

The environments I work in presume or dictate my task ordering and priorities according to the needs of my team and the broader business, with no concern for the restrictions imposed my my personal task management syntem. My boss/team expect me to work on The Things We Agreed on, in The Order We Agreed On, and I'm expected to start as soon as I wrap up my WIP from our last round of planning. Sometimes I get deadlines…

Well usually those kinds of things would be not just how you worked but discussions had with the team about how work got done. More or less all of the environments I have been in how work was done was an open discussion with the team and management, not just something dictated to us.

I suppose I'm not speaking clearly here. Generally yes, my tasks come from a combination of my team pushing priorities up from below (ideas for improvements, paying down tech debt) and the business pushing requirements down from above (strategic/financial objectives, promises to customers). Prioritization and assignment is usually a group discussion with everyone relevant.

The fact that priorities and schedules are decided with input and consensus from lots of people who aren't me is the crux of my point. The article is about personal task management. It, like any number of similar articles I've read, offers a system that presumes I can pick and choose what I work on today based on metrics of my own choosing, instead of being bound by a decision made with other people. The article expects I'm in an environment where nobody cares if I push tasks back 2, 3, 4+ days for reasons that have nothing to do with the project or team or business, but because of arbitrary restrictions on when I allow myself to do certain things. Unless I can make a business case that "theme days" or similar systems benefit the business, the business just sees needless, disruptive delays it didn't authorize.

Re: Themed days, Timeboxing and why you should use them

#16

Post by hliyan »

marcus_holmes wrote: post #2

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 deadlin…

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.

Re: Themed days, Timeboxing and why you should use them

#18

Post by hliyan »

spiffytech wrote: post #4

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…

This is probably due to differences in the schedules of "makers" vs. "managers" [1]. If you're a one-man operation (which I believe the author is), this approach is easy. If you're an individual contributor within a team, it's a bit harder. If you're a team lead or a manager, it's even harder. I'm an engineering manager and if I try to timebox a certain type of task into a specific day of the week, my teams are likely to get blocked until that day arrives.

[1] http://www.paulgraham.com/makersschedule.html

Re: Themed days, Timeboxing and why you should use them

#19

Post by Qwertious »

balfirevic wrote: post #7
RHSeeger wrote: post #6

Earlier quoted context omitted.

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

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

Re: Themed days, Timeboxing and why you should use them

#20

Post by 1123581321 »

spiffytech wrote: post #15
colechristensen wrote: post #14

Earlier quoted context omitted.

Well usually those kinds of things would be not just how you worked but discussions had with the team about how work got done. More or less all of the environments I have been in how work was done was an open discussion with the team and management, not just something dictated to us.

I suppose I'm not speaking clearly here. Generally yes, my tasks come from a combination of my team pushing priorities up from below (ideas for improvements, paying down tech debt) and the business pushing requirements down from above (strategic/financial objectives, promises to customers). Prioritization and assignment is usually a group discussion with everyone relevant. The fact that priorities and schedules are d…

Is all your work same-day deadline? If not, you can at least plan some part of your day for your longer-term work. Start somewhere.

Even if all your work is same-day, look at whether it can be sorted in some way.

If it can’t be sorted, box in some time to work on how to stop the firefighting. :)

Post reply on HN