I would argue if you're using Java, using an IDE is the only way to stay sane. Context aware class navigation is pretty much a requirement on any sizable project. Intellij can make Java almost enjoyable to use.
Your comments on agile and standups are spot on. Where I work now we do real standups. The group makes everyone actually standup and keeps the people who can wander during their turn on topic. The meeting is also strictly 15 minutes or less. It's the best daily type meeting I've ever had at any job and it works pretty well.
I don't like Java even with an IDE, and I especially dislike Maven, but Scala and Clojure are two of the most exciting languages out there, and because they're showing an ability to build communities that Haskell and Ocaml seem to lack (not a fault of the languages, but just because it's really hard to get people to learn "new everything") and so they're probably going to either be "the winners" when the divergence/convergence cycle of PL moves back into a convergent phase, or predecessors of whatever wins. Scala and Clojure are probably the "best bets" right now. The "language of 2020" won't be Java or Ocaml or SBCL, but Scala has a fighting chance.
On standups: if you're going to do a daily status meeting, then standup is the way to go.
That said, I dislike status meetings because I think they burn a lot of time, involve too much context switching, and don't solve problems that are better solved by direct communication. Also, audit-cycles don't have a one-size-fits-all pattern. You might want to ping an entry-level programmer daily in the first six months and 1-2x per week after that, while for a more senior person, a high-level might be appropriate.
One thing I will say is that a formalized status-reporting infrastructure (even one that costs a half hour per day) is much better than ad-hoc micromanagement. I worked at a company where 2-4 daily status pings (that would evolve into half-hour detailed conversations about minutiae) was the norm and that was a massive failure.
This applies to any language, not just Java.
Why do you say it failed?
I do consulting for Fortune 500 companies, and I am pretty convinced it was successful, based on the majority of guys we get assigned to our projects.
I'm kidding, sort of. I haven't seen the inside of a Fortune 500 company in years; I'm in startup-land now. But from what reports I hear, I imagine it's the same. Lots of "commodity" programmers driving the costs up an order of magnitude beyond what more talented programmers consider reasonable for the functionality. Then they pay a few brilliant people, often consultants, to drag them across arbitrarily designated finish line.
Meanwhile, startups, small companies, and the few large companies who take engineering seriously are bidding up the rest of the talented programmers. With cash, with freedom, with the ability to actually make something they aren't depressed by.
The problem is that even medium sized companies are following suite. My problem while looking for jobs is that it is becoming the same everywhere.
My tooling preference is evolving a bit. I used to hate IDEs, because I associated them with the (thank God it failed) attempt to commoditize programmer talent (starting in the 1990s with VB) that hijacked "object-oriented programming" and led to 21st-century spaghetti code. On the other hand, IDEs can actually be damn useful. You're in for hours of misery if you try to do Java development without an IDE, and IDEs are better adapted to one reality of software development: that most professional programmers spend more time trying to figure out other peoples' code than reading their own. The click-and-navigate capability (that automagically takes you to the file and line where a method or class is defined) is valuable.
Something Google had that I liked a lot is a code-navigation tool, much like a read-only IDE, served on the web, for its codebase. Very useful.
IDEs also help you navigate the dependencies and cruft-sprawl that are pretty much unavoidable on large Java projects. If you're on-boarding into an existing Java project and want to be productive in your first week, I think using an IDE is the only answer.
For my own projects (where I'll often use Scala but never Java) I still use emacs and probably always will, but if I'm working in a 100kLoC codebase of mixed Scala and Java, using a build and version-control system I'm not familiar with, I'm going to use the IDE, at least when I start out. IDEs aren't perfect: a lot of the things they hide or for which they automagically do the work (build system, version control) are things a programmer will actually want to understand at some point. But it's nice to be able to be productive (in a software environment you didn't create) on the first week.
Debuggers are another area where I'm coming to learn that printlining isn't always enough. The name of the game in debugging is not to break flow. Pinging about files inserting printlines (trying to figure out where to put them, and how to handle loops where you strictly do not want a printline for each time you're in the loop) can involve too much orthogonal thinking and context-switching to be productive, so an interactive debugger like what Lisp has or what Eclipse offers can be a godsend. Often printlining is the best solution because you know what you want to see in the execution (it's not "ad-hoc" debugging) but sometimes you don't. Once you start having to think about how to printline something, you're better off with an interactive debugger.
Unit tests, for me, are about not breaking flow. I'd rather do the debugging while the problem is fresh in my mind than possibly months later. I'm going to "REPL-test" the thing in any case, and I might as well turn that session into something persistent. I certainly won't remember, 3 months later, how comprehensive my REPL testing was. If I have unit tests, I can check and see what's covered and what isn't.
I don't write unit tests because I'm a nice guy. I do it because I'd rather spend an additional 20 minutes writing tests-- plus whatever debug time happens on account of bugs found, but that's strictly less time than it would cost me or someone else to debug it later-- than have to deal with a context switch weeks or months later to fix the damn thing.
As for Agile and Scrum, I think that stuff is mostly dopey pixie dust that's seems progressive because it's shiny and new, but most of it's neo-Taylorism, and Taylorism didn't fucking work the first time around. "Agile" is too ill-defined to mean much anymore. As for Scrum, structuring time into "iterations" is stupid (sure, you can call a 17-day period an "iteration" just as you can call an oblique trapezoid a "skwirk" and the class of mammals over 250 pounds "mforzas" but it doesn't mean anything), and most of this agile neo-management stuff can become a bog if (through benign neglect) it re-devolves through benign neglect into normal human behavior.
One example is stand-ups. If you're going to have frequent status meetings, stand-ups are the best way to do it. People tune out in meetings of more than 5 people except to communication directly affecting their work, so there isn't much learned in them. Stand-ups exist to encourage short status meetings rather than sprawling, boring slogs, so they're a useful innovation... when people actually stand the fuck up, If people treat it as a stand-up meeting (i.e. show up on time, actually stand, and only address issues that are directly blocking work) it can be useful, but if not, it just devolves.
The real purpose of stand-ups, by the way, is to prevent the issue where people delay communication on things they need out of fear or apprehension (that is, they're afraid to ask for what they need from people) and linger around being blocked on their main project, instead doing low-priority work. The purpose of standups is to allow people to say, objectively, "this issue is blocking me" and allow group pressure (rather than management fiat) to encourage resolution. It gives the blocked person an opportunity to state a blocking issue objectively without pointing a finger and the group pressure encourages people who have the power to resolve the blocker (who now not only know the blocker exists, but know that everyone else knows that they know, i.e. "common knowledge" in the modal-logic sense) to fix it. Without something like standups to force this, people with poor communication styles or avoidant personalities can end up lingering on low-priority work for weeks. So standups can be legitimately useful. On the other hand, most of this agile "magic sauce" is neo-managerial bullshit that quickly devolves into old-style bureaucratic muck.
For example, a lot of these "agile" startups that have standups have half the people not even standing up. It can creep into an hour-long sit-down meeting... except now it happens every day instead of once every 2 weeks. So now you're having 60+ minute long, boring status meetings every day, and productivity goes way down.