There's a nicely written white paper on java productivity called "Java Productivity Primer - Twelve guidelines to boost your productivity with a software factory" (great name too). It's written by consultants working at Octo (Guillaume "Groovy" Laforge's former employer, think of it as the French ThoughtWorks... ).
While some of it can sound as pretty obvious (use it to convince your peers or management if that's the case), I do like how they explain the reason for TDD, what development factories bring (even for smaller teams), why managing the build process from day one is a good idea, how it suggests Hudson as the continuous integration server, why you should use a source repository even for teams of one, among other things.
But there are a few things I don't quite agree with.
I'm just no longer buying the Tomcat + frameworks (Spring, Hibernate, ...) as a lightweight solution pitch. I mean, how lightweight can a solution be when you deploy 80% or more of the runtime with your application? The last thing a small development team wants to do is manage those software dependencies and deployments. Get a Java EE 5 app server and be done with those concerns. To be fair to the authors, this is a common perception in the industry.
Presenting REST as the only mentioned way to do Web Services just because it builds "on the web" is just way too simple. SOAP is here to stay and has a place. Others have covered this (+ this is a rat hole).
Finally, maybe somewhat of a nitpick but SVN is no one size fits all. While a much better CVS, one should also look at distributed systems (such as hg). Offline commit anyone?
Oh, and I still can't decide if Maven is a blessing or a curse.....
Download the white paper from Octo's web site.