Monday, December 8, 2008


Øredev was a fantastic conference! I can't stress that enough! So why haven't I blogged about it? Well, there's so many blogs already about it (google on "øredev" and "blog") so I don't really know how to contribute more content, just repeat what's already been said. That's why.

Instead, I'm going to write a note on one thing that I've taken with me from a talk at Øredev: the Pomodoro Technique. It's essentially a technique that takes agile to the personal productivity level: working in small and timeboxed iterations (25 minutes), with short breaks (3-5 minutes) between each iteration and longer breaks (15-30 minutes) between 4 iterations in a row. Oh, by the way, an iteration is called a pomodoro, italian for tomato. Why tomato? Because the inventor of the Pomodoro Technique, Francesco Cirillo, used an egg timer formed as a tomato during the early phase developing the technique. Further, each day starts with planning and ends with collecting and visualizing the data collected, ready to be analysed and retrospected.

So, the idea is very simple, but of course there a lot more to it. What you should start with is to read Staffan Nöteberg's Pomodoro Technique in 5 minutes. Actually, when the videos from Øredev get published, you should start there: Staffan Nöteberg did an excellent talk on the Pomodoro Technique, sometimes using hats and dolls to illustrate his points.

There's also a quite large pdf by Francesco Cirillo available, but I haven't had time to read that one yet.

I've just tried out the Pomodoro Technique myself for a couple of days now and some days have contained more pomodoros than others. Basically, I bought an egg timer for 25 SEK (around $3) and started with the fixed timebox part of the technique and logged the results. The second day I started to do some naïve estimation for each task. I also started with post-it notes for tasks, my personal pull system.

If you follow and read the links in this post, you'll see that I don't really do that much of the Pomodoro Technique! That's ok with me, I'm aware of that and that's why the title of this post is "PomodoroButtButtButt" (paraphrasing Jeff Sutherland's ScrumButt). I'm just getting used to the habit though, and making the human beings around me used to it as well. No need to be extreme here..

By the way, I'm still recording my workday in TimeSnapper, now TimeSnapper Professional. But that's a future blog post.


Peterh said...


Back in the days, this was a natural way of working. I guess of because everybody got tired of what they were doing and had to take breaks. But seriously, this is kind of retro IMHO.

I also think that this is scalable. That is, if your working four days on one problem, a day of from that problem is wise. As well as weeks /months/years/decade (yeah people do that!)

Gustaf Nilsson Kotte said...

Yep, you're right Peter. Breaks are retro. But it's the eggtimer thing that makes PT "fresh", in my eyes. Further, PT forces you to deal with internal/external interruptions, something I didn't blog about this time. And there's even more to it, i.e. estimation and reducing complexity through decomposing larger tasks. Nothing new, of course, but nicely packaged.. :)

Christian Genne said...

I'm still having problem using PT in combination with multitasking.

For example, I start a pomodoro cycle, but after say 10 minutes, I need to build some stuff. In c++, building means "waiting for several minutes". Now, should I just wait for the build to complete, or should I start working on another task? Or should I take a 10 minute break (to for example write this comment :))? If I take a break, does the iteration still count?

Perhaps there are no right answers, you just need to experiment until you find a solution good enough for you.

Also, I just found out it's real hard getting your coworkers to respect your pomodoro iterations... but that's another problem ;)

Staffan Nöteberg said...

Hi Christian,

These are really challenging questions.

1) Is it impossible to investigate upcoming problems during the building? I'm talking about the next little issue in this particularly activity. Like "if the building does not fail, the next thing in order to get closer to activity-completed is to add the xyz method. How will I do that?" That is, without switching activity.

2) About counting: first you should define exactly what you are measuring with your X. The out-of-the-box method is measuring how many 25 minute effort you have completed. So if you decide to switch activities during building (which I do not recommend) you could still count the 25 minute effort as a Pomodoro. To count Pomodori with breaks included can be very confusing. I would avoid that. A clear definition of the X is important in Pomodoro Technique.

3) And about coworkers: You need to define your interruption metric as well. If they interrupt you with a work question – perhaps you should not count that as an interruption, or perhaps you should. Or maybe you should improve your skills in inform-negotiate-plan-call, which for sure is hard. Or as a third option: you could decrease your iteration length to 15 or 10 minutes. I think everybody needs to be pragmatic here to figure out what rules are best for the team and not sub optimize.

I agree that experiment is the answer. That's why Pomodoro Technique has this retrospective every single day – to acclimatize the method to your particular circumstances.

Christian Genne said...

Hello Staffan!

Building for me often means "checking that the code is valid", and so I would like to avoid starting writing a new function before I know the current one works. Another problem is that when my computer compiles, it more or less takes up all system resources, making it hard to work in Visual Studio on other tasks.

Also, sometimes compilation can take up to 20 minutes (if I need to recompile everything). Perhaps I should try starting such a build just before a cycle completes? The next cycle, if the build still continues, I can start working on another separate task. Would that work?

I might try out shortening down my cycles to 10 or 15 minutes, so that I can switch tasks more often, if I need to wait for compilation to complete. Then it won't matter that much when a coworker interrupts the cycle (which happens a lot).

I'll try experimenting some with timing, and the definition of "a complete cycle", until I find a solution matching my needs!

Thank you for your answer!

Joakim Ohlrogge said...

Wow, long compiles! That is a long time to wait for feedback. I would imagine that you think twice before you start compiling.

Isn't this one of those things that are really illuminated with the Pomodoro technique? Exactly how hard it is to focus for a continuous X minutes, which things that tend to get in your way.
It's not like those things are not a problem without pomodoro, you're just more aware of them with pomodoro.
Some things you can probably do something about, others you can't. For instance, moving from C++ to something else is probably not an option for you. It might not even address the real problem. But modularizing your code so that you seldomly or never have to rebuild the whole system might be. And you would have some idea of what this effort would gain you in terms of productivity. If nothing, don't do it, if a lot... what are you waiting for :) If teammates or managers need to be convinced you really have some metrics to back your arguments.

As Staffan said, the pomodoro technique allows some tinkering so that it works in your particular setup. But always be sure you understand the tradeoffs with doing so. Sometimes your setup has problems. Sometimes you can remedy some of those things, sometimes you can't.