I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Pomodoro, 2013 edition

  • submit to reddit

My story with the Pomodoro Technique started in 2009, and in 2010 I was helping my team in adopting it. We used a simple Gnome applet at the time, not even a mechanical timer, and set up some interesting sounds as the end-of-Pomodoro ring.

I've written about some tips I've distilled from my experience in these years. For example, there is the issue of working in the flow, which I usually explain during my talk; here is a written argument for why you want to choose between interruptions and Pomodoros.

One important concept of the technique is also the personal backlog, containing all your tasks and reminders, and the trade-off between throughput and latency in prioritizing them.

Now I have experience with the technique both as freelancer and from using it in two different teams. I've just performed my Pomodoro Technique talk for the third time at a European conference, at PHP Benelux 2013, so here are some updates from the new version of this talk.

The latest team tips

There are many ways in which you can use the Pomodoro in a team, even if not all of it buys into the idea: for our team at Onebip roughly half of the members use it consistently, while the others are free to choose.

Using a single Pomodoro for multiple people scales up to when you're 3 or 4: after that, it is too difficult to synchronize everyone's work.

However, you should definitely use the Pomodoro timer or another form of timeboxing (10' or 15') when the whole team is in the same room and committed to the same activities:

  • planning poker
  • retrospective or standup meeting (repsectively a few Pomodoros or a timebox of 15')
  • book club, or other training sessions.

We found that timeboxing these sessions and defining expectations at the start of each Pomodoro is beneficial even for the people not using it when working alone. It's a form of respect for the time of everyone participating in the meeting.

When dealing with constant emergencies and tickets coming from outside the team (the customer, our partners such as mobile carriers and merchants) we found that we could avoid interrupting planned development by creating a special swimlane in our board, the Emergency Room, and allocating 20% of the team to it.

The members currently assigned to ER, deal with all the interruptions for the team, and spend their time in no-Pomodoro mode. There is usually enough work to keep them occupied, but even if all tickets are finished early, they can dedicate their time to low priority tasks like minor refactorings and reviewing or improving documentation.

The rest (80%) of the team keeps working normally, on development of the selected user stories, so their Pomodoros are not interrupted and they do not even have to change tasks at the end of them.
If adopted consistently, the ER swimlane also prevents backchanneling, the anti-pattern of giving tasks to the team without passing from the product backlog and the prioritization: the product owner and in second line ER catch everything that is thrown to the team, leaving their colleagues freedom to work on what has really high priority. Especially in large organizations, the ongoing battle with backchanneling requires you to send everyone to the product owner and leave some of your people (the ER) to get these requests satisfied.

Some feedback that came up

There were some interesting questions from the audience that dig into what I didn't cover during the talk.

How do you deal with finishing a task early in your Pomodoro? When any part of a Pomodoro remains and you do not have very similar tasks to start, go for *overlearning: perform refactorings, improve the documentation of your interfaces, and invest a bit more in your code. If you allocated N Pomodoros for it, the task should be that important.

How do you deal with finishing a Pomodoro and still needing 5 minutes to complete a task? Add a full Pomodoro: it's better to have some slack instead of being rushed into finishing and *skimping on the definition of code. In the remaining time, you may write additional unit tests for error conditions, or run the full suite with end-to-end tests, or integrate in CI immediately.

Yet, if you finish whole tasks more than twice a day maybe you are breaking down them in too many pieces.

How do you deal with pomodoro breaks not lining up for your team? If the breaks are not enough to communicate, institute special pomodoros where everyone involved in the issue participates. Standup meetings are built for this: talk with other members of the team to help you in removing obstacles, but allowing parallel development throughout the rest of the day.

Really, you get 11-12 Pomodoros done in a day? That would be impossible for us, it's 75% efficiency. This is possible just because I have ER protecting me in these days: their efficiency by this definition, excluding tickets and operations tasks, is 0%; so we're not a team of hyperproductive robots.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Pietro Di Bello replied on Sat, 2013/02/02 - 5:43am

Hi Giorgio, 

thanks for your post, really interesting tips on the pomodoro!

Two questions:

  • how often the ER people rotate in the team? each day? each week? 
  • do the ER people work in pair?
  • if you use the breaks to communicate with the team, don't you risk to use the full 5-minute break thinking and communicating without really resting?
One action we adopted in the past is the (so called) "pomo-timeout": each member / pair can call a time-out, loading a 25-minutes pomodoro to talk of doubts, ideas, puzzles, and so on. Obviously, no more than two timeouts should be called a day, otherwise you should ask why there's so much uncertainty in the team :)

Giorgio Sironi replied on Sat, 2013/02/02 - 10:48am in response to: Pietro Di Bello

We try to rotate them every week, the problem is that if they have a story to close before entering ER they cannot (and shouldn't) abandon it. Right now they do not work in pairs, but also most of the team does not do so.

About the breaks, personally if I estimate the communication to take more than a minute I schedule a new Pomodoro with the person I have to talk with.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.