Pomodori for Craftsmen
I received good questions and feedback about Pomodoros Monday night at the Software Craftsmanship Group. Before I dig the details you might want to check the slides and the video (coming soon) on Vimeo. The slides aren’t meant for plain reading, better if you wait to see the talk to understand the content. On my way home I thought about all the good discussions we had and here are my takeaways for the night.
Pomodoros and GTD. The Pomodoro Technique (PT) shares with GTD the mechanism to handle interruptions. In PT you “Inform, Negotiate, Reschedule” which is similar to the inbox mechanism of GTD. The principle is in both cases to move the interruption into a task and move it for prioritization to the queue. Erik asked how long should an interruption be to void the current Pomodoro. In theory the interruption should be negotiable in a couple of minutes to maintain active focus on the Pomodoro. In practice I found my self executing the interruption instead of negotiating when the interruption is short enough. The same happens in GTD for tasks that can be executed right away. It works good for me, but I suggest the PT beginner to learn first how to negotiate effectively and then decide if to apply exceptions like execution without negotiation.
Uncle Bob remembered quite well the exercise he did with Francesco the PT inventor at Agile2001. Francesco gave the following exercise: when the Pomodoro rings, write down in a single word what you’re doing (for example developing, design, refactoring, planning, etc.) and that is the “tag” for the Pomodoro. I’m writing a complete sentence and tags for the Pomodoro just worked which is more accurate. But I understand that as a statistic, writing just what you’re doing on minute 24 and 59 secs is perfectly fine. This is the reason why in EasyTracking there are reports about the percentage of time spent refactoring.
Uncle Bob also asked if I try to accomplish a specific sub-task before the Pomodoro rings. Let’s say I have a 4 Pomodoros task and I’m working the second Pomodoro. Do I try to see a portion of the 4P task that can be done in just 1P? The answer is not on purpose. The surprise is that many times that is exactly what happens but without actively searching for it. I discourage you to search for such a subtask actively because that is just over-planning.
Paul told me that in his opinion there is no strong reason for collecting Pomodoros as a team practice in a common repository. I always considered the “central collector” a powerful reporting solution but if there is already a good tracking in effect on user stories there is no need to add more process plumbing. I can see the risk: developers are already busy with TDD and refactoring, Pomodoros and micro-planning and that’s clearly enough. Pomodoros belong to the personal domain, or pair domain, where there is need for flexibility.
I forgot to talk about a lot of important things. For example to stress how important is to adopt the PT gradually because of the fine tracking which add complexity to the daily routine. For at least a week is necessary to just measure Pomodoros without planning. Planning and estimates are the second step. I know several examples of initial enthusiasm about the technique which is gradually abandoned when external pressure goes up. I also forgot to talk about common pitfalls: forget to start/stop the timer or to track the past Pomodoro on the inventory.
Hopefully I was able to remember all the most important questions and ideas. I’d like to refine the presentation and do it again. Agile2009 could be the next one.
3 years ago