So far, the talk I attended at Agile 2009 that has had the most impact on me was Renzo Borgatti’s talk on the pomodoro technique:

I’d heard a bit about the technique before, enough to know that it tells you to break your work up into 25 minute chunks and to try to really focus during those chunks, avoiding distractions and interruptions. It turns out that there’s more to the technique than that, however: it gives guidelines about breaks between chunks (3-5 minute breaks normally, longer breaks after every four chunks), there’s a whole planning and estimating mechanic you’re supposed to use with it (starting each day estimating your tasks in terms of pomodori, and reviewing your day at the end), and there are also mechanisms for tracking and actively tabling your interruptions.

What really sold me about the talk, though, was that, 25 minutes into it, a timer went off, and we all took a break for a few minutes! We took another break 25 minutes later; I think that it’s a great idea to break a 90-minute presentation into three chunks like that. As it happened, I’d been feeling over the course of the conference that I hadn’t been getting enough done over the evenings; so, that evening, I decided to give the pomodoro technique a try, and really focus on things for 25 minutes at a time.

Which turned out to work remarkably well: I probably got as much done that evening of the conference as in the other four evenings put together. Despite which I didn’t use the technique over the next month or so: I was pairing on a project in my last weeks at Sun, we were doing quite a good job concentrating as it was, and it didn’t seem to be a good time to introduce something new.

When I started work at Playdom, though, I picked up the technique again, and I’m glad I did. When I describe the technique to other people, one frequent concern that comes up is: doesn’t the timer going off interrupt your flow? For me, though, my problem is almost always too little flow rather than too much; and the pomodoro technique works great with that. I can stop myself from wandering for 25 minutes if I try, and I know I have a little release valve coming up in the not-too-distant future if I need one. And it occasionally happens that I’m banging my head against something unproductively and need the cooling off period between pomodoros to get myself thinking that I really should take a different approach. Also, it can be a big help if the next task seems frightening in some way: you’re not faced with wandering through something unknown and probably unpleasant for an unbounded amount of time, you’re faced with spending 25 minutes trying to shed a bit more light on your current situation, which is a much more palatable prospect. And I think the explicit guidelines for both shorter and longer breaks are helpful for me.

I’ve tried other aspects of the technique as well; they have had benefits, but I’m less sold on them. The planning period is a helpful reminder that I should think about all the different things that I’m considering working on (my next actions for my various projects, in GTD speak), and pomodoros give me permission to carve out a bounded amount of time to work on tasks that are important but not urgent. Having said that, I haven’t found much of a benefit from the actual process of estimating how many pomodoros a task will take at the start of the day: it doesn’t seem to be solving any problems that I have, and I have other mechanisms for telling myself when I’m getting stuck. (E.g. if I’m not doing multiple git commits over the course of a pomodoro, that might be a sign that things are going well.) So I’m stopping that for the time being.

And there’s one aspect of the pomodoro technique that I’m actively dubious about. One of the core rules is that the pomodoro is indivisible: if you don’t spend the whole 25 minutes working on what you planned, then it doesn’t count as a pomodoro, and you’re strongly encouraged to have as many pomodoros count as possible. There’s a bit of wiggle room here—if your plan at the start of the day has tasks that you think will take less than one pomodoro, then you can combine multiple of them in your plan to make a single pomodoro, and if you finish a task within the first five minutes of a pomodoro, then you’re encouraged to cancel the pomodoro, with the feeling that it was “really” finished in the last pomodoro. If you go beyond the first five minutes, though, you’re supposed to stick it out until the timer rings: in particular, the technique recommends that you spend spare time overlearning, delving into the area in question more deeply than you would otherwise.

Don’t get me wrong, overlearning is a great idea: it’s a similar philosophy to always doing a bit of refactoring once you’ve got your code working. Except that the pomodoro philosophy is different: you don’t always do it, you only do it if there’s time left on your pomodoro, and the amount of overlearning you should do is proportional to the time left. And that just seems bizarre to me.

Take this blog post, for example: I have a pomodoro timer running as I type this. If the timer goes off when I’ve got it done but not properly edited, I don’t want the pomodoro technique encouraging me to hit publish so that I won’t have a big gap to fill in my next pomodoro. After I’ve hit the publish button, probably a bit of overlearning wouldn’t be a bad idea—e.g. this blog post is suggesting an idea for another blog post I could write, so maybe I’ll take some notes on that. But that sounds like a good idea no matter how much time is left on the pomodoro; and those notes will probably take about 5 minutes, so what am I supposed to do if I turn out to have 15 minutes left on my timer when I hit the publish button?

So that doesn’t make much sense to me. The result is that I’m not feeling any guilt about either canceling a pomodoro if I finish a task in the middle of one or about not canceling the pomodoro and launching into a second task without a break in the same pomodoro. (Hmm, I probably should have a preference for one or the other of those solutions, maybe the former?)

But the core idea seems sound, and many of the surrounding ideas have seeds of something that I quite like (e.g. the concept of overlearning), even if I’m not convinced by their details.

Some resources I’ve found useful:

Post Revisions:

This post has not been revised since publication.