Two hearts are better that one...

A technique we are using these day, along side with the Pomodoro techinque time boxing, is Pair Programming, even if we are using it in a very unstructured way. As with every agile programming technique, this one revealed its usefulness, but has some 'dark corners'. What is Pair Programming ? Essentially it's just two people working togheter on a single workstation, sharing a single keyboard: one programmer (the driver) write the code, the other (the observer) review the code, trying to find out potential problems, bugs, bad code or thinking about possible improvements in code or design.

Some researches and studies have proven that pair programming reduce bugs of about 50%, with about a 15% cost increase (which is good, as bug fixing is much more costly if done at a later time, maybe by a developer who does't know the code...). A nice side effect is just that code and design decisions become shared among the team (at least two persons...), reducing the management risk (no programmer is a bottleneck, being the only one to know critical parts of the system, anymore...). There are obviously other benefits, like training on the job for less experienced developers, less distractions, better design and coding due to double knowledge and experiences...

Along with all these benefits, there are some drawback (as usual...).
According to the tries we are doing we saw that not all activities are good for pair programming. For example, there are some jobs that would be made exactly in the same way by both developers (as a result of common experiences), where the design is well known and the code quite consolidate, or some repetitive tasks. In this case the bugs are naturally few, and are quite easy to resolve. So, the contribution of the observer is quite low. The risk is to bring some boredom to the pair, and the attention in the long term is reduced by the pair practice instead of increased.
Another important thing to remark, which is not always kept in the right consideration, is that not all developers like to work for the whole day in pair. Some developers like to work alone, at least for some time, when trying some new technology or when doing some common task.

Another thing to think about is how to apply pair programming along with the pomodoro technique. Working for 20 / 25 minutes side by side brings the natural question of how to organize the work: for example is good to make an advance design, shared by the two, before writing the code ? Or is better for a developer to start coding while explaining his point, and then to review the design together ? Or every developer must try to prove that his design is good before starting ? All these approaches can lead to good results or to bad results.

In the next days we will try to use some of these approaches and to find out which ones work better for our project, a first pace in the road to agility.

Working with a pomodoro...

I was recently at the fifth Italian Agile Day, where there was an interesting discussion about the 'rigid' use of agile techniques, in particular about the Pomodoro technique. I knew this practice but never tried it seriously, so in the following week started to use it with my team (along with other techniques we already used, as pair programming...). I will not explain the pomodoro (by the way...'pomodoro' means 'tomato' in Italian...), as there are a lot of good resources out there in the Web, but want to express some random tougths about it:

- It really helps you to focus on your work and to decrease your distraction

- The standard time of 25 minutes for a pomodoro is not always optimal...I think this technique will be more effective not using always the same pomodoro time ( just a 5 minutes variation can do the work...). Obviously you change the pomodoro time before starting it, not during it. The gratest drawback of not having a constant pomodoro time is that you loose some precision in the extimation phase, as old pomodoro times can vary, but you gain in using more effectively your time

- It's not a capital sin if you go on working after the pomodoro rang, if just for a few minutes (3 - 5 min). In my experience sometimes the last minutes of a pomodoro can be the most productive, and there is no evidence of a bigger number of mistakes as someone (the agile radicals...) say. By the way, my pomodoro rang as I was starting writing this third point...

Maybe after some more use I will become more radical, but I always like flexibility, and don't think the same exact way is good 'as is' for everybody...
(total writing time: 1 pomodoro + 4 min...I'm slow when writing in English...)