Rough Sea Games

Please check my last blog entry for the background to this post.

This time I will focus a little bit more on the XP side and explain what exactly we practise here.

Step 5 – regular pair programming sessions

Unfortunately, we are not able to pair program very often. We currently try to meet up once a week and have a 3 – 4 hour pair programming session. At this session we go through as much code as possible and talk about the architecture and the current design flaws. We try to get hold of the worst things we did while coding on our own, and start refactoring on the spot to learn a little bit more of each other’s code.

Sometimes pair programming is not possible because people live too far away, so we are looking into remote pair programming. We have not established it yet, but have collected lots of information. Please checkout Doug Alcorn’s Blog or Andrzej Krzywda’s Blog for some field reports.  We will probably try VNC combined with Skype, because Flash Develop (our current IDE) does not have any collaboration support yet.

Step 6 – collective code ownership is even more important

CCO means that everybody can make changes and fix bugs anywhere in the code. There is not a single line of code in the project that is under the control of only one person. A good description of code ownership can be found at Martin Fowler’s Blog. As mentioned, we know each other very well already. If this weren’t the case,  CCO would be much more of a hassle.  A lot of trust and a lot of communication is necessary and coding divas are not allowed. Fortunately there is no diva in our team yet.

CCO is key for the success of a distributed team, because it helps to spread the knowledge of the code, systems and architecture of the project among team members (as pair programming does). Programmers will perform much better when they know how to use a specific system and how to adapt it to their needs. Not everybody on the web thinks that CCO is a the best idea ever; please check Ralf Sudelbücher’s Blog for a different perspective.

Step 7 – consistent and very regular refactoring

This, you might think, is not something specific to distributed teams — but I’m here to tell you you’re wrong. Sitting at home on your own, without a team mate next to you who reminds you to fix that broken window now (kudos to the pragmatic programmers), makes refactoring much less likely.  The code quality can decrease quite fast for a distributed team if the programmers do not really care about it. What to do?

It’s actually quite easy. At each pair programming session, we identify broken designs and foul code and write our own refactoring stories. We give those stories the highest priority in the backlog. It’s very important to keep these stories as small as possible, because refactoring can sometimes get out of hand and this should be avoided. We only put the most relevant refactoring tasks into stories, because otherwise the backlog gets too confusing.

Step 8 – keep up the motivation

This is by far the most relevant and hardest part for a team which does distributed work, especially when there is no investor yet. The 7 steps already described help a lot to keep up the motivation when done right, but that’s not everything which can be done.

Try to establish a culture of praise and respect in your team. As soon as people start blaming each other,  motivation will ebb and the team will break apart. If possible, the whole team should meet on a regular basis, as this helps a lot to improve communication and trust.

It’s also very important to have progress in all areas, not only the development part. Somebody has to care about investor relations, marketing issues, team building, business development etc.  The team needs to believe that the product will be a success and that it is worth selling to the customers.

That’s it for today. I hope I could shed some light on our Scrum and XP processes and if you have some improvements or suggestions for us, I would be very happy to hear them.

Popularity: 6% [?]