Since we started our SCRUM series, we've received some mails about eXtreme Programming. Are you keeping on it? Can we use XP along with SCRUM? Where XP practices are placed inside SCRUM process?

First of all, we should clarify some aspects:

• eXtreme Programming: it is a development methodology made of twelve programming practices (and some of them about planning). It is focused on writting adaptable code minimizing error rate.
• SCRUM: it is a planning and tracking project methodology (software projects, engineering projects or gardening ones :) with practices focused on managing the team, tasks, features, etc. It doesn't explain how you must write you code (gardeners don't write code!), but it explains how you can arrange your team to lead it to safe harbour.

So that, each stuff should be used for its purpose.
Thanks to SCRUM, we manage to track continuously our project, bringing forward
unpleasant surprises, in order to give enough time to respond to them. We
achieve a nice working environment, giving responsibilities to each team member, and
trying to don't create stress between team mates (although some of them are unavoidable).

Even though, whether we used only SCRUM in order to manage our project, we don't have any control for whole programming side. How we should write our code? Which tasks should be done before coding? And then? At this point, we can introduce XP. With eXtreme Programming, we have an agile methodology focused on programming, which fits perfectly with filosophy suggested by SCRUM. Perhaps, due to this fact, the SCRUM + XP combo is been applying successfully inside several Microsoft projects and even inside some games companies.

So, along with all SCRUM stuff we've talked about, we're applying next XP practices:

• Planning game: more or less it's the same we're doing during sprint planning:
  product owner suggests new features to be implemented and development team estimates them.
• Small and frecuent releases: therefore we're using 1-2 weeks sprints instead of 30 days as formal SCRUM suggests.
• User histories: all features we write down in product backlog are, more or less, user histories.
• Simple design: the least code you write the better. We try to avoid superfluous features and complex architectures. Remember XP motto: "the simplest thing that could possibly work".
• Unit tests: we go on with TDD way: write tests before code, at lest, whenever it's possible.
• Refactoring: our code base is under continuous evolution, trying to simplify and clarify it.
• Continuous integration: we build frecuent and automatic releases, running all tests.
• 40 hours week: it doesn't mind trying to set up a nice work environment if you're exploiting your team.
• In-place customer: our product owner is always available for solving questions.
• Programming standards: we're following Sun's Java code conventions.

But there're some practices we've abandoned:

• Pair programming: SCRUM doesn't limit us in this side. During your daily
  scrum, two programmers could be assigned themselves to one single task, if
  they prefer working together. Actually, we don't do it, except if someone is in
  difficulties.
• Collective code ownership: we don't let private modules, but we do with
  module responsible. Everybody could change code from all modules, but each
  responsible should aprove or at least be up to dated.

In short: SCRUM alone could be insufficient, due it doesn't give us guidelines about approaching programming tasks, so mixing it along with eXtreme Programming, we get a better and more complete agile methodology.