Why a Pomodoro helps you getting in the zone

When I enter the zone, I get really focused and efficient: I can code a Unix implementation from scratch if you then leave me at the keyboard for a while. I don't want to be interrupted. How should I use Pomodoros? They last only 25 minutes.

The answer to this question is well articulated, and to understand how the Pomodoro Technique works, you have to know that it must deal with external and internal interruptions. While internal interruptions are usually absent during a flow experience, external ones can't be controlled easily.

Thus, the Pomodoro technique isn't about forcing interruptions on a programmer, but about handling and programming them, and not being dominated by external conditions.

External interruptions

External interruptions are a fact of like: you all must communicate as a team, so you can't hack all the time alone on your office computer. Someone is going to ask you how module A works, or in what state class B is, or even how you should call routine C correctly.

Often, the ones that otherwise would be the most proficient programmers are constantly interrupted and can't get focused on their tasks. It may also be the case that the points of contention are the people who are repositories of knowledge about the domain or the application, the ones who can save you an hour of work, if they could only give you a quick answer to a quick question. As a consultant, I'm often busy learning about the codebase and its related domain (restaurant, school, taxes...), and I have to make a lot of questions to verify my assumptions and crunch knowledge. If I wandered in the office interrupting everyone for asking clarifications, I wouldn't be a great help for my colleagues.

How Pomodoros can solve these issues?

Pomodoros are not interruptible (25 minutes of pure focus), but there are short pauses between them. Interactions between members of the team are intercepted and captured, then left to be answered when everyone is willing to communicate. You have two solutions to handle the queue of collected questions:

• for quick ones, you can just use the break between Pomodoros. However, a large slice of this break shouldn't be related to the work at hand at all - this is the only way for such a short pause to be effective on your tired mind. If you continue mumbling on your last task, you won't be able to substain the Pomodoro rhythm for long.
• You can setup group Pomodoros instead, where the whole team gathers for a standup meeting or for asking questions to each other. This periods of interactions are organized so that some flow time is left to each developer every day.

Feeling the rhythm

You may feel that when you get very productive, in the zone, in the flow state of mind, whatever you call it, you shouldn't be interrupted every 25 minutes. In fact, getting in the zone will typically take 5 to 10 minutes for a programmer who does not manage his time.

However, working for hours at a time without interruptions isn't always the most clever solution.

First, you keep others from completing their work if they are depending on you for an answer: you can't communicate if you remain for hours in your isolation zone where you crank out 2,000 lines of code. With a simple phrase, you can solve a colleague's problem that he may spend hours to tackle by himself.

Second, there is no reason to believe you're not very productive in a single person morning-long flow, but you're trading off effectiveness (doing the right thing) for efficiency (doing the thing right). A Pomodoro interrupts you just enough to keep measuring your current spent effort and make sure you're not consuming your energy and time on a module which is not prioritary, or you're not refactoring a whole component of the application when it may be thrown away thereafter to explore a different solution.

Pomodoro breaks are a natural feeback that stimulates you to check your effectiveness, and not your ability to build something that may not be used at all. Agile methods are usually based on timely feedback from the customer to avoid just this lack-of-effectiveness mindset where you code the most powerful webmail interface of the world, but the client would rather have had a good spam filter transparent to his Thunderbird clients.

Third, and finally, I have noticed that you can shape your development process differently from the classic full afternoon session, by thinking of your time available in small discrete boxes instead of a continuos stream. When we started using Pomodoros in my last company, the most common complain was that when a Pomodoro rang, programmers had to annotate what they were working on to resume their half done work in the next Pomodoro.

I experienced this difficulty myself when starting out with timeboxing, but the evolution of my working process has solved the issue. I now organize my tasks in timeboxed whose length is of some Pomodoros, just like a project manager divides the client requirements in user stories whose size is measured in points or ideal hours. I also break up the current task in subtasks that are assigned and shifted between the allocated Pomorodos: I stopped thinking of time as a continuos resource and started treating it like a discrete one.

An example (if you want to read only one paragraph, read this)

A simple example to follow: If I had a two-Pomodoros story to implement, I would attempt to never have not working code on the end of the first Pomodoro. I'd rather divide the story in a basic version and an advanced one, and then operate incrementally by implementing the basic version in the first Pomodoro and expanding on it in the second one (Keep it releasable, isn't it the right motto?).

In this time management practice, tasks are spread over Pomodoros so that the 25-minute timebox become a natural cycle, with a working period that bootstraps in the first minute of the Pomodoro, reaches the Zone shortly after to produce a solid 20 minutes of insanely focused work, and ends up with some minutes of refactoring and overlearning that lead to the end of the Pomodoro (the percentages may vary.) This final minutes can be cutted or expanded to make up for changes in the main part of the Pomodoro, whereas details can be moved between the basic and advanced use cases responding to the estimate changes.

Moreover, techniques like Test-Driven Development make really easy to reenter the flow, since you always know what comes next: one of the three phases from the Red-Green-Refactor mantra. However, the timeboxing of Pomodoros is really crucial here, because you know that no one will disturb you in the next 25 minutes, and that you can't get a distraction until the break arrives.

Summing up, if you feel the Pomodoro ring is interrupting you at the wrong time, you're either not paying attention to the timer until it's too late, or not breaking up your tasks to fit the time you're allocating. Either way, you now know that you can manage your time not to be a slave of your lunatic Zone, but to conquer it and experience flow many times a day.