Pomodoro, 2013 edition
Pomodoro, 2013 edition
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
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.
Opinions expressed by DZone contributors are their own.