I'm a firm believer in the idea that a good development methodology always has two parts intertwined.
The first part is the Process. That's basically everything that has to do with the customer, requirements, iterations, planning etc.. . A process like Scrum is a perfect fit for this part.
But the second part is the technical supporting practices.
Things like Unit testing. continuous Integration, TDD, Pair programming and basically anything that states how developers work on a day to day basis is part of that.
Following a process like Scrum is a good start, but if you take a look at the ideas behind Agile Development you quickly find that process is not enough. Something technical has to be there to make sure the process is indeed feasible.
Example: Handle requirements that keep changing (Embrace Change)
It doesn't really matter how well you work with scrum, how short your iterations are and how simple your backlog is. When you need to change a part of your code because something has changes in the requirements or your understanding of them, you're faced with the prospect of breaking existing code. If you break existing code and don't know that you did, it won't be long before your iterations and changes wreak havoc in your code base and your development time per feature will slow down considerably because you keep bumping into unexpected bugs during testing (hopefully!).
Unit tests are a great example of a technical practice that supports an Agile process. If you had unit tests on that project you could change the code and see the places where you broke something and fix them quickly. you'd have a much easier time going into the code base and start messing with it knowing that you know the consequences of your actions.
Embracing change over time without unit tests is next to impossible, no matter how small your iterations are.
What about continuous integration? THe idea is to get feedback quickly that you broke something in the code base. If it takes you a month to find out you broke someone else's code or it won't compile at all, that's a lot of code under the bridge that you need to sift through to find the problem. If your iterations are short you can't really afford to have such a lengthy integration phase. it needs to be every day or you risk finding yourself between a rock and a hard place soon.
(Automated build with FinalBuilder)
Smaller iterations are next to impossible without a good integration\testing\build cycle.
Jeremey Miller posted that people seem to like Scrum over XP. People need to realize that Scrum and XP are two sides of the same coin. Successfull companies I've seen implemented parts of both, or a variation of them.
I like to call these hybrid processes ScrumP (Scrum-pee but in a good way!) as the combination of both of these methodologies and the idea of combining process and technical practices.
BTW, in the comments to Jeremy's post Dave Woods suggests that people like Scrum of XP since it's a easier Sell. I wholeheartedly agree. Managers really don't like to hear the word 'Extreme" when all they want is for people to just work better. But I think "selling" Scrum and then adding in parts of XP without doing this officially is a much more suitable solution since everyone feels more comfortable doing it, especially the managers.