Pomodoro sauce for development teams

We recently started using the Pomodoro technique in our development team. Pomodoro technique is a time management method that specifies working in 25 minute blocks with short breaks in between. A 25 minute block is called a pomodoro. 

We have adapted it a little for our purposes. We work as a team in synchronised pomodoros and then have a mini standup after each. Each week we assign a pomodoro master that is responsible for managing the process - start pomodoros, keep time, count the completed pomodoros, etc. 

One of our team members, Steve Occhipinti (@steveocchipinti),  developed a handy web app to keep time and provide visibility to all team members. It can be found at http://pomodoro.stevenocchipinti.com/. The intention is to display the timer on a big screen to be visible to everyone in our area.

Working this way has had a number of benefits. In general the team is much more focussed. Individuals and pairs focus on one task for 25 minutes without allowing themselves to be distracted. We try to defer external distractions until the end of the pomodoro. Its easy to point to the pomodoro timer and ask someone to give you X minutes to finish what you are busy with. Also, IRC and emails do not get attention until the end of the pomodoro. 

Because we have a quick catchup every 25 minutes, everyone is across everything going on in the team and everyone can provide input on whatever is being worked on. Our solutions tend to be very well thought through.

We tend to waste less time on implementing something that will not work or is suboptimal. On quite a few occasions a pair worked on something for one pomodoro, then discussed it with the team only to realise that what they are doing will not work. That is at most 25 minutes wasted, without pomodoro that could have been a whole morning wasted.

We try to achieve something every 25 minutes. This leads to breaking problems into smaller tasks. Working on smaller tasks leads to very focussed thinking and much greater sense of achievement. There is the danger of getting lost in the detail but our mini standups after each pomodoro tend to counter that.

We have found that multiple teams can work together on the same story in very close code proximity to each other. This is because our tasks are are small and we continuously discuss what we are working on. This has a great influence on the flow of cards on our wall. 

There is a lot more to explore in this space. I think as a team we have just scratched the surface of adopting this way of working and reaping the benefits. Working this way is a discipline that needs to be practised. What is clear to me is the power of a team working together in step to tackle a challenge. I think this is very well understood by sports and military teams. I am keen to explore further how we can apply this to software teams.